Re: Gnumach FP Struct (Beating a dead horse)
Barry deFreese, le Fri 22 Dec 2006 23:45:18 -0500, a écrit : > 1) What do I do with the xmm space, ignore it? Of course no, since fxsave will fill it up anyway. > 2) Where is the best place to check for fxsr? Should it be done in > fpu.c after we determine fpu_type = FP_387? That should be fine, yes. Maybe we should define a new FP_387X (or any better name, I'm not good at naming things). Samuel ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Gnumach FP Struct (Beating a dead horse)
Samuel Thibault wrote:
Barry deFreese, le Thu 21 Dec 2006 09:54:05 -0500, a écrit :
OK, that makes sense, sorry. It just takes a while to get through my
thick skull sometimes. So about my question about adding a struct for
the fxsr stuff. I don't really want to add a union of 4 structs right,
I need two unions of two structs? So I'd have something like this:
union i387_save_struct {
struct i386_fp_save;
struct i386_fpxsr_save;
}
and
union i387_regs_struct {
struct i386_fp_regs;
struct i386_fpxsr_regs;
}
Make sense?
Makes sense, but won't work. Remember that the size of a union is the
size of its biggest member. When you'll put both unions one after the
other in the i386_fpsave_state structure, i386_fp_regs will _not_
be just after i386_fp_save, just because sizeof(i386_fpxsr_save) >
sizeof(i386_fp_save). The union has hence to be before the split into
structures.
Also, about structure, look at the Intel docs: only the XMM register
saving area doesn't have holes.
Samuel
OK, one more time. And if this is correct, I have two questions. 1)
What do I do with the xmm space, ignore it? 2) Where is the best place
to check for fxsr? Should it be done in fpu.c after we determine
fpu_type = FP_387?
Thanks as always and thanks especially to Samuel and Olaf for their time
and patience!
Barry
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Gnumach FP Struct (Beating a dead horse)
Barry deFreese, le Thu 21 Dec 2006 09:54:05 -0500, a écrit :
> OK, that makes sense, sorry. It just takes a while to get through my
> thick skull sometimes. So about my question about adding a struct for
> the fxsr stuff. I don't really want to add a union of 4 structs right,
> I need two unions of two structs? So I'd have something like this:
>
> union i387_save_struct {
>struct i386_fp_save;
>struct i386_fpxsr_save;
> }
>
> and
>
> union i387_regs_struct {
>struct i386_fp_regs;
>struct i386_fpxsr_regs;
> }
>
>
> Make sense?
Makes sense, but won't work. Remember that the size of a union is the
size of its biggest member. When you'll put both unions one after the
other in the i386_fpsave_state structure, i386_fp_regs will _not_
be just after i386_fp_save, just because sizeof(i386_fpxsr_save) >
sizeof(i386_fp_save). The union has hence to be before the split into
structures.
Also, about structure, look at the Intel docs: only the XMM register
saving area doesn't have holes.
Samuel
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Gnumach FP Struct (Beating a dead horse)
Samuel Thibault wrote:
Barry deFreese, le Thu 21 Dec 2006 00:17:34 -0500, a écrit :
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.
I told you: this permits to easily do what is written in fpu.c:
/*
* Ensure that reserved parts of the environment are 0.
*/
memset(user_fp_state, 0, sizeof(struct i386_fp_save));
user_fp_state->fp_control = ifps->fp_save_state.fp_control;
user_fp_state->fp_status = ifps->fp_save_state.fp_status;
user_fp_state->fp_tag = ifps->fp_save_state.fp_tag;
user_fp_state->fp_eip = ifps->fp_save_state.fp_eip;
user_fp_state->fp_cs = ifps->fp_save_state.fp_cs;
user_fp_state->fp_opcode = ifps->fp_save_state.fp_opcode;
user_fp_state->fp_dp = ifps->fp_save_state.fp_dp;
user_fp_state->fp_ds = ifps->fp_save_state.fp_ds;
*user_fp_regs = ifps->fp_regs;
With separate structs, the last line can be written that way, allowing
the compiler to optimize the copy. For getting the same result without
separate structs, we'd have to call an ugly explicit memcpy().
Samuel
Samuel,
OK, that makes sense, sorry. It just takes a while to get through my
thick skull sometimes. So about my question about adding a struct for
the fxsr stuff. I don't really want to add a union of 4 structs right,
I need two unions of two structs? So I'd have something like this:
union i387_save_struct {
struct i386_fp_save;
struct i386_fpxsr_save;
}
and
union i387_regs_struct {
struct i386_fp_regs;
struct i386_fpxsr_regs;
}
Make sense?
Thanks,
Barry deFreese (aka bddebian)
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Gnumach FP Struct (Beating a dead horse)
Barry deFreese, le Thu 21 Dec 2006 00:17:34 -0500, a écrit : > 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. I told you: this permits to easily do what is written in fpu.c: /* * Ensure that reserved parts of the environment are 0. */ memset(user_fp_state, 0, sizeof(struct i386_fp_save)); user_fp_state->fp_control = ifps->fp_save_state.fp_control; user_fp_state->fp_status = ifps->fp_save_state.fp_status; user_fp_state->fp_tag = ifps->fp_save_state.fp_tag; user_fp_state->fp_eip = ifps->fp_save_state.fp_eip; user_fp_state->fp_cs = ifps->fp_save_state.fp_cs; user_fp_state->fp_opcode = ifps->fp_save_state.fp_opcode; user_fp_state->fp_dp = ifps->fp_save_state.fp_dp; user_fp_state->fp_ds = ifps->fp_save_state.fp_ds; *user_fp_regs = ifps->fp_regs; With separate structs, the last line can be written that way, allowing the compiler to optimize the copy. For getting the same result without separate structs, we'd have to call an ugly explicit memcpy(). Samuel ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Gnumach FP Struct (Beating a dead horse)
doesn't matter the bytewise layout is set by the hw how you call the fields in c is taste ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Gnumach FP Struct (Beating a dead horse)
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 intfp_eip; /* eip at failed instruction */
unsigned short fp_cs; /* cs at failed instruction */
unsigned short fp_opcode; /* opcode of failed instruction */
unsigned intfp_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 {
longcwd;
longswd;
longtwd;
longfip;
longfcs;
longfoo;
longfos;
longst_space[20]; /* 8*10 bytes for each FP-reg = 80 bytes */
longstatus; /* 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)
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
