ARM Launches "Facts" Campaign Against RISC-V

[L_A_G]

You know, the moment people "redefined" RISC is the moment they lost the RISC-superiority argument and CISC won. Nothing more needed.

You do know that CISC was never actually a deliberate design approach to begin with? RISC was from the start a "back to basics" approach based on the findings of research conducted at Stanford and Berkeley in the 1970s and CISC was always an "Everything else" catch-all coined in that material.

[chithanh]

Michael it appears that the riscv-basics website has been taken down.

It is reported that internally at ARM, this campaign was largely criticized and rejected by their staff.

[Weasel]

There's no law that a RISC-style ISA couldn't have an instruction/extension like inverse reciprocal square root, especially if it's a meaningful performance win and the uarch pipelines it relatively efficiently with other instructions in its hardware. CPU designers aren't drawing pedantic distinctions between RISC and CISC, you are.

I don't care about CPU designers? RISC is a term, an attribute, not a goal. I already said that ARM is NOT RISC so not sure what CPU designers have to matter in this.

If RISC is so fundamentally gimped on performance, can you please explain why Apple's arm64 JS engine running on my iPad Pro outperforms all JS engines running on the Skylake/Haswell laptops I use, and does so with only a heat spreader? Can you explain why during the 90s, high-end RISC processors typically outperformed x86/68k cores? Is it maybe, just maybe, possible that the microarchitecture/application-specific optimizations and extensions/implementation details are far more important aspects of high-performance CPUs than the base ISA?

I did explain at least 10 times. ARM is not RISC for a long time, it had to become a hybrid to compete.

[Weasel]

You do know that CISC was never actually a deliberate design approach to begin with? RISC was from the start a "back to basics" approach based on the findings of research conducted at Stanford and Berkeley in the 1970s and CISC was always an "Everything else" catch-all coined in that material.

CISC is a "let's do what we can/want in hardware, any instruction we want".

RISC was originally (and what it should be) a "let's implement all instructions on register-operands so they execute in exact X clock cycles and have the exact same size in encoding, simplifies the CPU tremendously".

You guys can deny it, but you know it's true. The only instructions that were exceptions in RISC were memory addressing instructions (load/store as called in RISC). Everything else was supposed to run in X clock cycles (e.g. 1 cycle) to simplify the damn processor. That's why CISC was "complex" because it had no such limits on the design. Initially, all this extra synchronization and logic in the CPU was pretty big overhead, a large % of the CPU die for CISC. But memory was even scarcer, so CISC still won out in the end.

Today, the CISC "logic" is minuscule compared to stuff like out-of-order things and the cache (which is like half of the entire die), so CISC is simply superior as it offers you extra performance with specialized instructions if you need it.

It's like having a 1MB extra file when you have 1TB of space on your drive. Do you mind the 1MB "cruft"? But then that 1MB can substantially speed up some specialized tasks via CISC instructions.


The "reduced" comes from the fact that only a limited amount of operations can be implemented in X clock cycles. For example, the reciprocal square root approximation I was talking about is NOT risc because it can't be done in the same amount of clock cycles as a floating point multiply.

Neither is division, for that matter. Did you know most RISC don't (or didn't) even have a division instruction at all? Because it's a super slow operation. You had to implement it in software which is even slower. Heck some didn't even have a damn multiply instruction, just to abide to that philosophy and keep the CPU simple.

CISC has no such limits, that's why CISC > RISC.


Anyway I did read all of you but I can't reply to each because of the spam filter getting on my nerves. Just consider this post as a summary.

And lastly, ARM is not RISC anymore and hasn't been for a really long time.

[L_A_G]

...

I can see that you really like droning on and on trying to sound very knowledgeable and all, but in this case you are just plain wrong. CISC really was just a catch-all for everything else that didn't arise from the Stanford and Berkeley research, including CPUs that were more RISC-like than the CPUs that resulted from the research simply due to predating the research and not being explicitly designed with RISC-like internals in mind.

Seriously thou, CISC is not and has never been an actual design philosophy. You can talk about the flaws of the RISC philosophy and all, but CISC being literally everything else you really can't say it's worse or superior.

