On Tue, Aug 26, 2008 at 19:56, Benjamin Huntsman <[EMAIL PROTECTED]> wrote: >>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.
Well, even on EV4 it could matter. At least I don't remember Alpha having any real cache-coherency (or memory coheency at all), also EV4 and EV5 which don't have BWX can get much higher speed from using 8-byte aligned data, as well as sticking to 64-bit data where possible. All those masking operations are probably slowing the code much. > 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. :) Well, the code for updating PALcode probably should be in bootloader anyway, and HWPRB *does* report processor type, doesn't it? Patching only "illegal instruction trap" should be enough. As for GS-series, at my current job we still have some GS1280 (those were EV7z?) Pity I wouldn't be able to play with those machines.... And could you share EBSDK? If the license permits, of course. > -Ben > -- Paweł Lasek
