This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: real.c on unicosmk
- From: Roman Lechtchinsky <rl at cs dot tu-berlin dot de>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 22 May 2002 14:16:19 +0200 (MET DST)
- Subject: 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.
Bye
Roman