This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: real.c on unicosmk
On Sat, May 18, 2002 at 03:33:02PM +0200, Roman Lechtchinsky wrote:
> Just couldn't wait till next week :-) One question I have is about
> the representation of floating point numbers in the emulator. In the
> external format, the exponent is always the last element of the
> EMUSHORT array at the moment. If EMUSHORT is 32 bits it will have to
> be packed into the last element together with the last 16-bit word
> of the significand. Do I have to take the endianness of the host
> into account here or can I just say that the exponent is always
> stored in e.g. the upper 16 bits of the last 32-bit word? In the
> latter case, the physical layout will change on big-endian hosts.
The external format is (should be) opaque to all code outside real.c,
which means you can do whatever is most convenient to the code inside
real.c.
> Similarily, in the internal representation we have a sign word, the
> exponent and two guard words which are all 16 bits now. I suppose
> that these should be stored in separate EMUSHORTs regardless of its
> size. Or should they be packed in some way in the 32 bit case?
I would go for separate EMUSHORTs; that should require fewer code
changes. The size of the internal representation is not really a
concern. Heck, the size of the *external* representation is not
really a concern; a case could be made for storing raw internal
representation in REAL_VALUE_TYPE, as a brute force way of cleaning up
some of the maze that is real.c. But that's a patch for another day,
if at all.
zw