On Sat, 4 Dec 1999 19:03:59 -0500 (EST) 
 Andrew Gillham <gillhaa@ghost.whirlpool.com> wrote:

 > 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?  e.g. Windows NT has PALcode embedded in it somehow?

No, ARC console comes with the NT PALcode.

It is possible to run on the bare hardware.  But, there are some things
that the PALcode does that are *quite* model-specific:

	- various cache issues
	- various interrupt issues (e.g. issuing EOIs, interrupt
	  routing, etc.)
	- machine checks generated by the core logic
	- machine checks generated by the I/O processors

...and the list goes on.

This doesn't include the processor-model specific stuff:

	- TLB differences
	- cache differences
	- trap differences

..and the list goes on here, too.

Basically, the PALcode provides a very nice abstraction to the hardware
which makes it actually reasonably possible to port the OS to the hardware
(and, geez, even Digital UNIX is horribly complex in the hardware specific
stuff even *WITH* the PALcode).

Running on the bare hardware would be a real pain.

Now...

The NT PALcode *is* documented ... pretty well in the Green Book, and
probably even better in the Red Book.  It might not be totally unreasonable
to think about a NetBSD/arcalpha ... however, the NT PALcode comes with
some caveats:

	- It's very geared to NT's kernel model
	- Memory management is essentially MIPS-like, and also
	  limits the virtual address space to 32-bit (except for
	  some virtual address extension hack used to get at the
	  hardware in the kernel)
	- It's ... amazingly large and complex.  The number of
	  NT PALcode calls is simply mind boggling.

 > This sounds familiar, but I'm still confused about it.  Why can't the
 > PALcode be reverse engineered, or otherwise re-written?

Writing PALcode for the Alpha is not in the business you want to be in.
It's a lot (a lot a lot a lot) of very carefully written assembly code.
Instruction counts in many operations matter.  It's a daunting task.

 > Maybe the explanation is missing some details.  I have typically thought
 > of the "SRM is required for NetBSD/alpha" along the lines of "OpenFirmware
 > is required for NetBSD/macppc." (e.g. to boot and get started)
 > The impression I have now is more like "SRM is required for NetBSD/alpha"
 > along the lines of "BIOS is required for Windows." (e.g. calling the BIOS
 > all the time for services)

Note, SRM isn't really required, per se.  NetBSD/alpha *DOES RUN* on
a platform that doesn't have SRM; it's a parallel multicomputer called
the Avalon A12.  It's not a DEC machine.  It does't have DEC console
software.  The console software it does have, however, provides OSF/1
PALcode, and the A12 console software also complies with the Alpha
Console Architecture as described in the architecture manual.  SRM
also complies with this (obviously).  The AlphaBIOS console software
complies with ARC (originally a console specification for MIPS systems),
and not with Alpha Console Architecture.

If someone were to write some free console software, please pay careful
attention to the Green and or Red Book's description of the Console
Architecture.  The Console Architecture doesn't suck.

Now, strictly speaking, the console software and the PALcode are
distinct entities.  When NetBSD calls the PALcode, it's not calling
the console software, really.  It's calling the PALcode.  There is
a standard PALcode operations called `swppal' which enables you do
switch to a different PALcode image on the fly (the NetBSD/alpha
boot loader does this; SRM comes up in the OpenVMS PALcode by default).

However, the PALcode is called literally all the time.  Take a NetBSD
kernel image sometime, pump it though objdump --disassemble, and grep
for the "call_pal" instruction:

bishop:thorpej 53$ pwd
/sys/arch/alpha/compile/GENERIC
bishop:thorpej 54$ objdump --disassemble netbsd | grep -c call_pal
4807
bishop:thorpej 55$ 

Some of those are in key places, like, for example, all traps (syscalls,
interrupts, page faults, etc.).  The C library uses it, too.  It's how
system calls are made (the `callsys' PALcode operation).

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