[oiaohm]

The "reduced" comes from the fact that only a limited amount of operations can be implemented in X clock cycles. For example, the reciprocal square root approximation I was talking about is NOT risc because it can't be done in the same amount of clock cycles as a floating point multiply.
.

That wrong. reduced instruction set computer, or RISC

https://en.wikipedia.org/wiki/Reduced_instruction_set_computer

Take a closer look. Risc is about instruction set. Not number of operations per clock cycle. Risc effect is few clock cycles per instructions. Of course this does not mean a risc instruction could not take multi clock cycles. Or that multi risc instructions cannot be executed in 1 cycle.

Fixed width and fixed processing risc that was not the first RISC by the way(the first risc was fixed width dynamic processing) kind of matches what you are talking about.

Dynamic processing did not have a particular problem fixed processing has. Fixed processing risc in instruction set have to have "branch delay slot" instruction. Yes fixed is where you get the wrong idea only limited amount of operations can be implemented in X clock cycles.

Its less transistors to make a fixed processing risc chip than a dynamic processing risc chip. The first risc prototype was dynamic.

Yes you would also see "branch delay slots"/nop instructions on fixed processing CISC chips.

RISC and CISC are both about how the instruction set are design not about how many clock cycles processing will take. If you cannot guess any out of order cpu design be it risc or CISC is dynamic processing.

In fact a risc-v instruction set cannot be made as full blown fixed processing as it has no "branch delay slot". Yes x86 can be made as fixed processing. Yes x86 that you call CISC is implement with X number of micro ops per clock cycle. Risc instead of micro ops would be x number of risc instructions cleared per clock cycle. Result is not much different.

I know it hard but the first RISC chip is dynamic with different time per risc instruction and more than 1 risc instruction processed per clock cycle. Lot of ways risc-v is returning to the first RISC design. We have never seen RISC as it best really facing off against CISC.

[blargh4]

You really have to look at the term "RISC" in its historical context.

Take a look at something like the VAX-11: it has a ton of addressing modes that almost any instruction could directly use: https://i.gyazo.com/1266ee4bca68c71a...2de6e4b7cd.png

It had instructions like this: https://i.gyazo.com/9b64c3d15332d363...b7e04375df.png

Needless to say, making a processor that can tightly pipeline instructions that encode both complex operations and complex memory access is non-trivial.

When these ISAs were being designed, memory was both ridiculously expensive and slow. Computers did not have fast on-die sram caches, but microcode ROM was fast. People wrote a lot of assembly. So dense instructions that relegated lots of the work to complex microcoded routines and made assembly language expressive made sense. By the mid-80s, the technology was in a place where it was making less sense.

ARM certainly doesn't meaningfully resemble the archetypal CISCs, ARM64 even less so.

[Weasel]

I can see that you really like droning on and on trying to sound very knowledgeable and all, but in this case you are just plain wrong. CISC really was just a catch-all for everything else that didn't arise from the Stanford and Berkeley research, including CPUs that were more RISC-like than the CPUs that resulted from the research simply due to predating the research and not being explicitly designed with RISC-like internals in mind.

Seriously thou, CISC is not and has never been an actual design philosophy. You can talk about the flaws of the RISC philosophy and all, but CISC being literally everything else you really can't say it's worse or superior.

Isn't that what I said? CISC's "philosophy" is basically "no limits" at all and can implement any type of instruction no matter how complex or specialized it is etc. So it's more like a lack of one than an actual direction so to speak.

[Weasel]

That wrong. reduced instruction set computer, or RISC
https://en.wikipedia.org/wiki/Reduce...n_set_computer

Take a closer look. Risc is about instruction set. Not number of operations per clock cycle. Risc effect is few clock cycles per instructions. Of course this does not mean a risc instruction could not take multi clock cycles. Or that multi risc instructions cannot be executed in 1 cycle.

But that's exactly what I said?

I meant that there's only so many operations you can implement with 1 clock cycle (or X, replace X with anything). Thus the amount of instructions corresponding to those operations will be reduced in RISC compared to CISC. You can't have division, for example, and still consider it RISC. And no, if a RISC does have other types of instructions, then it's not RISC anymore. Maybe a hybrid.

