Subject: Re: bcopy, bzero, copypage, and zeropage
To: Jason Thorpe <>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 12/14/1996 17:00:19
Jason Thorpe writes:

>Actually, in that forum you _didn't_ mention exception handling on the
>MIPS (although you did mention VMS :-).  One thing I will point out...
>In that mail you also said, and I quote:

>   The maintenance headaches of low-level self-modifying code are obvious.

uh, the paragraphy you quoted said, in full:

   The maintenance headaches of low-level self-modifying code are obvious.
   I think replacing one _entire_ (leaf) routine with another is much less
   unpalatable, from a software-engineering perspective, than frobbing
   individual instructions.  To be safe, one needs a reliable mechanism to
   ensure that the tuned copy fits in the location it's being copied
   to. This comes a method to find the length of a function, and assert().
   (mips CPUs already _have_ to do something like this to set up
   exception vector code, so perhaps that's, uh, lowered my tolerance
   for this particular hack.)

> which I say "Exactly."  I don't want to be debugging some bit
>of code, realizing "Oh, this code modifies itself... Whee, fun!"

Have you heard `quoting out of context'?

I'm not advocating ``self-modifying code'' in the usual sense of the
term, which includes modifiying arbitrary instructions in the code
stream.  I'm talking about replacing an entire (leaf) function with a
specially-tuned version at runtime, as part of kernel initialization,
before main() gets called.  I hink a more apt comparison is to OO
compilers that dynamically inline specific versions of a function.

>I don't like that approach... Ay "my" site, I like to rip out all the
>drivers that I know I'm not going to use on a given machine.  We
>typically have "classes" of machines:
>        LESSER_VAMPIRE  i486 EISA machines with same hardware used as
>                        workstations, build servers
>        VAMPIRE         P6 PCI machines with same hardware used as
>                        devel platforms, build servers
>        WHITNEY         Kernel for the cluster machines (same hardware)
>...etc.  We rip out the unneeded drivers, set certain parameters
>(like my build server gets a bigger buffer cache, etc.)  Machines
>in the same "class" get the same kernel... But are, in all other
>ways, tuned for that class.

Hey, I resent that :) I ``rip out the unnneeded drivers'' too.  But
your argument -- and Chris's -- presupposes that __EVERYONE__ can
partition their machines into "classes" which happen to have
_HOMOGENEOUS_ cpu types.  That's just not so in general.  (Or at
least, it isn't for me.)  Pretend I said so in terms as strong as you
feel comfortable with.  I have both P5 and P6 "servers", and I'd like
to use the same kernel on all of them.  I'd also like to be able to
tune a bcopy() for the P5s, which have cache allocate policies which
mean a nonstandard bcopy() is a win.  And I'd like to use that tuned
bcopy() for  copyin() and copyout(), which is currently dominating
my benchmark-of-interest...

>...and how do you do that?
>#ifndef GENERIC
>	/* loop that modified code here */

The mips port has code that sets a vector of function pointers into
locore. (it's acutally a struct, to get the correct prototypes).
(note: This is at the next layer up from the exception handlers.
They really do get copied to the locations the hardware jumps to
in response to exceptions.)

I'd replace that code, which initializes a vector of function pointers,
with code that copies the _bodies_ of functions.
Ignoring the modification of text space, I fail to see how this is
more gross than #ifdef's on machine type scattered all through locore.

>Not necessarily true.  In this case, we're talking about the m68k ports,
>and so far, all the m68k workers have liked what JT and I have been
>doing :-)  I mean, on a sun3/60, you really do need to optimize things
>like page zero/copy :-)

> > In any case, given how NetBSD works, this isn't likely to happen
> > unless the relevant portmasters agree on it -- which doesn't seem
> > likely at the moment.

Hey, I don't use 68ks anymore, but I liked what I've seen too.
Where did I say I didn't?