Port-i386 archive

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

x87 fpu and some very old code



I've been looking at the floating point code in both the i386 and amd64
ports with a view to adding support for AVX and any future cpu extensions.

So far I've just tidied up some over-compley structure and made
the field names unique (so I can grep for the uses).

This code is made all the more horrid because there are array definitions
of the hardware save areas elsewhere (eg for getucontext) that just
get cast to ones that contain the additional fields of (2) below.

There are a few of things about the existing code that I might change
but they might have odd side effects.

1) Make support for the x87 non-optional (ie remove all the #if NNPX).
   I'll also look at the attachment (npx at isa/acpi) since that might
   also be irrelevant for i486 onwards.
   (The i486 has never had an fpu co-processor, only the 286 and 386
   had external fpus. I'm not sure the io address (0xf0) is used at all.)

2) For some reason the FPU 'tag word' and 'control word' are saved in
   special locations in the pcb during an fpu fault. Apart from the
   immediate use when generating the signal, I can't find any other
   uses of the fields.
   However they are saved in a place that will be overwritten by the
   additional registers.
   I need to move them, but I mught just delete them.
   Does anyone know if anything odd (like gdb) looks at them.
   The code goes back a long way right to the very first versions in
   the netbsd cvs.

3) Someone put the thread register right in the middle, that will have
   to be moved.  This is visible to userspace via [sg]etcontext()
   except that the register layout isn't defined.
   The last 48 bytes of the 512 byte fxsave buffer are available for
   use by the OS. I might put th TLS register in there.
   [sg]etcontext() will also need versioning - if nothing else to
   add a buffer length.

4) The FP register buffer for [sg]etcontext() is either in x87 fsave
   of the newer fxsave format.
   I think I'll change the code to always return the latter (as the amd64
   port does - I think even for 32bit processes).

5) I might even emulate fxsave on old cpus - so even the pcb contains the
   fxsave format. This won't cost much unless some of the x87 resisters
   are marked 'active' - unlikely unless the code is using MMX instructions.

6) I also intent to simplify the code that generates the full 'tag word'
   from the 'abridged tag word' so that it only generates 0b00 (used)
   and 0x11 (free) (not 0b01 (zero), and 0b10 (special)).
   Only the 287 looked at these bits.

7) I'll look at the linux code for gdb to see what to do for ptrace.
   Best not tomake the gdb changes too hard.
   IIRC they added a different system call to request the extended state.
   gdb has its own definition of these structures - makes at least 3.

Any thoughts before I break everything.

I have got a system that supports AVX (sandy bridge) and a 486-like cpu.
I might be able to test on an ivy bridge system as well, and just possibly
a haswell. I don't have a recent amd system though.
(Not that all the above are currently bootable...)

        David


        David

-- 
David Laight: david%l8s.co.uk@localhost


Home | Main Index | Thread Index | Old Index