@gabrielesvelto yes, it's only a part, but it starts there. The irregular instruction sizes caused problems when instructions straddled cacheline boundaries, etc. Everything after that: superscalar execution, OOOE, all got harder because the simplest case, single instruction in-order, was already non-deterministic.

@hyc it's definitely an added source of complexity for x86 implementations. I remember reading this a few years ago: https://blog.trailofbits.com/2019/10/31/destroying-x86_64-instruction-decoders-with-differential-fuzzing/

@gabrielesvelto seriously, GET A FUCKING BLOG.

#getafuckingblog

@gabrielesvelto this was fascinating, thanks!

@krzysdz @gabrielesvelto Back in my day at least there was lots of latch-based design. The time borrowing through the transparencies was used to make up for timing miscorrelation on the datapath. I remember timing limiters that could be 5+ cycles long.

However, that presumes you have tighter constraints on the clock path. Even a faster-than-model clock path could slow you down.

@gabrielesvelto great thread! Thanks!

@shelldozer @grumble209 @gabrielesvelto I've probably had more of those UltraSPARC-II's pass through my hands than any other CPU. (I had four maxed-out E4000's at home at one point.)

I had a friend in the 90s who had a job at DEC one summer writing a program that output random but legal C, to stress-test their compiler.

@gabrielesvelto The 6502 had no bugs. Just some undocumented features.

@mdione @gabrielesvelto The small flash chip that holds the UEFI and other firmware components also has the µcode patch on it. The chip sits on a simple bus (usually SPI), so it can be directly wired into the CPU and accessed immediately after the system comes out of reset.

@gabrielesvelto how about a blog post ?

@usul je n'ai pas l’énergie pour fair un blog post, ça serait très long