[oiaohm]

I meant that there's only so many operations you can implement with 1 clock cycle (or X, replace X with anything). Thus the amount of instructions corresponding to those operations will be reduced in RISC compared to CISC. You can't have division, for example, and still consider it RISC. And no, if a RISC does have other types of instructions, then it's not RISC anymore. Maybe a hybrid.

https://en.wikipedia.org/wiki/CDC_6600#Instruction-set_architecture

Division is a complete fail of example. CDC 6600 is the is the first classed as being RISC this is before the term RISC existed it has a divide function. Yes a float point divide it was missing interger divide CDC 6600 is where the triple action risc instructions comes from. Triplet being 2 inputs and 1 output. Even the IBM 801 that is the first RISC after the term RISC is recognised has triplet action instructions.

But there is something interesting. Most risc instructions sets don't have a unique divide or multiplication instruction. Instead have a muldiv instruction with function modes. Yes divide, remainder, multiplication all under the same master instruction code..

Please note CDC 6600 triplet functions were all ALU (arithmetic logic unit) functions. So anything mathematical under risc it is normal for it to be triplet.

There is a different limitation. Load/store architecture what most RISC are and all first generation risc cpu are the ALU operations can only happen between registers and they are triple register functions. 2 registers in 1 register out..

So if RISC cannot have divide there is no such thing as a RISC cpu that has ever been made. RISC is a optimisation on what is called load/store architecture.

https://en.wikipedia.org/wiki/Load/store_architecture

CISC on the other hand is Register memory architecture in most cases there are some CISC that are load/store.

https://en.wikipedia.org/wiki/Register_memory_architecture

The difference is nothing more than that Risc due to being load/store forces operations taking multi parts to be perform on registers. Where most CISC those operations can be performed memory directly because they are Register memory architecture. Not like this difference between CISC and RISC has to cause any performance difference when you have risc cpu that can clear multi instructions per clock cycle.

load value 1 into register 1
load value 2 into regsiter 2
ALU divide register 1 with register 2 with result in register 3.
store register 3 to memory.
Yes you see some out of order risc designs clear this in 1 clock cycle. With risc-v compression this stack of instructions are in fact smaller than x86 CISC instructions directly doing the divide directly on memory addresses. Yes when x86 turns a memory divide into micro ops basically turns it into almost exactly the same as risc program had from start line.

The biggest problem with CISC when you start turn it into micro ops to allow out of order operations you fairly much end up turning you CISC code into RISC on load/store architecture. So why not start with compressed RISC in the first place and have simpler translation.

This is where idiots like Weasel get into trouble talking about RISC. RISC is a method you apply on top of load/store architecture. RISC is not the base architecture. Load/store architecture defines how you do ALU under RISC cpu and always has. Only reason why a RISC cpu could not do divide is if it has no ALU.

I guess weasel made the mistake of thinking the limitation on memory operations of load and store applied to ALU operations.

Yes CISC you might be able to implement what ever instruction you like but you still have to be able to perform that instruction effectively.

CISC end up with more and more complex conversions attempting to get out of order to work to make best usage of bandwidth inside hardware.

Remember my note that Risc-v out of order boom CPU core end up smaller than the rocket core in order cpu. This is impossible with a CISC. CISC you end up having to translate stacks of stuff to microops and have stacks of processing like that all consuming silicon space as you attempt to make CISC out of order compadible. Risc-v boom creates not a single micro op. Yes you have op fusion where two risc ops can be performed at exactly the same time. Basically out of order risc-v just processes risc-v instructions almost normally..

A well designed risc instruction set is highly out of order compatible. Every time you add a CISC like instruction to a risc instruction set you make ti less and less out of order compatible so forcing you to perform micro op conversions like CISC cores have to.

Yes arm instruction set is kind of ruined because core is RISC but developers have got stupid and add CISC like functions on top so resulting in arm needing to perform micro op conversions.

Lot of the performance gain of CISC can be achieved with op fusion and out of order execution and instruction compression while keeping a proper RISC instruction set that is highly out of order compatible.