1. Phix: peek8u deprecated.
- Posted by petelomax Dec 26, 2016
- 1770 views
I have just spent a couple of days chasing down an intermittent bug, only to finally realise that 80-bit floats can store all signed 64-bit integers, but not unsigned.
The fly in the ointment, as I now understand it, is that there is an implicit 1 in 16 and 32 bit floats which is explicit in 80-bit - thanks for that should go to IEEE 754.
The main change is that C_PTR and friends have become signed on 64-bit Phix, mainly to cope with GetStockObject yielding handles such as FFFF_FFFF_B130_104F.
Given that peek8s can cope, I have somewhat reluctantly decided to deprecate peek8u (or at least add dire warnings to the docs).
I would love to be proved wrong on this, but I somehow doubt that will happen.
Pete
2. Re: Phix: peek8u deprecated.
- Posted by SDPringle Dec 28, 2016
- 1668 views
Yes the problem is, what you say is true. In general on IA64, this will cause hard to find bugs in wrapper code.
3. Re: Phix: peek8u deprecated.
- Posted by ChrisB (moderator) Dec 28, 2016
- 1683 views
This must be the Pokemon Deprecation then.
Chris
4. Re: Phix: peek8u deprecated.
- Posted by SDPringle Dec 28, 2016
- 1633 views
This must be the Pokemon Deprecation then.
Chris
WHAT?
5. Re: Phix: peek8u deprecated.
- Posted by ghaberek (admin) Dec 29, 2016
- 1615 views
This must be the Pokemon Deprecation then.
Chris
WHAT?
"PEEK EIGHT YOU" sounds like Pikachu.
-Greg
7. Re: Phix: peek8u deprecated.
- Posted by petelomax Jan 01, 2017
- 1532 views
Oh, ffs - I read something on the internet and it was WRONG!
I knew there was a problem with unsigned 64 bit ints in 80-bit floats, so just accepted his word (/diagram) as the gospel truth.
(Figure 2.3 shows a literal 1, which I thought was odd, but y'know the whole "well, that explains it" thing.. It ain't a fixed 1.)
To my shame, I already knew there was a problem getting them in, what I missed was the (simple) problem in getting them out.
The FP instructions fild/fist/fistp work with *integers* there is no instruction for unsigned integers.
The Floating Point Unit doesn't know of unsigned integers existence, so if the number won't fit in a signed integer then it is an overflow (0x80000000....).
There may be a better way (suggestions welcome) but this will load an unsigned int (already in rax):
-- to load unsigned, right shift rax by 1, save odd bit in rcx, then *2+[0|1] xor rcx,rcx shr rax,1 rcl rcx,1 push rax push rcx fild qword[rsp] fild qword[rsp+8] add rsp,16 fadd st0,st0 -- *2 faddp -- +0|1
Extracting an unsigned int (from an 80-bit float already in st0) is not really any better or worse:
-- if uint>#7FFF... then uint-=#1_0000... push r15 -- #4000_0000_0000_0000 fild qword[rsp] fadd st0,st0 -- #8000_0000_0000_0000 fld st1 fcomp fnstsw ax sahf jb @f fadd st0,st0 -- #1_0000_0000_0000_0000 fsub st1,st0 @@: fstp st0 -- discard fistp qword[rsp] pop rax
(Obviously, do a mov r15,h4 first when unsure, but that will be unneccessary more often than not.)
[Some further care may also be needed when dealing with already signed values, and it may be easier in hll]
So that just needs applying in ten dozen or so places throughout the backend, and peek8u can live on
Pete