This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]