Gabriele SveltoMay 24
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.
Show thread🇺🇦 haxadecimal 🚫👑6d ago
@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.
Show threadRaffzahn6d ago

@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

Show thread🇺🇦 haxadecimal 🚫👑6d ago
@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.
Show threadRaffzahn5d ago

@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...

Show threadRaffzahn5d ago

@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.

Show thread★ STMAN ★ 🏳️‍🌈

@Raffzahn There is a subtile difference between a state diagram, and a program code, but I admit these concepts are close, but not equal.

- Code execution needs instruction fetching at the PC memory location and then its decoding, then its execution, and one instruction only does a specific thing.
- While microcode words are function of a state variable, and you can do many parallel things during a single state by activating many output bits of the truth table controlling assets.

@brouhaha

May 26 at 6:03pmWeb
Show thread🇺🇦 haxadecimal 🚫👑4d ago
@stman @Raffzahn
That's what microcode does, to implement the FSM, except that an instruction doesn't have to only do one thing. Macroinstructions often do more than one thing, so it's not at all a stretch for microinstructions to do so as well.
As with pipelined processors in general, usually the microcoded control unit executes microinstruction n while fetching n+1 (or another branch address).
A good introduction can be found in _Bit-Slice Microprocessor Design_ by John Mick and Jim Brick.
Show thread🇺🇦 haxadecimal 🚫👑4d ago
@stman @Raffzahn
Common examples of processors in which instructions do multiple things include VLIW processors, like the Intel & HP Itanium, and some DSP processors, like the Motorola DSP56000 series. There have been many others; they simply aren't as common as e.g. x86 and ARM.
Show threadRaffzahn3d ago

@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.