On Sat, 4 Dec 1999 19:24:19 -0500 (EST) 
 der Mouse <mouse@Rodents.Montreal.QC.CA> wrote:

 > think the PALcode itself is very hardware-specific.  (That is, it won't
 > work to, for example, put AlphaPC164LX PALcode on anything but an
 > AlphaPC164LX.)  Very loosely put, custom microcode. :-)

Ah!  But it's not microcode!  :-)

It's written in the same instructions that you and I as appliation
and kernel developers write code in, plus a few that can only be
executed while in the PAL mode (PAL == Privileged Architecture Library;
it runs in a separate privilege level even higher than kernel privilege).

It also has access to process-specific internal registers, i.e. ones
not included in the normal register file.

If it were microcode, it wouldn't be written in the user-exposed
instruction set.

It's also very obvious when you're executing PALcode.  PALcode is
executed *only* when:

	- an exception occurs
	- the call_pal instruction is issued

Dammit, we're RISC!  No microcode!  :-)

 > > I have typically thought of the "SRM is required for NetBSD/alpha"
 > > along the lines of "OpenFirmware is required for NetBSD/macppc."
 > > [...]  The impression I have now is more like "SRM is required for
 > > NetBSD/alpha" along the lines of "BIOS is required for Windows."
 > 
 > The latter is more or less the impression I have too, for what that may
 > be worth.

It's slightly different than that.  Windows uses the BIOS to talk to
peripherals, generally.  It doesn't require the BIOS to simply deal
with normal processor operations.  BIOS is more analogous to "console
software".  PALcode really is something different.

To be honest, PALcode is one of my favorite features of the Alpha
architecture.  It allows you as an application or kernel programmer
to program on the bare metal with a nice RISC instruction set, yet
saves the kernel developer from having to deal with REALLY nasty
deatils that one often has to deal with on RISC systems (like, say,
the MIPS; how I wish the MIPS had PALcode ... dealing with different
variations of the MIPS processor can be a *real* pain sometimes).

Plus, the PALcode is written by the processor designers.  Those
people know how the hardware works, and all of its quirks and
gotchas (or, at least, they'd better :-) ... I trust their TLB
reloading code more than I would mine, I think :-)

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>