[rfc] Add some more floatformat types ....

[rfc] Add some more floatformat types ....

[Andrew Cagney]

Hello,

The attached adds the floatformats:

floatformat_i387_ext80;
floatformat_i387_ext96;

	Explicitly sized x86 float formats.

	Depending on where/how it is stored,
	an i386 extended could use 80 (10 bytes)
	or 96 (12 bytes).

floatformat_m88110_harris_ext;

	This eliminates a build hack.

	Prior to this tweek, a compile time
	option was deciding the layout of the m88110
	floatformat.  I think that was just wrong.

floatformat_arm_ext_big;
floatformat_arm_ext_littlebyte_bigword;

	Like i387_ext but with byte order.

	The arm can be big or little endian.
	arm-ext little-byte big-word
	is my interpretation of how the LE-arm
	lays an FP value out in memory.
	The lack of this has me puzzled, I'm
	suprised no one added it earlier :-/

Given that these files are only used by opcodes and GDB, and that this 
change (ignoring the harris bit) has no effect, I'm planning in simply 
checking it in (via GCC) in a few days.

Comments?

	Andrew

PS: Hopefully I've got the values right.

Re: [rfc] Add some more floatformat types ....

[Andrew Cagney]

Attatched is a revised patch for:

> Hello,
> 
> The attached adds the floatformats:
> 
> floatformat_i387_ext80;
> floatformat_i387_ext96;
> 
>     Explicitly sized x86 float formats.
> 
>     Depending on where/how it is stored,
>     an i386 extended could use 80 (10 bytes)
>     or 96 (12 bytes).
> 
> floatformat_m88110_harris_ext;
> 
>     This eliminates a build hack.
> 
>     Prior to this tweek, a compile time
>     option was deciding the layout of the m88110
>     floatformat.  I think that was just wrong.
> 
> floatformat_arm_ext_big;
> floatformat_arm_ext_littlebyte_bigword;
> 
>     Like i387_ext but with byte order.
> 
>     The arm can be big or little endian.
>     arm-ext little-byte big-word
>     is my interpretation of how the LE-arm
>     lays an FP value out in memory.
>     The lack of this has me puzzled, I'm
>     suprised no one added it earlier :-/
> 
> Given that these files are only used by opcodes and GDB, and that this change (ignoring the harris bit) has no effect, I'm planning in simply checking it in (via GCC) in a few days.
> 
> Comments?
> 
>     Andrew

It also adds

floatformat_ia64_ext128
	An 82bit IA64 floating point packed
	into a 128 bit integer.

I'll check it in ``tomorrow''.

	Andrew

Re: [rfc] Add some more floatformat types ....

[Mark Kettenis]

Andrew Cagney <ac131313@cygnus.com> writes:

> > The attached adds the floatformats:
> > 
> > floatformat_i387_ext80;
> > floatformat_i387_ext96;
> > 
> >     Explicitly sized x86 float formats.
> > 
> >     Depending on where/how it is stored,
> >     an i386 extended could use 80 (10 bytes)
> >     or 96 (12 bytes).

Andrew, I thought I (implicitly) raised some objections to this
change.  See

   http://sources.redhat.com/ml/gdb/2001-07/msg00401.html

To clarify things a bit: The ISA (that stands for Istruction Set
Architecture doesn't it) defines a single 80-bit extended floating
point format.  On top of that floating point format most ABI's build a
a 96-bit extended floating point type (e.g. GCC's `long double').  I'd
like GDB to somehow maintain this concept, by *not* introducing the
floatformat_i387_ext80 and floatformat_i387_ext96 types you propose.
Instead we should make the distinction at the builtin_type_* level.
By making the 80-bit and 96-bit builtin_type_* variants share the same
underlying floatformat_* variable, we can easiliy check whether two
floating point formats on the ABI level share the same encoding on the
ISA level.

Something similar might hold for IA-64.

The other two fixes seem obvious to me.

Mark

Re: [rfc] Add some more floatformat types ....

[Fernando Nasser]

Andrew Cagney wrote:
> 
> floatformat_arm_ext_big;
> floatformat_arm_ext_littlebyte_bigword;
> 
>         Like i387_ext but with byte order.
> 
>         The arm can be big or little endian.
>         arm-ext little-byte big-word
>         is my interpretation of how the LE-arm
>         lays an FP value out in memory.
>         The lack of this has me puzzled, I'm
>         suprised no one added it earlier :-/
> 

I don't have any objection.


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9