Comment by simula67 | Hacker News Reader

Comment by simula67 | Hacker News Reader

Parent Full thread

> Today, 99% of 32-bit and 64-bit processors are RISC

> Concluding this historical review, we can say the marketplace settled the RISC-CISC debate; CISC won the later stages of the PC era, but RISC is winning the post-PC era

It is clear that his assessment is right, but isn't the 99% number too high ? Servers, laptops and desktops still run x86 and they are CISC ( unless you are counting x86 as RISC based on microcode )

> Many researchers assume they must stop short because fabricating chips is unaffordable. When designs are small, they are surprisingly inexpensive.

> High-level, domain-specific languages and architectures, freeing architects from the chains of proprietary instruction sets, along with demand from the public for improved security, will usher in a new golden age for computer architects. Aided by open source ecosystems, agilely developed chips will convincingly demonstrate advances and thereby accelerate commercial adoption.

It will be interesting if manufacturing also gets open sourced. There already seems to be a project attempting this : http://libresilicon.com/

There's an x86 processor in your desktop, but there are many more RISC processors doing things like controlling your hard drive. If you buy an AMD processors there's even an ARM core inside the x86 processor in the Platform Security Processor.

Add in all the microwaves, routers, the many processors in your car, and so on and 99% seems a bit high to me but not unreasonable.

Seems disingenuous though, as the two markets have totally different optimization points and volumes. More like RISC has won the low-cost, low-power market, and CISC-RISC hybrids won the performance market, or something like that.

I'm sure you can think of a million other markets like this- sedans vs race cars, fighter jets vs puddle jumpers, etc.

It's really a lot more than two markets. The high end communications systems that use MIPS have almost as high performance demands as a desktop or server. And currently the highest performance core is a POWER 9. But on the other hand you have a few places where x86 Atoms have made inroads as embedded cores, as in the UR robot arms I work with.

But really I think we really do overemphasize the importance of x86 because that's the architectures we have the most experience working with directly.

there's a really interesting market at the bottom as well - super low power CPUs. 8/16 bit stuff, not RISC at all (since DRAM itself is a huge power draw at that level), and so on. fun stuff.

Smart TVs, Digital Cameras, Thermostats, Wristwatches, Phones, Tablets, Printers, Google Home devices, Amazon Echo devices, TV sticks (Chromecast, Firestick etc), Ring doorbells, security devices, etc, . . .

Anything (like a Printer) with a web based interface, having a micro web server within the device.

There are VASTLY more ARM and other architecture chips than there are x86/64 chips around you right now. Possibly even in the computer monitor you're reading this on. The desk phone in your office.

Just about anything that has any kind of a screen with menu system.

> Digital Cameras

The SD card has an ARM chip, usually, in addition to whatever is in the camera itself.

> agilely developed chips

I feel there's a long way to go there. The economic structure of the industry is against agility because "deployment" remains stubbornly expensive, and the product culture is also much more conservative.

> manufacturing also gets open sourced.

It's one of the most capital-intensive industries in the world, so I don't quite see how this would work? Libresilicon are offering a 1000nm (not a typo) process.

Yeah, it's like open sourcing code for 3D immersive visualisation of deep-water seismic survey data, along with the detailed blueprints for the ROV and survey equipment. Awesome enough, sure, but pretty much useless to me. I can build the software like a boss on my laptop, but since I don't have access to any seismic survey data, a CAVE room to view it in, an oceanographic survey vessel, ROV and associated equipment, etc. that's as good as it gets. And, if I had all that awesome oil industry exploration stuff, I'd probably also have a team of engineers building me software anyway, so I don't need it.

My point? Open sourcing stuff with ridiculously huge capital requirements is not that useful, I guess?

It's useful for verifying the process is what it claims to be, and for debugging problems as a user of the process.

I assume they’re counting them as RISC cores plus microcode that makes them compatible with older x86 CISC designs. Modern x86 is RISC under the covers by any meaningful definition-/and also shares pretty much all the problems.

I don't know why this gets thrown around but it's completely wrong. RISC and CISC are about instruction set architecture. As soon as you have crossed the decoder boundary you are deep into micro architecture territory where the ISA is completely irrelevant because you can use the same techniques regardless of whether you have RISC or CISC.

Now if one would take what you said at face value then it would actually imply that RISC as an ISA is completely irrelevant because it is possible to achieve the same benefits or even beat it despite CISC having the inefficiency of hard to decode instructions and the high cost of a conversion step in the micro architecture. One suddenly realizes that this battle of ISAs is completely futile and the secret sauce is in the micro architecture which is completely divorced from the ISA.

Here are some examples: ARM makes slow ARM chips. Apple makes fast ARM chips. AMD made slow x86 chips in the past but now adopted a faster micro architecture. Intel made Itanium but the chips didn't have any sort of dynamic scheduling so they couldn't deliver the promised performance gains.

Well, both Hennessy and Patterson have perpetuated the micro code and RISC myth, presumably because it suits the "RISC world domination" narrative.

ARM doesn't make any ARM chips, they just design them. Licensees make them. https://en.wikipedia.org/wiki/Arm_Holdings

Modern x86 is not RISC under the covers.

There’re instructions combining a dozen of math operations and also RAM loads, that on modern CPUs decode into just a single micro-op.

