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 Mon, 20 May 2002, Zack Weinberg wrote:

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

I've now implemented it such that the sign, the exponent and the high
guard are stored in separate words while the low guard occupies the lower
16 bits of the last 32-bit word. This seems to be the most convienient
representation. Arithmetic seems to work ok.

However, I don't really understand the various target-specific
representations (i.e. e24, e53 etc.). Unless I've missed something they
are only used internally, but the actual representation depends on
REAL_WORDS_BIG_ENDIAN which considerably complicates the code now and
becomes a real mess with my changes. Is there any good reason for this
dependency or can I safely remove it? Then, endian would be the only
function which takes the endianness of the target into account.



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