Date: Sun, 12 Dec 1999 17:26:02 +0100 From: Martin Cracauer <cracauer@cons.org> To: arch@freebsd.org Cc: marcel@freebsd.org, bde@freebsd.org Subject: Concrete plans for ucontext/mcontext changes around 4.0 Message-ID: <19991212172602.A10611@cons.org>
next in thread | raw e-mail | index | archive | help
Here's my summary what to do with signal handler arguments until 4.0: 1) Before feature freeze: get the size of ucontext/mcontext into what we can live with for a longer time (i.e. until 5.0 or serious other changes). - Correct the size of the FPU/FPU-emul reservation so that it is the size of struct save87 (4 bytes too much at this time). - Add space for SSE registers. - Add some more space that allows more flexible use of the SSE register space for other purposes (isn't this pretty equivalent to the 3dnow registers on AMD, BTW?). This will not be enough space for a whole new feature. - Add one int member to use as 32 bitwise booleans to indicate what the SSE/additional space is used for in this signal invocation. FPU state will unconditionally be there. 2) Actually implement the saving of FPU state over signal handlers, ASAP. I'm working on this, but the first review result by Bruce indicates I need some additional homework, so I won't be ready on 15th Dec. I don't consider this to be a new feature, it is required semantics for ANSI C compliance, so I hope its ok to do while the freeze is in effect. 3) Fix the FPU and other CPU feature set representation in struct ucontext/mcontext. As you might have noticed, I would prefer to have real structs, not byte arrays as it is now. However, this is hard to do without serious include file bloat and some people don't want it at all (other OS don't have it as well). The implementation of 1) and 2) as indicated above will have the FPU represented exactly like struct save87 (although it appears as plain array). Thus, people will be able to use the named struct field by just casting this space, not needing to count bytes. I think this is a reasonable compromise for now. When I feel an urgent need to fix this, I will work on a restructuring and unbloat of include files and see if it is considered OK. This may become irrelevant with [sg]etcontext and/or thread changes anyway. Any objections? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991212172602.A10611>