Example: https://www.felixcloutier.com/x86/vfmadd132ps:vfmadd213ps:vf... The AVX version computes x=a*b+pointer[i], for 8 independent SIMD lanes.

If you call that amount of stuff in a single micro-op “reduced instruction set” I wonder what exactly is the meaningful definition that you referred to?

x86 is not RISC by any meaningful definition. RISC vs CISC has always been about architecture, not microarchitecture. Breaking down instructions into microinstructions is as almost as old as the CPU itself and predates the CISC/RISC nomenclature by decades.

Many people describe the uOps inside a modern x86 as RISC-like and that's a good analogy. The internals really are much more similar to a RISC pipeline than older microcoded processors were. But it is still just an analogy because you're right about architecture versus microarchitecture.

but microcoding has existed for ever and while uops is probably a very specialized form of microcoding, it still not a new thing.

Also I do not think uops are fixed size as IIRC they can take a variable number of slots in the uop cache, and fix size instructions is pretty much one of the only two remaining differentiating RISC features. The internal x86 microarchitecture is also not load-store, the other one RISC feature, at least in the fused domain, and as far as I understand, in the uop cache.

So, even if we want to abuse the RISC term to describe the microarchitecture, I do not think it cleanly apply to the usual x86 implementations.

edit: this is a pet peeve of mine. It seems I have this discussion every 6 months on HN :)

Everything I've read about Intel uOps says that they're fixed size[1]. Now, the size isn't a power of 2 multiple of a byte like you'd see in a RISC design. I seem to recall some Intel architecture with 83 bit uOps? But it is fixed. And the uOp caches for both Intel and AMD are fixed size. Haswell stores 1.5k uOps[2] and Zen 2k[3] for instance.

But the important thing is that uOps are much higher level than microcode instructions. Except for the odd encoding size they would make a lot of sense as an early RISC ISA. Now, they expose a lot of the odd corner cases of the underlying architecture in a way that no modern ISA would but the original Berkeley RISC had branch delay slots and followed the philosophy that you'd just recompile the code when the ISA changes.

I'm at the edge of my knowledge here but I understand that microcoded instructions would tend to be much lower level, being things like read from memory to such and such an internal buffer. By contrast uOps do specify registers or constants, though they do so (post-rename) in terms of physical rather than architectural registers. But the decision on whether to get that arguments from the physical register or the bypass network is still made further down the pipe as with a RISC processor.

Is the analogy perfect? No, of course not. No analogy ever is. But I do think it illuminates more than it misleads for people learning about the evolution of processors - just as long as people can keep architecture and micro-architecture straight.

[1]https://en.wikichip.org/wiki/micro-operation for instance. [2]https://www.realworldtech.com/haswell-cpu/2/ [3]https://en.wikichip.org/wiki/amd/microarchitectures/zen%2B#M...

FWIW, Agner says that if a uop has multiple constants (for example an address and an immediate), it will borrow up to 32 bits from the next uop cache slot.

Encoding constants in the instructions themselves is a very non-RISC thing BTW.

> Many people describe the uOps inside a modern x86 as RISC-like and that's a good analogy.

Not really. Micro-Ops are typically very large (100+ bits wide) where each bit can be thought of as directly controlling a specific function in an EU. They can do things in parallel; the frontend may emit only one uop for more than one ISA instruction, they can contain constants, they're kinda-of variable-length in some microarchitectures. Overall they're very un-RISC-y.

Overall the whole RISC/CISC debate is pretty much meaningless and has been for decades. Many folks superimpose their own superstitions about unrelated issues (e.g. "PC server" vs "UNIX server" seems a popular one), but at the end of the day pretty much all high-performance cores look fairly similar, regardless of ISA.

Compared to other CISC CPUs designed at the same time as x86s (Vax, 68k, 32k, etc) x86s ARE positively RISCy - the instruction set (with 1 or two minor exceptions - push) only has instructions with 1 memory address making exceptions/restart (paging code) simple and making instructions easy to break into simple uOps (one trip to the TLB for protection checking - Vaxes used to potentially do 27 and guaranteeing that instructions could make progress in all situations was problematical)

I guess if you take into account micros embedded in things like washing machines, kitchen appliances, smart home devices, cars, etc... the figure could get close to 99%.

Not to mention laptops and desktops are getting RISC-based co-processors these days (e.g. Apple's T2 is present in the current iMac Pro, Macbook Pro, Mac Mini and MBA).

In fact now that I think about it, pretty much every SSD contains a controller SoC which is almost certainly RISC, so even in a standard laptop you get at most a 1:1 ratio of RISC:CISC. And modern GPUs (including IGP) would be RISC in a VLIW configuration, if each computation core is counted as a RISC chips the ratio quickly gets ridiculous.

> even in a standard laptop you get at most a 1:1 ratio of RISC:CISC

If you manage to find all the processors I bet it's more like 10:1. To a first approximation everything on the PCI and USB buses will have its own processor, even if it doesn't accept external firmware.

The article specifically points out that Intel/AMD took on board all the lessons from RISC as they evolved the x86 series and now it's pretty much a RISC architecture too.

Most RISC architectures have fixed-length instructions (16-bit, 32-bit, 64-bit, 128-bit), whereby most CISC instructions are variable size. So x86 is not a RISC architecture...

Reply on news.ycombinator.com