Hacker News Reader

In one of the Mill talks, I've long since forgotten which, someone asks Ivan Godard a question about RISC. His response is something like "there was a brief window in the eighties where if you had a RISC machine you could get the whole computer onto one chip." I don't enough experience to know if this is right, but it strikes me as a nice clean explanation. It also explains why x86 won since then, because a couple generations later it was possible to get the whole computer onto one chip with x86 as well.

(I may have misquoted badly, in particular I'm not sure about the dates)

(edit: I found the talk, it's the last couple minutes of this: https://www.youtube.com/watch?v=LgLNyMAi-0I)

Your dates sound about right. The eighties. Mead+Conway was just out and fabs of a certain size became accessible. The question then was what could you do with these fabs and transistor budgets? Berkeley+Stanford did RISC+MIPS. Clark did the Geometry Engine at Stanford+SGI.

So what could you do with X transistors? But then X became stupid large. The 68000 (1979) had 40,000 transistors. Now the Apple A10 has 3.3-billion transistors. So you can imagine that architectural design assumptions dating from 1980 will need to be revisited.

> The 68000 (1979) had 40,000 transistors.

Where did you get that figure? I'm curious because the figure I've seen tossed around is 68,000 transistors (the story going that this is where the model number came from).

It's much more likely (like infinitely more likely) that the 68000 name stems from the earlier 6800 8-bit product line. There's nothing definitive saying 68,000 transistors and I've read both 40,000 and 68,000. I believe that 68,000 was just marketing. FWIW, Motorola also employed 68,000 people in 1980 (approximately):

https://www.motorolasolutions.com/content/dam/msi/docs/en-xw...

The Geometry Engine had 40,000.

https://books.google.com/books?id=gD4EAAAAMBAJ&pg=PA17&dq=68...

there was a brief window in the eighties

This was also the very brief time when memory was actually faster than the core, making it possible to contemplate things like large fixed-with instruction encodings, since the main bottleneck with the early CISCs was instruction decoding and not fetch bandwidth; it is unlikely that, had this period not existed, RISC would have developed in the way that it had.

It's ironic that Ditzel went from Berkeley RISC to Bell Labs and helped develop CRISP [1]. This was the invention of the Decoded Instruction Cache which solved the fetch/decode bandwidth problem. You could have a CISC and not have to worry about decode bandwidth. You could have a wide μop and not have to worry about fetch bandwidth.

[1] http://mprc.pku.edu.cn/~liuxianhua/chn/corpus/Notes/articles...

My own understanding is more simple... people care mostly about application availability and x86 was chosen as the primary platform for Microsoft Windows so anything that didn't support the x86 instruction set was at a disadvantage. These days with interpreted or JIT compilation, things are less certain but those days running things on bare metal mattered.

Yes, RISC-V is simple+elegant. If that's what you want, great. True, RISC-V is open source. If that's what you need, awesome. Now weigh those qualitative features against the cold hard $1B/year that Intel invests in making the mess that is x86 run fast.

I wonder how hard it would be for Intel to substitute an alternative decoder in place of the current x86/x64. Given the existing micro- and macro-fusion capabilities, is there anything that would prevent them from reusing the loop streamer and decoded instruction cache and entire back-end for a different instruction set? While there are probably legal issues with ARM or Power emulation (are there?), it seems like it wouldn't be too hard for them to quickly put together a high-performing hyperthreaded superscalar out-of-order alternative for RISC-V should they ever want to.

BTW, anyone who thinks that μops are actually RISC under the hood severely needs to re-read ...

Could you expand on this? I take you to be saying that Intel µops aren't really the same as classic RISC at all, but you seem to be the only person in this thread that holds this position. The majority appear to be saying straight-out that current Intel is actually RISC under the hood. Personally, I suspect that you are right, and that it would be useful for you to make this claim more forcefully. Or maybe I'm the only one that believes this, and I'm misinterpreting you?

Microprogramming is a technology which goes back to the 50s. CISCs were microprogrammed. The VAX was microprogrammed. It was the status quo circa 1980. RISC as a term really dates to 1980 (although the ideas go back to the 801 and Crays machines).

The big idea of RISC was to avoid microprogramming and have a simple to decode ISA which was directly executed by a short simple pipeline. ld/st + lots of registers + C compiler. Awesome.

Indeed in Patterson+Ditzel's version of Luther's 95 theses, they say:

  Microprogrammed control allows the implementation of complex architectures more cost-effectively than hardwired control

They say this in the section Reasons For Increased Complexity. RISC is revolting from that complexity, from microprogramming, so how can μops be RISC if that's what they were revolting from?

I think people say this because no one knows what microprogramming is anymore. You might read one paper in a graduate architecture seminar. And no one but no one writes microprograms.

The decode stage of Haswell translates add RAX,RBX into a '150b' μop. If can you read Agner Fog and you'll know how many μops, what the latencies are, etc. These are empirically determined properties of the μop but that's it. You know the Decoded ICache characteristics. But you don't know the ISA.

After all that's done, you're left with maybe a 14-pipestage data path. That's not RISC. Complicated instructions (AAA) get interpreted. That's not RISC. Multiple functional units can calculate 2+3 operand effective addresses. That's not RISC. This all is REALLY not RISC.

μops are micro-instructions, not RISC instructions.

BTW, the alternate decoder kinda wouldn't work so well because the microarchitecture, functional units, datapath, caches and registers are really set up for x86. Folks wanted something like that at Transmeta, a Java processor, but the HW was designed for x86.

This all is REALLY not RISC.

Thanks for the clear restatement!

Complicated instructions (AAA) get interpreted.

It may be worth mentioning that the BCD suite of instructions are not supported in x64. But if you are looking for an example of modern microcoded x64 to avoid, BTR/BTC/BTS with a memory operand is a prime example. Which does bring up the point that talking about "x86/x64" can be misleading in a similar way as discussions of the "C/C++" language.

the alternate decoder kinda wouldn't work so well because the microarchitecture, functional units, datapath, caches and registers are really set up for x86.

Are there specific areas where you see problems? For example, I'd think the existing abstraction between limited number of architectural registers and the hundreds of physical registers would work fine for alternative ISA's. And I don't immediately see why caching wouldn't work unaltered.

Folks wanted something like that at Transmeta, a Java processor, but the HW was designed for x86.

I searched for more information about what became of Transmeta after I posted last night, but didn't find much about the technical issues they encountered. Do you know if there is a good post-mortem?

While searching, I did come across a couple interesting CPU's that are going the other way:

Loonson 3 is Chinese MIPS processor that emulates x86 and ARM: https://venturebeat.com/2015/09/03/chinas-loongson-makes-a-6...

Elbrus-4S is a Russian VLIW design can emulate x86: https://www.extremetech.com/computing/205463-shadows-of-itan...

The main problem I see mentioned when going the other way (ARM emulating x86) is dealing with "flags". Since recent Intel processors already support "flagless" variants of most of the instructions (SARX, MULX, etc) this doesn't seems like it could be insurmountable.

BTS with a memory operand. Now that would be bad. What compiler people learned was to avoid the CISC-iest instructions in favor of RISCy ld/st+registers instructions. What Intel learned was to make RISCy instructions fast. However after translation to uops, the instruction encoding itself just didn't matter.

Also, register renaming helps a LOT; so you don't need a 32 direct registers when 16 registers renamed to 180 internal registers will more than do. Register renaming predates RISC by 15 years (Tomosulo). I'd almost say it's anti-RISC.

BTW, Elbrus + Transmeta are kinda joined at the hip. Babayan consulted at Sun with Ditzel and is now at Intel. Half the Transmeta people went to NVidia (eventually) and did an x86 before switching to ARM (Denver).

Eventually people will see RISC as the provisional idea it is. Register renaming is a Great Idea. Uop translation is a Great Idea. RISC is provisional.

> The main problem I see mentioned when going the other way (ARM emulating x86) is dealing with "flags".

I see the much larger problem in ARM emulating the memory model of x86, which gives much stronger guarantees on ordering and synchronization than the weak memory model used by ARM processors.

nicely said. though I think the Mill deserves more credit. Assuming that the team doesn't die or simply get acqui(patent)hired, they seem more likely to have material impact than RISCv which exists simply to swap out Arm.

Mill has had some their patents issued and their applications published which means there's something to read rather than listen to Godard's talks.

http://patents.justia.com/assignee/mill-computing-inc

I'm impressed at their doing something completely different and do wish them well. I know someone on the team but I'm impatient.

To me the most interesting part is that Mill has attracted a quite amazing amount of supportive interest from people who are talented, experienced and knowledgeable. Essentially a who's who of comp.arch...

I don't read comp.arch so who - besides Godard and willvarfar - is involved?