> Which brings us to Christopher Domas' discovery that some VIA x86 Samuel 2 processors had an "Alternate Instruction Set" -- Domas found it independently by f

> Which brings us to Christopher Domas' discovery that some VIA x86 Samuel 2 processors had an "Alternate Instruction Set" -- Domas found it independently by fuzzing. However, the publically available documentation of the time (16 years prior to Dumas's work) did say how to switch to AIS mode, the basic format of the AIS instructions (the needed prefix and that they're 32bit) and how to prevent access to AIS mode was actually well documented. Indeed, support for the "new branch instruction" was actually added to NASM back in 2002. This documentation also states that it is available on all VIA C3 processors (so also stuff like Eden). There are also hints that it was available earlier (eg., the documentation references an instruction being available on the "C2", which I assume is one of the IDT Winchip designs), and I've see rumours of something on the VIA Nano processors. So, a little reading would have saved Dumas quite a lot of time; although it's certainly a good demonstration of how one can go about finding similar features. What wasn't easy to find at the time was the actual AIS instruction set, this has now been uploaded to bitsavers, although it's a somewhat early and incomplete version. > what is the Alternate Instruction Set's relation to uOps? Is the AIS direct uOps, or 1:1 mapping? Or was it implemented by microcode that translated each AIS instruction into multiple uOps, and if so, how was that microcode implemented? The introduction of the now available application note, states that these are the micro-operations, albeit not the entire set: "the VIA C3 processor has a special operation mode where the front end logic can also fetch (selected) micro-operations (versus x86 instructions) and pass them directly to the internal execution unit." The (now available) Alternate Instruction Set Programming Reference states "the VIA C3 processor comprises two major components: a front-end that fetches x86 instruction bytes, and an internal microprocessor that executes these internal instructions." In particular it seems to be a MIPS core with extensions/modifications optimised for emulating an x86 processor - there are instructions with "special control fields to allow most ALU semantics to be specified in a single 32bit instruction" and instructions that are "needed to perform a single-cycle X86 [instruction name] function". Why MIPS? Because the Programming Reference says "There are no MIPS format load/store instructions and no way to perform load/stores to native-mode address space. All load/store operations use X86 address and load/store semantics". Without pulling up a MIPS instruction set, and comparing, it also looks a lot like MIPS (32 registers, constant 0 register etc.,) Notably, you can even interleave x86 instructions and these uOP instructions (with some restrictions), I doubt the internal core is microcoded, the references to "single-cycle" and "MIPS" would seem to preclude that. However, there may not be access to all the possible uOPs (the appnote says "selected" plus there are multiple references to a "translator", and registers used for "Xlator-ucode communication"). Of course, this translator could be hardware that, say, deals with all x86 instructions that map to a single uOP, perhaps skipping the MIPS decode. Thus the translation directly feeds the RISC core with single translated instructions where there is a mapping or with a ucode instruction stream from a ROM where the implementation requires multiple instructions. This format would make the wrapper instructions very easy to implement. If you're interested, there's a wikipedia page - https://en.wikipedia.org/wiki/Alternate_Instruction_Set https://en.wikipedia.org/wiki/Alternate_Instruction_Set - with links to the documentation.