🚀 go-pugleaf

zstern@adobe.com (Zalman Stern) writes:
	[ talking about PALcode as abstraction, performance aside ]
>Also, it has a certain amount of  
>intellectual and logistical complexity. There's a layer between the OS  
>writer and the hardware. You must understand the layer, and somebody must  
>provide the code for the layer. If that interface is not a good match to  
>your needs there's going to be a problem.

DEC has published a detailed data sheet for the 21064, from which I
could hope to design my own PALcode. As for actually writing it,
that's just Alpha instructions: the user-mode tools and expertise
more-or-less carry over. So far, this is nicely analogous to writing
the lowest-level OS code on an Rx000.

The big difference is that DEC intends to have multiple Alpha
implementations (and fairly soon) and it is not guaranteed that
PALcode for the 21064 will be appropriate for any/all of the others.
This is the *only* reason why an OS group might decide not to be
in the PALcode business. And then, yes, they might dislike what
they get given, but that's life.

The upside here is that the Alpha could (for example) avoid the
strange situation of the 386 power management modes. What's happening
is that vendors are adding (incompatible!) features which have to be
controlled by some sort of code, and yet the features are supposed to
be completely invisible to the OS. Say what? 

A portable with an Alpha would do power management from PALcode, and
there would be some effort to keep each PALcode/OS interface
unchanged.




-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science