Re: Merging few files from i386/amd64 into x86

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

Andrew Doran wrote:
> On Sun, Mar 29, 2009 at 07:27:42PM +0100, Mindaugas Rasiukevicius wrote:
> 
>> David Young <dyoung%pobox.com@localhost> wrote:
>>> Can you avoid using new #ifdefs, or else confine them to the top of the
>>> file?  They make even straightforward code hard to read. :-/
>> My goal is a little bit different than sprinkling #ifdefs in random places. 
>> ;)
>>
>>> The vm_machdep.c are so alike that I wonder if you can pull out most of
>>> the code that is the same and stick it into sys/arch/x86/ ?
>>>
>>> I had a look at vm_machdep.c with a mind to reduce purely cosmetic
>>> differences.  I made the attached compilable but untested patch.  ISTR
>>> the differences can be reduced further by a few minor changes: for
>>> example, rename npxsave_lwp to fpusave_lwp.
>> I have committed various cosmetic reductions yesterday, including some
>> changes to vm_machdep.c code which are similar to yours (noticed your
>> email just today, since I was not in CC). Ideally, those #if NNPX > 0
>> should be removed by making npxsave_lwp() et al empty stubs.
> 
> Contrary to what the configuration files suggest fpu support is not
> optional. The fpu code can easily be shared between amd64/i386 because i386
> no longer needs the 80387 support. A small hurdle is register naming.
> Another is XEN support, which will differ between the two architectures.
> 
> I have heard it said that npx should be included in the device tree because
> it uses various system resources. Fair enough, but from what I remember 
> there are other ports and they differ between cpu families.

The Xen FPU driver is just there to perform the FPU context switch - the
only one privileged operation.

Define a simple API for a FPU context switch with one implementation
for i386/amd64 and with one Xen implementation. All other FPU code can
be shared.

Christoph