Re: FloatToStr Reals and whole numbers on XP
From: Martin Harvey (Demon account) (martin_at_nospam_pergolesi.demon.co.uk)
Date: 10/09/04
- Next message: Shiva: "Re: Preventing user access"
- Previous message: James B. Millard: "Re: Program terminating"
- In reply to: AlanGLLoyd: "Re: FloatToStr Reals and whole numbers on XP"
- Next in thread: AlanGLLoyd: "Re: FloatToStr Reals and whole numbers on XP"
- Reply: AlanGLLoyd: "Re: FloatToStr Reals and whole numbers on XP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 09 Oct 2004 12:17:53 GMT
On 09 Oct 2004 05:46:55 GMT, alanglloyd@aol.com (AlanGLLoyd) wrote:
>Martin
>
>Maybe I'm in dim mode <g>
No, no - you were right! I was in dim mode, and wrote 2^8, when I
meant 2^3 = 8.
>AIUI 1.001b x 2^8 == 288d, 1.001b x 2^3 == 9d.
>
>I realise that your quote of ...
>
> $00, $00, $00, $00, $00, $00, $22, $40
>
>... are the bytes of a double of value 9.0000000etc
>
>But I have difficulty relating those bit values to the memory representation
>quoted in OPLG 18-4 (and Delphi help) of ...
>
>v = (-1)^s * 2^-1022 * 0.f
>
>... where s is bit 63, and f is bits 0 to 51 (counting from RHS).
>
>Additionally investigating the byte values shows they are as you quoted, but
>that -9 is ...
>
> $00, $00, $00, $00, $00, $00, $22, $C0
>
>ie the "sign" bit appears to be bit 7 (from RHS).
There are two (separate) issues at stake here:
- Bit order when writing a hexadecimal constant.
- Endian when writing a multibye quantity as an array of bytes.
- Writing a hexadecimal constant, the most significant bit is on the
left.
- However, when writing an array of byte values down, we tend to list
the byte at the *lowest address* first - hence, thinking from a
"reading a constant" point of view, the "bit order" and the "byte
order" are different.
- In such cases, we have to bear "endian" into account. In little
endian (intel processors), the least significant bytes come at the
lowest memory addresses.
So, here are four examples of 64 bit constants expressed as a single
hex number:
Bit 0 Set: $0000000000000001
Bit 7 Set: $0000000000000080
Bit 55 set: $0100000000000000
Bit 63 set: $8000000000000000
Now what I'll do is write them down as an array of eight bytes in
little endian. Remember that the "bit order" in the bytes is written
the same way, but because we have an array of bytes on a little endian
processor, the bits are divided into chunks of 8, and then stored with
the least significant at the lowest memory address (which is
conventionally written first):
Bit 0 Set: $01, $00, $00, $00, $00, $00, $00, $00
Bit 7 Set: $80, $00, $00, $00, $00, $00, $00, $00
Bit 55 set: $00, $00, $00, $00, $00, $00, $00, $01
Bit 63 set: $00, $00, $00, $00, $00, $00, $00, $80
This also illustrates it well:
http://www.cs.umass.edu/~verts/cs32/endian.html
You managed to come up with the answer "bit 7 is the sign bit" by
reading the array of bytes in big endian instead of little endian.
Taking this into account, you can see that the bit ordering for a 32
bit quantity (too lazy to write all 64 down!), when written as an
array of bytes, and viewed in hexadecimal is:
7 6 5 4 3 2 1 0, 15 14 13 12 11 10 9 8, 23 22 21 20 19 18 17 16, 31 30
29 28 27 26 25 24
Oh yeah, and if you think that's messed up, when numbering the bits
(for example) 0..63, most processor manuals take bit 0 to be the least
significant, apart from some Motorla processors, which are not only
big endian, but number the bits the other way round as well
(aaaargh!).
MH.
- Next message: Shiva: "Re: Preventing user access"
- Previous message: James B. Millard: "Re: Program terminating"
- In reply to: AlanGLLoyd: "Re: FloatToStr Reals and whole numbers on XP"
- Next in thread: AlanGLLoyd: "Re: FloatToStr Reals and whole numbers on XP"
- Reply: AlanGLLoyd: "Re: FloatToStr Reals and whole numbers on XP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|