4 ms·

> Even though incl is a single instruction, it's not guaranteed to be atomic. Internally, incl is implemented as a load followed by an add followed by an store.

> Even though incl is a single instruction, it's not guaranteed to be atomic. Internally, incl is implemented as a load followed by an add followed by an store. I've heard the joke that RISC won because modern CISC processors are just complex interfaces on top of RISC cores, but there really is some truth to that, isn't there?

terafo 5y ago
> but there really is some truth to that, isn't there? There was an Arm version of AMD's Zen, it was called K12, but it never made it to the market since AMD had to choose their bets very carefully back then.
- 7speter 5y ago
  Isn’t amd still hamstrung by their size relative to their competitors? At least in different ways than 5 years ago. The latest examples of amd having to choose carefully include them having to choose what products to focus on with their agreed upon capacity at tsmc last year (more zen chips to make gains ops intel, more gpus to make market share gains vs nvidia and or dedicating as much capacity to console apus for Sony and Microsoft. Also seems to be the case when they tried to make a budget gpu and had to settle with strapping laptop gpus to desktop pci cards and suffering heavy derision from gamers because, as I understand from people familiar with the way chips are designed, a design for a new die can cost tens of millions of dollars and amd, unlike intel and nvidia, are still too small to just crank out new costly designs at will.
  - dralley 5y ago
    Chip design cycles are long enough that you could argue they're hamstrung by their size 3 years ago.
monocasa 5y ago
Eh, it's overstated. Classic CISC tended towards microcode because it allowed complex operations in way that didn't consume main data memory bandwidth. RISC in a lot of ways was the recognition that when you can assume ubiquitous instruction caches for your ISA you can let your ASM writers just write what was microcode previously. Hot loops will be cached and out of the way of data bandwidth, but now there's no arbitrary limits to microcode program size. So RISC was a revolution over CISC, but CISC arguably always had 'a RISC core' inside, even before RISC was a thing.
- zozbot234 5y ago
  RISC does not resemble microcode all that much, VLIW is a lot closer to the mark. VLIW is also heavily μarch-dependent, much like microcode.
  - monocasa 5y ago
    There's two kinds of microcode, vertical and horizontal. RISC resembles vertical microcode that can expand to horizontal microcode looking uops in a single decode stage. Having coded all three (vertical ucode, horizontal ucode, and RISC decode stage HDL) the biggest difference I've found is that RISC tends to be three address, and CISC vertical microcode to be two address. I think that comes from the same place as assuming the presence of an I$. The gate count niche that lets you have a large SRAM block for cache also let's lets you have a large SRAM block for your register file. You're therefore not as dependent on a single accumulator or two tightly coupled with your ALU like earlier CISC designs had to encourage.
    - zozbot234 5y ago
      Three-address designs trade off a larger insn word for fewer MOV insns and a more straightforward use of the register file. ("Compressed" insns are often two-reg special cases of a three-reg insn.) It's true that RISC tends to feature a higher amount of fully-general registers (as opposed to e.g. separate "data" and "address" registers) but that seems to be a separate development, possibly relating to the load-store approach.
      - monocasa 5y ago
        They're all related. When you have an accumulator based design with your ALU and registers, that necessitates a two address format. Or else you're not accumulating. If you don't have space next to your ALU except for one register, you're stuck with an accumulator.
- ajross 5y ago
  I'd argue the causality goes the other way. Microcode allows you to do complex things on top of a very minimal execution engine. You might use the same ALU for an add as you would for a multistage multiply as you would for a computed jump, etc... But as CPUs got bigger and suddenly had enough hardware to do "everything" at once, they had the problem of circuit depth. Sure, you can execute the whole instruction in one cycle but it's a really LONG cycle. You fix that problem with pipelining ([R]eally [I]nvented by [S]eymore [C]ray, of course). But you can't pipeline a complicated microcoded instruction set. Everything that happens has to fit in the same pipeline stages. So, the instruction set naturally becomes "reduced". Basically: RISC is the natural choice once VLIW gets rolling. It's not about simplification at all, it's about exploiting all the transistors on much more "complicated" chips.
mhh__ 5y ago
Some but not the whole truth. It's a sort of RISC core, but count the number of micro-ops some things translate to, it appears that some of them are pretty chunky.

terafo 5y ago

> but there really is some truth to that, isn't there? There was an Arm version of AMD's Zen, it was called K12, but it never made it to the market since AMD had to choose their bets very carefully back then.

7speter 5y ago
Isn’t amd still hamstrung by their size relative to their competitors? At least in different ways than 5 years ago. The latest examples of amd having to choose carefully include them having to choose what products to focus on with their agreed upon capacity at tsmc last year (more zen chips to make gains ops intel, more gpus to make market share gains vs nvidia and or dedicating as much capacity to console apus for Sony and Microsoft. Also seems to be the case when they tried to make a budget gpu and had to settle with strapping laptop gpus to desktop pci cards and suffering heavy derision from gamers because, as I understand from people familiar with the way chips are designed, a design for a new die can cost tens of millions of dollars and amd, unlike intel and nvidia, are still too small to just crank out new costly designs at will.
- dralley 5y ago
  Chip design cycles are long enough that you could argue they're hamstrung by their size 3 years ago.

monocasa 5y ago

Eh, it's overstated. Classic CISC tended towards microcode because it allowed complex operations in way that didn't consume main data memory bandwidth. RISC in a lot of ways was the recognition that when you can assume ubiquitous instruction caches for your ISA you can let your ASM writers just write what was microcode previously. Hot loops will be cached and out of the way of data bandwidth, but now there's no arbitrary limits to microcode program size. So RISC was a revolution over CISC, but CISC arguably always had 'a RISC core' inside, even before RISC was a thing.

zozbot234 5y ago
RISC does not resemble microcode all that much, VLIW is a lot closer to the mark. VLIW is also heavily μarch-dependent, much like microcode.
- monocasa 5y ago
  There's two kinds of microcode, vertical and horizontal. RISC resembles vertical microcode that can expand to horizontal microcode looking uops in a single decode stage. Having coded all three (vertical ucode, horizontal ucode, and RISC decode stage HDL) the biggest difference I've found is that RISC tends to be three address, and CISC vertical microcode to be two address. I think that comes from the same place as assuming the presence of an I$. The gate count niche that lets you have a large SRAM block for cache also let's lets you have a large SRAM block for your register file. You're therefore not as dependent on a single accumulator or two tightly coupled with your ALU like earlier CISC designs had to encourage.
  - zozbot234 5y ago
    Three-address designs trade off a larger insn word for fewer MOV insns and a more straightforward use of the register file. ("Compressed" insns are often two-reg special cases of a three-reg insn.) It's true that RISC tends to feature a higher amount of fully-general registers (as opposed to e.g. separate "data" and "address" registers) but that seems to be a separate development, possibly relating to the load-store approach.
    - monocasa 5y ago
      They're all related. When you have an accumulator based design with your ALU and registers, that necessitates a two address format. Or else you're not accumulating. If you don't have space next to your ALU except for one register, you're stuck with an accumulator.
ajross 5y ago
I'd argue the causality goes the other way. Microcode allows you to do complex things on top of a very minimal execution engine. You might use the same ALU for an add as you would for a multistage multiply as you would for a computed jump, etc... But as CPUs got bigger and suddenly had enough hardware to do "everything" at once, they had the problem of circuit depth. Sure, you can execute the whole instruction in one cycle but it's a really LONG cycle. You fix that problem with pipelining ([R]eally [I]nvented by [S]eymore [C]ray, of course). But you can't pipeline a complicated microcoded instruction set. Everything that happens has to fit in the same pipeline stages. So, the instruction set naturally becomes "reduced". Basically: RISC is the natural choice once VLIW gets rolling. It's not about simplification at all, it's about exploiting all the transistors on much more "complicated" chips.

mhh__ 5y ago

Some but not the whole truth. It's a sort of RISC core, but count the number of micro-ops some things translate to, it appears that some of them are pretty chunky.