🚀 go-pugleaf

In article <DOCONNOR.92Nov20095251@potato.sedona.intel.com> doconnor@sedona.intel.com (Dennis O'Connor) writes:
>
>dipirro@star.dec.com (Steve DiPirro) writes:
>] ... 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. 
>
>Sounds like a microcoded instruction to me. Except, of course, that
>there's no guarantee of what PALcodes are available on a particular
>system, and that the microcode may be external to the chip.

No, it's not really microcode at all.

When the processor is running in PAL mode (as a result of executing a 
call PAL opcode or taking an exception) the processor is fetching and
executing instructions as usual, but:

1. The I-stream is _physically mapped_ (otherwise, you can't do ITB 
   manipulations)

2. You can access the five implementation specific opcodes (that cause a
   reserved opcode exception if executed in non-PAL mode)

3. Interrupts are disabled (so you can do atomic operations)

Otherwise, when running in PAL mode, it is business as usual:  you can use 
all of the Alpha instructions.  PALcode is just code written to run in 
PAL mode (i.e. it uses the five special opcodes to manipulate the machine 
state).

PALcode isn't necessarily stored in any special place:  it's fetched into
the processor for execution in the same manner that all other code is 
fetched (it gets cached in the I-cache, etc).  Most systems load PALcode 
into main memory from ROM, disk, or network, just like you would load 
boot code.
-- 
Andrew C. Payne
DEC Cambridge Research Lab