>I think trap.c would be easier to work with or extend to other
>instructions, l.s might give better performance. 

That was my concern as well.  The Alpha compiler doesn't optimize much.  Not that optimization is going to matter much on an EV4.
The problem I'm running into now is that by the time we get to the illegal routine in trap.c, obtaining the faulting instruction isn't so easy.  From the Alpha Architecture Reference, 19.4.2:

"...The saved PC at(SP+00) is the address of the instruction after the instruction that 
caused the bpt, bugchk, gentrap, and opDec synchronous traps."

So it looks like trap() in trap.c doesn't actually get passed the faulty instruction, but just the contents o a0...a2, etc.  I'm thinking the best way to do this without making sweeping (and slow) changes will be to test for and potentially jump to the emulations from illegal0 in l.s, and let the existing code handle the exceptions.

>PALcode would be probably the best option if it was properly patched during boot, but I
>don't know where one might get apropriate SDK nowadays.

I've got the EBSDK, which was the PALCode developer's kit from the AlphaPC boards.  I don't think there's any pressing need to patch up the PALCode though.  The OSF/1 PALCode that Plan 9 runs with is already designed for UNIX-like systems.  Besides, since they're all implementation-specific, it'd be a bad idea to try to run the EBSDK PALCode on a GS-series machine, should anyone want to run Plan 9 on one in the future. :)

>Good luck with Alpha hacking, and remember about memory barriers...
>("Program Counter is not reliable source of information about which
>instruction caused the exception" - It's like a mantra in Alpha
>manuals...)

Thanks for the tip!  I'll keep it in mind.

-Ben