🚀 go-pugleaf

In article <1992Nov19.204209.6619@nntpd.lkg.dec.com>, dipirro@star.dec.com (Steve DiPirro) writes:
|>In article <lgnfc3INNqnt@spim.mti.sgi.com>, woodacre@mips.com (Michael Woodacre) writes...
|>>In article <1992Nov18.210416.27212@nntpd.lkg.dec.com>,
|>. . .
|>>Can you explain how this is different from kernel code with interrupts
|>>disabled on any other risc processor? For instance, an R4000 can
|>>implement uniprocessor-atomic "instructions" which are sequences of
|>>MIPS instructions to implement complex functions by running code
|>>in kernel level with interrupts switched off.
|>
|>There are certainly similarities. PALcode "instructions" actually appear
|>as single instructions in the Istream which is handy for debuggers, etc.
|>PALcode runs with interrupts disabled, Istream memory management traps
|>disabled, and complete control over machine state. The environment allows
|>more flexibility and more possibilities than merely running in the "standard"
|>environment with interrupts disabled.

Another difference is that the instructions available to PALcode are not
architected.  The assumption is that PALcode will use standard Alpha
instructions plus up to five additional instructions specific to the
implementation.  Also, no cpu registers are defined.  The PALcode is what
implements standard things like interrupts triggered by implementation
specific mechanisms.  So, the CPU implementations are free to be as creative
as they can be in making the basic instruction set fast as well as making
PALcode fast.

On the other hand, if you think that interrupts should dispatch via an
interrupt vector, then you can implement PALcode to do that.  Or if you
prefer that on an interrupt you jump to location zero where a special
instruction is executed to determine the source of the interrupt, the
`hardware' can be implemented that way as well.

The PALcode shipped with the current hardware supports two styles of
hardware interface for things like interrupts, page faults, etc.  There
are only a handful of PALcode calls that are common between the two
styles.  While it is possible that an operating system might include
its own PALcode (it can be switched), given the possibly significant
differences in the PALcode environments for different chips and systems,
this is probably not going to happen.  However, for imbedded applications,
you will need to develop PALcode specific to the application.  One might
expect that some applications that don't need interrupts or virtual
memory or other overhead might implement the entire application without
any sort of PALcode at all.

Basically, PALcode is one of the features that makes the Alpha architecture
unbiased toward VMS or unix, but instead biased totally toward performance.

mulp [jack of all trades, master of none]
DEC