Subject: Re: Q: Compaq, *BSD and 'Linux-only' AlphaBIOS (fwd)
To: Mike Smith <msmith@FreeBSD.ORG>
From: Matthew Jacob <mjacob@feral.com>
List: port-alpha
Date: 12/04/1999 17:09:42
> > > I can't *believe* I'm having to say this again, for the Nth time in as many
> > > months:
> > > 
> > > 	The PALcode included in MILO has severe bugs.  You can't use
> > > 	it to run BSD, or OSF/1 for that matter.  It's remarkable that
> > > 	you can use it to run Linux, and sundry reports of Linux
> > > 	instability when run with MILO make me suspect that, in fact,
> > > 	you can't.
> > 
> > In essence what you're saying is that no Alpha OS is capable of actually
> > talking to the bare hardware?  e.g. PALcode is still required after the
> > kernel is loaded? 
> 
> That's partially correct.  The PALcode requirements for different 
> operating systems are different; that's why there is NT PALcode, VMS 
> PALcode and OSF PALcode.  The NT PALcode footprint is perhaps the 
> smallest, and as a result (according to one of the developers therof with 
> whom I have had conversation) there is a single common PALcode for each 
> CPU architecture.


Anyone interested in this subject should consider purchasing the 'Green
Book'- the Alpha Architecture Reference manual (now in third edition). It
is absolutely indispensible for anyone working in this area.

Insofar as it goes, Alpha *is* a RISC architecture. However, I've always
had a twitch at the corners of my mouth about a "RISC" architecture that
has the same number of general purpose registers as the VAX. Oh, and like
the VAX, requires microcode (PALcode) to run.

The point of PALcode (other than being a pain to deal with) is that for
each flavor, it provides an extremely consistent bare minimum set of
services that each OS needs and is guaranteed across the entire chip
family. It's more than just TLB stuff- it's also initial interrupt
handling as well. If anyone has ever looked at the low level trap handler
for sparc, particularly for dealing with register window over/underflows
while already in kernel mode, you'll appreciate why PALcode is so much the
right thing to do (*it* handles this kind of h/w complexity). That's why
95% of porting effort to a new alpha platform is I/O bus related- not main
processor chip or cache related.

-matt

http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=1555582028