remAddr# primop inconsistency

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

remAddr# primop inconsistency

Csaba Hruska
Hello,

I've discovered that the remAddr# primop documentation is inconsistent with the implementation.
According to the docs (primops.txt.pp) the remAddr# should be the same as remInt#.
primop   AddrRemOp "remAddr#" GenPrimOp Addr# -> Int# -> Int#
         {Return the remainder when the {\tt Addr\#} arg, treated like an {\tt Int\#},
          is divided by the {\tt Int\#} arg.}
But it is implemented with the mo_wordURem instruction, just like the WordRemOp primop.
GHC/StgToCmm/Prim.hs:
AddrRemOp -> \args -> opTranslate args (mo_wordURem platform)
WordRemOp -> \args -> opTranslate args (mo_wordURem platform)
IntRemOp -> \args -> opTranslate args (mo_wordSRem platform)

Which one is correct, the docs or the implementation?

Regards,
Csaba Hruska

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: remAddr# primop inconsistency

Ben Gamari-3
Csaba Hruska <[hidden email]> writes:

> Hello,
>
> I've discovered that the remAddr# primop documentation is inconsistent with
> the implementation.
> According to the docs (primops.txt.pp) the remAddr# should be the same as
> remInt#.
>
>> primop   AddrRemOp "remAddr#" GenPrimOp Addr# -> Int# -> Int#         {Return the remainder when the {\tt Addr\#} arg, treated like an {\tt Int\#},          is divided by the {\tt Int\#} arg.}
>>
>> But it is implemented with the mo_wordURem instruction, just like the
> WordRemOp primop.
>
>> GHC/StgToCmm/Prim.hs:
>>
> AddrRemOp -> \args -> opTranslate args (mo_wordURem platform)
>>
> WordRemOp -> \args -> opTranslate args (mo_wordURem platform)
>>
> IntRemOp -> \args -> opTranslate args (mo_wordSRem platform)
>>
>
> Which one is correct, the docs or the implementation?
That is a good question. The only user (in the GHC tree) is
GHC.Ptr.alignPtr which appears to want the Word semantics (that is, it
would break given a negative remainder). Moreover, my mental model of
pointers is that for the purposes of arithmetic they are non-negative.
Therefore, I belive that the documentation here is wrong.

I have opened #19332 to track this.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: remAddr# primop inconsistency

Csaba Hruska
Great, thanks!

On Sat, Feb 6, 2021 at 5:04 PM Ben Gamari <[hidden email]> wrote:
Csaba Hruska <[hidden email]> writes:

> Hello,
>
> I've discovered that the remAddr# primop documentation is inconsistent with
> the implementation.
> According to the docs (primops.txt.pp) the remAddr# should be the same as
> remInt#.
>
>> primop   AddrRemOp "remAddr#" GenPrimOp Addr# -> Int# -> Int#         {Return the remainder when the {\tt Addr\#} arg, treated like an {\tt Int\#},          is divided by the {\tt Int\#} arg.}
>>
>> But it is implemented with the mo_wordURem instruction, just like the
> WordRemOp primop.
>
>> GHC/StgToCmm/Prim.hs:
>>
> AddrRemOp -> \args -> opTranslate args (mo_wordURem platform)
>>
> WordRemOp -> \args -> opTranslate args (mo_wordURem platform)
>>
> IntRemOp -> \args -> opTranslate args (mo_wordSRem platform)
>>
>
> Which one is correct, the docs or the implementation?

That is a good question. The only user (in the GHC tree) is
GHC.Ptr.alignPtr which appears to want the Word semantics (that is, it
would break given a negative remainder). Moreover, my mental model of
pointers is that for the purposes of arithmetic they are non-negative.
Therefore, I belive that the documentation here is wrong.

I have opened #19332 to track this.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs