bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Gnumach FP Struct (Beating a dead horse)


From: Barry deFreese
Subject: Gnumach FP Struct (Beating a dead horse)
Date: Thu, 21 Dec 2006 00:17:34 -0500
User-agent: Thunderbird 1.5.0.8 (Windows/20061025)

Heya gang,

I apologize for keep going on about this but I still don't quite understand why a seperate struct is needed for i386_fp_regs. Here is what gnumachs looks like:


struct i386_fp_save     {
       unsigned short  fp_control;     /* control */
       unsigned short  fp_unused_1;
       unsigned short  fp_status;      /* status */
       unsigned short  fp_unused_2;
       unsigned short  fp_tag;         /* register tags */
       unsigned short  fp_unused_3;
       unsigned int    fp_eip;         /* eip at failed instruction */
       unsigned short  fp_cs;          /* cs at failed instruction */
       unsigned short  fp_opcode;      /* opcode of failed instruction */
       unsigned int    fp_dp;          /* data address */
       unsigned short  fp_ds;          /* data segment */
       unsigned short  fp_unused_4;
};

struct i386_fp_regs {
       unsigned short  fp_reg_word[5][8];
/* space for 8 80-bit FP registers */
};


And here is how Linux does it:


struct i387_fsave_struct {
       long    cwd;
       long    swd;
       long    twd;
       long    fip;
       long    fcs;
       long    foo;
       long    fos;
       long    st_space[20];   /* 8*10 bytes for each FP-reg = 80 bytes */
       long    status;         /* software status information */
};


Is there some reason that I am not understand that i386_fp_regs has to be a seperate struct and not an element of i386_fp_save?

Thanks and sorry to keep griping on this,

Barry deFreese (aka bddebian)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]