Re: Unifying i387 support

[jtc@redback.com (J.T. Conklin)]

>>>>> "Jim" == Jim Blandy <jimb@cygnus.com> writes:
>> > struct i387_regs {
>> >   char ctrl[2];		char dummy1[2];
>> >   char stat[2];		char dummy2[2];
>> >   char tag[2];		char dummy3[2];
>> >   char code_off[4];
>> >   char code_seg[2];
>> >   char opcode[2];
>> >   char data_off[4];
>> >   char data_seg[2];	char dummy4[2];
>> >   char st[8][10];
>> > };
>> 
>> Does anyone care for the MMX view of the ST(i) registers?  Perhaps, if
>> we design a change in the layout, it would be better to make it
>> last...

Jim> I don't understand.  They do appear last.

I think Eli was asking whether it would be better to use the FXSAVE
format introduced with MMX and extended with the SSE instead of the
FSAVE format described above.  It might be worth doing if we're 
going to support MMX and SSE registers.  

The FSAVE format makes supporting FP registers trivial on targets that
use FNSAVE to store FP state and GDB accesses it via the u area or a
ptrace call as it.  Those targets would have to place registers into
the FXSAVE struct one by one.  Since both the FSAVE and FXSAVE formats
are well documented, we could share the code used to do the
conversions.

For reference, the FXSAVE struct would be something like this:

/* STx / MMx register layout */
struct st_mm_reg {
	char st[10];
	char dummy[6];
}

struct fxsave_data {
	char fcw[2];
	char fsw[2];
	char ftw;
	char dummy1;
	char fop[2];
	char ip[4];
	char cs[2];
	char dummy2[2];
	char dp[4];
	char ds[2];
	char dummy3[2];
	char mxcsr[4];
	char dummy4[2];
	struct fxsave_streg stregs[8];
	char xmm[8][16];
}

	--jtc

-- 
J.T. Conklin
RedBack Networks