On Fri, 5 Jul 2002, Jake Burkholder wrote:

> Apparently, On Fri, Jul 05, 2002 at 05:43:26PM -0700,
>       Julian Elischer said words to the effect of;
> >
> > Looking at i386/exception.s
> > one sees:
> [...]
> >
> > Now:
> >
> > would it not make a lot of sense to put doreti immediatly after
> > calltrap: in the same file

It would make little sense to put it immediatly (sic) after calltrap,
since most jumps to it are not from there.

> > so that one could follow the entire picture without having to bounce back
> > and forth between two files?
> I'd say so, yeah.  Its probably there because it used to be alongside
> splz and unmasked pending isa interrupts.

This is correct.  In 386BSD-0.0, it was mainly for handing ICU masking after
return from a hardware interrupt and it was in a file named icu.s.  In
FreeBSD-1, it only handled software masking and was still in icu.s.  SMPog
renamed it to ipl.s and pushed the hardware interrupt masking issues further
away from it.  SMPng pushed the software interrupt masking issues away from
it (using nested includes, ugh).  Its name still suggests that it is more for handling 
interrupts than
traps, but interrupts are a special type of trap and it has nothing to do
with isa or ipls, so it belongs more in i386/exception.s than in isa/ipl.s.
But the nested includes in it don't logically belong there.

> >
> > (also gets rid of the jmp in the common case)
> System calls are probably the common case.  But I'd suggest just put
> it after the trap code at the end of the file and leave the jump.  Its
> super aligned so there would probably be a bunch of nops to plow through
> anyway.

Yes, it belongs near the end of the file, perhaps in the same place that
it was included.  I found that having all the exception and interrupt
handling routines close together (on the same page?) made significant
differences for microbenchmarks on i486's (presumably because the i486
L1 cache is so small or direct mapped).  Better not change the order
without running some benchmarks on old machines where this matters,
though SMPng may have messed up the order or locality without really
trying.  (Micro-pessimizations were swamped by macro-pessimizations in
SMPng so I didn't notice them, but I noticed micro-pessimizations for
splitting the UPAGES from the stack.)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to