(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)
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.
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).
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...
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.
[1] http://mprc.pku.edu.cn/~liuxianhua/chn/corpus/Notes/articles...
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?
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
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.
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.
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.
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.
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.
Well, you should start from this and then work backwards because it's just an empirical fact that x86_64 is fast and that RISC isn't. There are many reasons for that, none of them fair, but in the end, it's still just a fact.
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. Add to that the billions that ARM+Samsung+NVidia+Apple+... spend on making ARM fast. It's not a fair fight. It really isn't.
But know this. If RISC had anything tangible, any fundamental advantage, then we'd be living in a RISC world by now and we aren't (Patterson+Ditzel was 37 years ago). If you want to think worse is better, sure. Whatever. If you want to call ARMv8 MIPS-ish, that's your constitutional right.
Skylake is a superscalar, speculative, out-of-order, renaming, hyperthreaded multicore beast. You may program it in x86 but those instructions get translated+cached as μops, very wide microinstructions.
BTW, anyone who thinks that μops are actually RISC under the hood severely needs to re-read The Case for the Reduced Instruction Set Computer and then say, Inside Nehalem [1] or Micro-operation cache: A power aware frontend for variable instruction length ISA [2]; microprogramming (vertical+horizontal) predates RISC by decades [3]. These μops are wide, 150+ bits. Ain't nothing reduced about that.
In 2017, believing in RISC is only slightly more acceptable than believing in Mill. Moreover, I say this as someone who went to Berkeley and read Patterson+Ditzel in 252. I should preach the religion.
[1] http://www.realworldtech.com/nehalem/
[2] https://www.researchgate.net/profile/Ronny_Ronen/publication...
[3] https://people.cs.clemson.edu/~mark/uprog.html