Regarding the Raptor Lake bug I received a couple of messages from confused users that had read articles on Tomshardware and Neowin. They asked about erratas and microcode updates which puzzled me, because that was part of my early investigation into the bug and we know that the failure is not caused by a known errata and microcode updates cannot fix broken CPUs. So why did they ask? As it turns out it was slop. Both articles are 100% slop full of confusing and inaccurate claims.
@stman @gabrielesvelto
Vertical microcode really is a lot like assembler, but the majority of microcoded systems (including microcoded microprocessors) use horizontal microcode, which usually takes fewer words of microcode, but much wider. Overall it's usually more total bits, but faster. Horizontal microcode almost always accomplishes more work in a single cycle.

@brouhaha

I'd say it's the same in either case. Horizontal is just more capable by complying with more implied restrictions. In consequence one needs to think even more about each line.

@stman @gabrielesvelto

@Raffzahn @stman @gabrielesvelto
The few vertically microcoded systems I'm familiar with take _many_ cycles to interpret one macroinstruction, and the cycle time is slow because the narrow, highly encoded micro word needs more levels of logic to decode into the hardware control signals.
Most horizontally microcoded machines take very few cycles per macroinstruction, unless the macroinstruction is quite complex.

@stman @brouhaha @gabrielesvelto

Well, isn't it the same way as an Assembler is specific to a CPU? And boy there are CPU's out there at least as weird as some micro code engine...

@stman @brouhaha

Not really, Of course there are may micro code architectures that use a full figured PC - as well as such with next-pointers or such coding (one or more) next addresses within their word.

@stman @brouhaha

Is there? to me they are just different representation of the same. A CPU is also just a FSM - like any other real existing hardware. The usual description being procedural doesn't make a difference - in fact, just think how many different ways of programming there are which in the end will be executed by a plain CPU :)

And no. For one, having a PC is just the most common way, not the only one there is. More important, even a 'simple' instruction of a 'simple' CPU, like the 8080, does several things at once. Take SBB, SUB and CMP. These 3 instructions handle the same functions in different ways.

SBB
- takes two input values
- takes a borrow flag
- subtracts them using the borrow
- stores the result
- stores a resulting borrow
- updates flags

SUB does the same, but

- sets the borrow input to zero before subtracting

CMP again the same, but

- as well sets borrow input to zero
- does not update borrow
- does not store the result

Doesn't that sound quite like those 'micro instructions' handling different output bits / functions in parallel and in reaction to input bits?

The fact that there is a decoding stage is just a storage optimization. Kind like the Thumb instruction set of older ARM architectures was made used to compress much used instructions variants into a shorter form. Internally going thru a decoding stage to create the long form.

CPU instructions are usually nothing more than compacted representations, leaving out all the variations a wide word would have to carry without using.

Or from a total different point of view one can think of it like Japanese writing:

- There are Kanji - Boom, one symbol a whole complex meaning

- And Kana, Mora (Syllables) where usually more are needed for a word, they com even in two variations:

- Hiragana which still go along the meaning, while

- Katakana go strictly by pronunciation

- And finally Romaji.

All different levels of explicite detailing for the same thing.

@stman @Raffzahn
That's not what I was saying.
An FSM has a current state, and depending on inputs, a transition occurs that results in a next state, which in turn becomes the new current state.
In many microcoded systems, the state encodings are arranged such that the most common choice of next state from any given state encoded as 'n' is the state 'n+1'. The current state value is stored in a hardware register, conventional.called the micro program counter, which literally does count,
1/
@stman @Raffzahn
just like a normal program counter, except that it gets loaded with a different value on a 'branch' microinstruction, when next state of state 'n' is not 'n+1'.
That is why I say that the microprogram (mapping from current state and inputs to next state and outputs) is entirely analogous to assembly language, even though the microinstructions are usually not very similar to macroinstructions (especially in horizontal microcode).
2/

@stman @Raffzahn
The micro program counter in such a system is often referred to as the ΞΌPC (or uPC), and is entirely unrelated to the macro-level PC.

It's true that the macro-level PC is a state variable of the state machine that is the ENTIRE machine, but it's not directly a state variable of the micro program control state machine.
3/

@stman @Raffzahn
In a horizontally microcoded machine, the micro control state machine outputs might include bits meaning "increment PC", "load PC from datapath", and "load PC from macroinstruction stream".
The macro level PC is a "peripheral' of the microprogrammed control, just as the other macro level data registers, stack pointer, etc.
4/