Talk:DEC Alpha/Archives/2014

What are those ISA addition letters?
What do the different ISA letters stand for? Also, the entire table could use a chart, for those who might not immediately recognize that "BSide" equals "Backside."

MSTCrow 00:56, Jun 4, 2004 (UTC)


 * The letters in "ISA" stand for "instruction set architecture". The letters in the abbreviations for the various extensions to the Alpha ISA stand for what the section titles say they do, e.g. "Byte Word eXtensions" for BWX, "Motion Video Instructions" for MVI, etc. Guy Harris (talk) 02:50, 13 March 2014 (UTC)

Epicode
Hi, all.

I am new to Wikipedia... so if I commit a fox pass, please forgive.

Do the production versions of the Alpha support Epicode?

I am an embedded systems designer and I read with great interest an article in Byte Magazine years ago speaking to the ability of the Alpha to take on any instruction set, not just that of the VAX with Epicode. I was trhilled and thought this was indeed the computer architeture to take DEC 25 more years. Want to make a CDC6600? No Problem!

Time passed and the Alpha came out, but when I received an Alpha Data Book, it was not spoken about, nor have I seen anything in the press since the Byte article which preceded (if memory serves) the release said nothing about Epicode.

Can anyone tell me if the Epicode architecture was actually implemented?

Broh. (Broh-dot)


 * AFAIK, Epicode was a DEC PRISM thing. Epicode evolved into PALcode on the Alpha, which was only used to hide differences between platforms and processor variants (ie. a kind of hardware abstraction layer) and not to completely redefine the instruction set. Letdorf 10:03, 25 July 2006 (UTC).


 * And I suspect Epicode wasn't much more than PALcode was; a certain range of Prism instructions would trap into a special Epicode mode, with its own register set (so you don't have to save registers when entering Epicode or restore them when leaving Epicode) and perhaps with some special Epicode-mode-only processor-dependent instructions letting you do stuff, on that particular processor, that you couldn't do in regular code. A given Epicode instruction might be available on all Prism processors, but would trap to a different Epicode routine on different processors.  (I think late System/390 processors, and z/Architecture processors, have a similar concept, called millicode.)


 * I doubt that Epicode was at all involved in the instruction decoding stage, so you couldn't make the processor support an arbitrary new instruction set. The Byte article might have claimed that, but it may have been written by somebody who completely misunderstood what Epicode was. Guy Harris (talk) 22:08, 27 December 2013 (UTC)


 * Either that, or they were talking about FX!32, which implemented other instruction sets by translating machine code from those instruction sets to native Alpha instructions and running the generated Alpha code on the hardware. That, however, is not a concept unique to Alpha; binary translation has been used on a number of source and target instruction sets. Guy Harris (talk) 22:16, 27 December 2013 (UTC)


 * And the PRISM System Reference Manual's discussion of Epicode makes it sound very much like PALcode, and that manual explicitly says that PRISM does NOT provide a VAX compatibility mode. It says that Epicode can be used to implement some PRISM instructions, and that whether a particular instruction is directly implemented in hardware or traps to Epicode is processor-dependent. Guy Harris (talk) 02:46, 13 March 2014 (UTC)