Hacker News Reader

> in what ways is the design of microcode instruction-sets for CISC-ISA CPUs, different from the design of outward-presenting RISC ISAs?

There's a lot of variability in microcode designs, but based on the microcodes I've examined closely (various IBM 360 mainframes, Xerox Alto, 8086), there are several characteristics.

Microcode is usually much wider than instructions (21 bits for the 8086, over 100 bits for some IBM machines). Microcode is usually doing several things in parallel. An instruction set is designed to be general-purpose and "make sense", while microcode is nearly incomprehensible and does whatever bizarre tricks are necessary to implement just what is needed for the instruction set. (One important factor is that microcode doesn't need to be backwards or forwards compatible, so designers can do whatever they want.) Microcode's relationship with memory is different since you're dealing with address and data registers, not abstract reading and writing of memory. Microcode needs to worry a lot more about timing. For instance, in the 8086, an ALU operation is set up a cycle before it happens. In the Xerox Alto, conditional branches happen a cycle after you issue them.

For your specific question about registers, much of the 8086's microcode ignores the specific register names, saying things like move the generic source register to the ALU. The hardware selects the appropriate register based on the instruction, direction bit, etc. (I'm in the middle of writing a blog post about this.)

For a more modern look at microcode, the book "The Anatomy of a High-Performance Microprocessor" describes the AMD K6 processor in way more detail than you'd want.

There's two vague categories of microcode, with different answers for each.

This article is an example of vertical microcode. 15 to 64 bit wide instructions that look a lot like a regular assembly, just what you'd expect after the first stage of decoding, with the some of the encoding wrinkles ironed out. Source register always in the same place in the bit pattern kind of stuff. This will normally look a lot like the host ISA; two address versus three address kind of stuff. Might still have memory RMW ops if it's a CISC ISA.

Then you have horizontal microcode, which is a wider word. I've seen 64 bits to 256 bits. It's simply most of the control lines for the processor uarch state concatenated together. You'll have sometimes dozens of fields that always mean the same thing, and when you look at the schematic you clearly say to yourself "oh, these three bits are this mux, the four bits next are this mux, this next line is an enable", etc."

It's not uncommon to have both. The 68k's main microcode looks vertical, then has a horizontal microcode for it's "nanocode" deeper in the core.

Could you explain the flow or how the vertical and horizontal microcode interact? If a bit pattern is read into the instruction register that pattern is used as an index into a translation ROM? Is that translation the horizontal microcode that drives everything including further lookup and translations to mico-ops i.e vertical microcode?

So go to the 6502 for an example which has a decode ROM which is similar in concept, but far more primitive and fixed rather than programmable..

Instructions take a length of time from 2 to 7 cycles, with an additional cycle under certain conditions.

The decode ROM determines what is done for each of those cycles and allow the modularization of circuity for common purposes among instructions.

I think CPUs such as the Z80 and definitely the 68000 had more sophisticated mechanisms where the microcode was really a sub-CPU executing actual micro-instructions.

> I've also been curious whether there are any lessons in the design of microcode ISAs, that can be applied in the design of abstract-machine bytecode ISAs.

I think something like Itanium's VLIW breaks this barrier between microcode and ISA more than other ISAs and the lesson was it's too difficult to port legacy software to it, so we keep going on with CPUs that continue to support the appearance of an in-order ISA initially developed in the 1970's with more and more frankensteined extensions as time goes on.

Microcode instruction sets have different engineering trade-offs to the user-visible ISA. In microcode, memory bandwidth isn't such an issue so microcode instructions can be relatively wide (21 bits compared to 8 for the 8086).

The microcode can also be relatively difficult to write. For example, in the 8086 microcode I saw one place where there is a "DEC2 tmpc" microinstruction (subtract 2 from tmpc), then tmpc is loaded after that, after which the correct result is available (this makes sense when you think about how the ALU works on the chip, but in any normal ISA you have to load the values into the operands before you perform operations on them).

There's nothing in the 8086 microcode which creates any temporary undetermined states as far as I can tell but there may be combinations of microinstructions which could create a race condition.

In my experience, CISC instruction sets are primarily a way to create compact representations of fairly long instruction words.

That arises from the way in which the register file, the ALU, the flags, and various counters (instruction, stack, Etc) are laid out in logic and the buses between them.

Something that I find really fun to do is to experiment with compute architectures. I first started playing around with this with an Altera DE2 board, then the Spartan III dev board from Xilinx, and these days with a Lattice Ice40K board (Icebreaker, and soon ULX3S board). There are a number of "soft" CPUs where you can play around with this to your hearts content (given you have enough gates in your FPGA, which is getting easier and easier these days).

CISC instructions are, as the name suggests, are simply "subroutine calls" or "macro calls" (depending you what era of computing you were introduced to) into an underlying machine that can move bits around each "clock". RISC is essentially making that level of instruction available directly to the compiler.

The most infamous version of exposing what is essentially microcode to the compiler was, in my opinion, the Itanium which has a really flexible native instruction set that the compiler mixed and matched into pseudo instructions which it used to compile code into. A more elegant version of this was the Xerox PARC "D" machines which allowed you to load an instruction set prior to booting into your actual applications. This made Mesa[1] development interesting because you needed the appropriate instruction set to go with the Mesa compiler you were using.

[1] Mesa was Xerox's modular development language that inspired Wirth's Modula 2 (I believe that was the ordering, Wirth might claim it went the other way)

>" There are a number of "soft" CPUs where you can play around with this to your hearts content (given you have enough gates in your FPGA, which is getting easier and easier these days)."

Could you make some recommendations for a newcomer in terms of ease of use and good tooling? Thanks.

Perhaps the easiest way to get set up is to get a ULX3S from Crowd Supply[1], and then download the "official" tool chain from Github[2]. This project[3] is a good hackable target. There are interesting examples for this board here[4].

A better collection of links are here: https://ulx3s.github.io/

You'll need to develop some HDL skills (which is a deep dive) but it is well worth it to make experimental computer architectures!

[1] https://www.crowdsupply.com/radiona/ulx3s

[2] https://github.com/ulx3s/ulx3s-toolchain

[3] https://github.com/SpinalHDL/SaxonSoc/tree/dev-0.1/bsp/radio...

[4] https://github.com/emard/ulx3s-examples

Thanks for the recommendation this is a great list of links. You states: >"You'll need to develop some HDL skills ..."

Do you have some of recommendations on where to begin with that?

Thanks

Well there are two popular HDLs, one is Verilog and the other VHDL. In my experience Verilog is more popular both in github repositories and around the industry, so you could get something like "Verilog by Example"[1] which is a pretty concise jump into building things with Verilog.

There are a number of universities that put their Verilog course notes on-line and that is a good source of reference material as well.

[1] https://www.amazon.com/Verilog-Example-Concise-Introduction-...