The functions getX and setX in Foreign.Memory take an offset as a Word.word. I'm finding that it is possible to have a negative offset by negating the word offset, e.g. get8 (p, ~ 0w1) Is that guaranteed work generally?
Given that Word.wordSize = 63 SysWord.wordSize = 64 I wouldn't have expected this to work for get8/set8 but it does.
Phil
P.S. My efforts to inspect the source didn't get far as these functions go straight to run-time calls and I'm not familiar with internal representations in Poly/ML...
On 15/01/2016 16:13, Phil Clayton wrote:
The functions getX and setX in Foreign.Memory take an offset as a Word.word. I'm finding that it is possible to have a negative offset by negating the word offset, e.g. get8 (p, ~ 0w1) Is that guaranteed work generally?
Given that Word.wordSize = 63 SysWord.wordSize = 64 I wouldn't have expected this to work for get8/set8 but it does.
Phil
P.S. My efforts to inspect the source didn't get far as these functions go straight to run-time calls and I'm not familiar with internal representations in Poly/ML...
The intention is that they should work correctly for negative offsets. It seemed more useful that way. Word.toIntX does imply that the basis library understands signed word values.
Currently these functions end up in the assembly code, in the case of getX as cmem_load_asm_8, where it uses an arithmetic shift to detag. I'm currently working on incorporating them into the code-generator which will much improve efficiency but that will have to wait for the next release.
David
On 16/01/2016 08:51, David Matthews wrote:
On 15/01/2016 16:13, Phil Clayton wrote:
The functions getX and setX in Foreign.Memory take an offset as a Word.word. I'm finding that it is possible to have a negative offset by negating the word offset, e.g. get8 (p, ~ 0w1) Is that guaranteed work generally?
Given that Word.wordSize = 63 SysWord.wordSize = 64 I wouldn't have expected this to work for get8/set8 but it does.
Phil
P.S. My efforts to inspect the source didn't get far as these functions go straight to run-time calls and I'm not familiar with internal representations in Poly/ML...
The intention is that they should work correctly for negative offsets. It seemed more useful that way. Word.toIntX does imply that the basis library understands signed word values.
Yes - the getX/setX operations are more useful by allowing negative offsets. Unfortunately, the word offset can be viewed in an unsigned way. I would suggest e.g. getX : voidStar * int -> Word8.word unless use of an int introduces more overhead.
Certainly the Basis Library understands sign extension of words. If the Word.word offset is signed extended to a SysWord.word (the underlying pointer representation) then I see no problem.
Currently these functions end up in the assembly code, in the case of getX as cmem_load_asm_8, where it uses an arithmetic shift to detag. I'm currently working on incorporating them into the code-generator which will much improve efficiency but that will have to wait for the next release.
Good to know, thanks.
Phil
On 18/01/2016 10:14, Phil Clayton wrote:
The intention is that they should work correctly for negative offsets. It seemed more useful that way. Word.toIntX does imply that the basis library understands signed word values.
Yes - the getX/setX operations are more useful by allowing negative offsets. Unfortunately, the word offset can be viewed in an unsigned way. I would suggest e.g. getX : voidStar * int -> Word8.word unless use of an int introduces more overhead.
I don't want to use "int" here for these very low-level functions. It would require a tag test to check that it isn't a long-format arbitrary precision number.
David
-
David.Matthews＠prolingua.co.uk -
phil.clayton＠lineone.net