🚀 go-pugleaf

In article <By0xy0.FsA.2@cs.cmu.edu>  writes:
> 
> woodacre@mips.com (Michael Woodacre) writes:
> 	[ in reference to PALcode ]
> >Can you explain how this is different from kernel code with interrupts
> >disabled on any other risc processor?
> 
> Think of it as a supervisor state. This state doesn't just have
> interrupts disabled:  it also has direct access to a large variety of
> implementation-specific internal registers. For example, TLB reloads
> are done by PALcode, whereas the "normal" code in the OS need only
> know architectural things (things that remain constant across
> implementations). 

This is effectively provided by the coprocessor 0 enable bit on a MIPS  
architecture machine. (Which is probably ignored in kernel mode but not  
supervisor mode or vice-versa (I can never remember which is which).) In any  
event, it is a reliability/robustness issue not a functionality issue. I can  
write my kernel to not use any of the protected features except in a small  
set of routines through an architected interface. (And in fact RISC/OS on  
MIPS platforms did this for many things because the coprocessor 0  
functionality is quite different on the various R-series implementations.)

> Also, PALcode can be entered from user state - you don't need to do a
> system call, with its heavy-duty state-change overheads.

This is an implementation issue. (And certainly if you spec a  lot of  
lightweight primitive operations via sys-or-PAL calls, you better make them  
fast.) The only significant difference between MIPS syscall and Alpha  
PALcall in terms of speed is that PALcall has many exception vectors where  
you need some dispatch code on the MIPS. (Anybody have cycle counts?) Even  
this is not an architectural issue. I could implement an Alpha processor  
with a single exception vector and I could implement a MIPS processor with  
16 million of them (or so). (And there's the 'ol RISC argument that the  
single vector might be faster. Supposedly Cray's only have one exception  
vector though...)

The point I'm trying to make is that DEC's "Privelleged Architecture  
Library" is probably a good abstraction but it doesn't require big changes  
in hardware. (Nor is it all that original.) 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.
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson