Subject: Re: bcopy, bzero, copypage, and zeropage
To: Jason Thorpe <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
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.)
>...to 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
>...and how do you do that?
> /* 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?