This is the mail archive of the gcc@gcc.gnu.org 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 Thu, 16 May 2002, Zack Weinberg wrote:

> Just a lot of tedious typing.  Lemme get you started.  Apply the
> appended patch.  Go through the entire of real.c and change all the
> uses of 2*NE to EBYTES.  Then inspect all the other uses of NE to make
> sure they don't assume that EMUSHORT/UEMUSHORT are 16 bits.  You
> should probably also take a close look at NI, NBITS, etc.  I'll help
> as needed.

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.

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?

Bye

Roman



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