ARM Launches "Facts" Campaign Against RISC-V

[Weasel]

@coder: Took the words right out of my mouth, honestly it's like talking to a wall when dealing with him, he just replies with unbased (literally) walls of text and buzzwords. :/

Yet you still talked about CISC as if it was a real thing and not just "everything that doesn't fall under RISC" or even the at-the-time most common definition embodied by CPUs like the Motorola 68k with it's instructions ranging from simple to hugely complex and lack of superscalarity... When you design a CPU you are going to have at least some philosophy and most CPUs today are designed under a "Post RISC" philosophy where you still try to ensure as much of the silicon is in use at all times by trying to make everything either as quick as possible or split it into enough micro-ops that you get as little as possible of the silicon tied up with executing instructions that don't need that particular part anymore.

What do you mean a "real thing"? CISC/RISC are just ways to categorize CPUs, they're not a concrete "thing" or anything "physical".

I just said that a RISC CPU (a true RISC not a hybrid) won't ever reach the performance of a CISC CPU because some tasks need specialized "complex" instructions for the job to perform that well. RISC and CISC in this case are adjectives and classifications, not something that exists in the CPU. And using such classifications makes ARM a hybrid (because it has some "complex" parts).

[L_A_G]

What do you mean a "real thing"? CISC/RISC are just ways to categorize CPUs, they're not a concrete "thing" or anything "physical".

I just said that a RISC CPU (a true RISC not a hybrid) won't ever reach the performance of a CISC CPU because some tasks need specialized "complex" instructions for the job to perform that well. RISC and CISC in this case are adjectives and classifications, not something that exists in the CPU. And using such classifications makes ARM a hybrid (because it has some "complex" parts).

How many times do I have to repeat myself? There is no such thing as an actual CISC CPU! There's RISC, modifications on RISC and everything else (i.e CISC). Saying that a RISC CPU will never be as fast as CISC one is like saying that a car powered by a petrol engine will never be as fast as a car powered by something else. As a term CISC is literally vague to point of being meaningless and I've already brought up pre-RISC CPUs that are slower than even the earliest RISC-inspired CPUs so even your performance claims are simply stupid. If we really want to go back in time CISC can easily be argued to include very early machines like Colossus, ENIAC and the Z3 as it's that vague of a term.

Sure, pure RISC can't hold candle to modern post-RISC CPUs like current day x86s and bigger ARM cores, but you can't really describe those as CISC as the term is so vague that it includes everything designed without explicit RISC philosophy from today to the first Turing-complete machines that I just mentioned.

[Weasel]

How many times do I have to repeat myself? There is no such thing as an actual CISC CPU! There's RISC, modifications on RISC and everything else (i.e CISC). Saying that a RISC CPU will never be as fast as CISC one is like saying that a car powered by a petrol engine will never be as fast as a car powered by something else. As a term CISC is literally vague to point of being meaningless and I've already brought up pre-RISC CPUs that are slower than even the earliest RISC-inspired CPUs so even your performance claims are simply stupid. If we really want to go back in time CISC can easily be argued to include very early machines like Colossus, ENIAC and the Z3 as it's that vague of a term.

Sure, pure RISC can't hold candle to modern post-RISC CPUs like current day x86s and bigger ARM cores, but you can't really describe those as CISC as the term is so vague that it includes everything designed without explicit RISC philosophy from today to the first Turing-complete machines that I just mentioned.

Claiming stuff doesn't make it true. WTF are you even talking about?

In terms of classification on this scale, there's only RISC and CISC at the extremes, and grey levels in between if you want to be more "precise" but really who the fuck cares of details like that? It's like looking at something white and something black, I guarantee you they're not perfectly white or black, but people just call it white or black. We have grey too (like ARM) but overall we don't go around and say "this object is 96.7054% black" what the hell is wrong with you. You just say it's black (i.e. CISC), you don't have to be so damn specific.

A CISC CPU can be extremely slow, or extremely fast, it doesn't matter one bit. What matters is if it's using complex / specialized instructions (e.g. the crc32 instruction for x86 and others similar, most SIMD, and instructions using many clock cycles, and so on).

How do you know if an instruction is "complex"? Pretty simple, it's not a super scientific rule but you can get damn close to an accurate result with one of the following:

1) Ask yourself, does it require at least 3-4 times more clock cycles than the fastest instruction with register-operands only? (no memory loads or stores) If yes, it's probably a complex instruction.

2) Does it perform a specialized task (not basic arithmetic/logic/etc) which is more application-specific that could be done with simpler instructions? If yes, it's a complex instruction.

This definition TRANSCENDS the existence of a CPU. It's not tied to a CPU, unlike your way of thinking. It doesn't matter that some CPUs employing this philosophy were slow or fast.

The fact is that ARM, which is a hybrid as it has some instructions qualifying for complex above (and keeps adding them), still can't compete with x86 on performance, while x86 has more instructions that qualify for the above. Therefore x86 is "more black" or "more CISC" than ARM (to be precise), and is faster, thus CISC > RISC (black > white, if objects that are blacker are faster, it's called logic). If not, then why isn't the top-end ARM competing with top-end x86?

______________________

The crc32 instruction is a great example to illustrate this. A RISC CPU will never compete with x86 as long as it calculates that respective form of crc32. I mean, Skylake above in the table even has only ONE micro-operation for crc32 with a memory operand. Yes, a memory load AND a crc32 calculation is done directly in the hardware, not split into more operations. It's specialized for calculating it from memory, which is a typical use case, and thus it's way faster and more efficient than anything you can do on a RISC CPU "in software". Period.

[oiaohm]

What you posted is an algorithm you found, with absolutely zero evidence that it can, or ever has been implemented in a single cycle.

The reality here is you are commenting on risc-v without ever reading the Chisel code. The Chisel code that generated the ALU parts for risc-v processes uses that algorithm and it is 1 clock. It generates to 128 bit divide and multiply that work.

Then it would be out of patent and there'd be much faster idiv in chips for decades, yet the latest and fastest chips still number in the dozens of cycles for this.

Powerpc chips and arm have been used in supers because they don't take dozens of cycles todo mult and divide. X86 has never really improved it stuff.

Not what I heard. I read that Apple pushed for AVX to look more like Altivec (i.e. 3-operand), which the DIVA paper references. Otherwise AVX is basically just double-wide SSE, with a couple new tricks.

Who pushed for it and where intel went for design reference are two different things. You will find AVX shows the performance profile of DIVA.

I don't need your dissembling. I've made it clear I don't trust a single thing you say. Posting authoritative links is the only way to save your reputation.

And I cannot post patent links here because people who are working on stuff who could conflict with patent could find themselves in trouble. Sometimes its not possible to post the authoritative links. You are looking for 2002 patents taken out by the group behind DIVA. So either you have the skill to look that up or you don't.

[oiaohm]

The crc32 instruction is a great example to illustrate this. A RISC CPU will never compete with x86 as long as it calculates that respective form of crc32. I mean, Skylake above in the table even has only ONE micro-operation for crc32 with a memory operand. Yes, a memory load AND a crc32 calculation is done directly in the hardware, not split into more operations. It's specialized for calculating it from memory, which is a typical use case, and thus it's way faster and more efficient than anything you can do on a RISC CPU "in software". Period.

http://www.ti.com/lit/an/spna146/spna146.pdf

Try again divide/multiply arguement is a failure because the Chisel of risc-v has that done in one clock cycle and this crc32 one is no better. Notice how Texas instruments memory controller for risc implements crc32.

So getting a crc32 is just a general RISC load on a mmu supporting crc32. So risc its only 1 micro-operation as well if the hardware supports accelerated crc32 in the MMU.

CISC you have a habit of implementing lots in the CPU core not putting lots in correctly design accelerators. Risc you implement a lot in the sub modules like the MMU. Reality Skylake is doing the crc32 in the MMU as well so exactly like the Texas instruments did for arm based risc before x86 chips had hardware accelerated crc32.

The the mmu by Texas instruments lets auto operation so you can cpu core can get on with executing code without having to worry about crc32 checking and get a interrupt if there is a problem. As you said the typical usage case is checking memory so implementing it in the MMU makes sense.

High performing risc has a lot of stuff implemented transparently. Risc the core instruction set is simple but this does not mean the items you are performing load/store to and from are simple. Proper RISC requires thought were a feature should be the ISA or should it be in a accelerator like the MMU like with crc32.

Complex / Specialised instructions the truth is horrible. Lot of times when you are doing CISC instructions you are putting them in the worst performing place. Making your instruction set by cpu core more complex to process. When you could do the same thing using targeted load/store in a risc without adding instruction to the instruction set.

RISC implementations have been hindered in a lot of ways with fixed clock cycles. So unable to like using half ALU to save on silicon at cost of performance so making risc chips more expensive per unit than CISC ones..

RISC has also been hindered by fixed clock cycles different way because this does not allow instruction fusion. Instruction fusion is execution of multi risc instructions or multi microops in 1 clock cycle. Risc has also been hindered by not having instruction compression so requiring larger memory transfer between ram and cpu caches than CISC did.

CISC really was first way of compressing instructions. But we are now seeing with x86 CISC vs RISC-v with compression where x86 CISC is not as compressed as compressed risc-v.

CISC benefit of being done as a register memory architecture also starts disappearing when you have risc with instruction fusion. Why reading from memory writing to a register and pushing somewhere for processing and pulling result back into a different register in a risc with instruction fusion can happen in under 1 cycle.

Basically a RISC instruction fusion sees a RISC instruction set being able to behave a lot like a CISC one in performance while still have fairly simple instruction set.

CISC been register memory does appear to have advantage due to not having to use registers. But this also makes limit sense since risc-v in experiments has found for 90% percent of cases it has 2 times the number of registers it really needs and the number of registers they allocated because this is historically what risc processor had never really gets fully used.

ARM has been badly ruined by adding more and more complex instructions because it had not implemented good instruction fusion.

Risc-v compression, out of order and fusion combination with accelerators is getting really interesting.

Prime objective with risc is to use each individual instruction in the most numbers of useful ways.

[L_A_G]

...

I thought I was actually getting somewhere with you, but apparently not... CISC is only extreme in the breadth of what it encompasses as it's not a design philosophy, it's a "literally everything else" definition. Sure, it has been thought to describe designs similar to the Motorola 68k with a list of instructions from simple single cycle ones to ones that take well over a dozen cycles and no superscalarity, but it's always been plain wrong.

It really doesn't matter how verbose you can get when your basic argument is plain wrong. You cannot use the term CISC like you're doing as it's just too vague to serve as any useful distinction and as I mentioned, it encompasses CPUs that are more RISC-like than most actual RISC CPUs (like the i8080).

[Weasel]

http://www.ti.com/lit/an/spna146/spna146.pdf
Try again divide/multiply arguement is a failure because the Chisel of risc-v has that done in one clock cycle and this crc32 one is no better. Notice how Texas instruments memory controller for risc implements crc32.

So getting a crc32 is just a general RISC load on a mmu supporting crc32. So risc its only 1 micro-operation as well if the hardware supports accelerated crc32 in the MMU.

Lol man if a "RISC" has a crc32 uop then it's simply not RISC. It's either a hybrid or CISC.

I also never said that a RISC can't do a crc32 in 1 clock cycle if it has such instruction, it's purely about availability of such instructions. Both CISC and RISC which calculate crc32 without a specialized instruction will be slower than one using such instruction.

The point is that the existence of a crc32 instruction makes the CPU non-RISC. ffs.

(there's also many possible variations on crc32, x86's calculates a specific polynomial, so yes it IS A SPECIALIZED instruction)

[Weasel]

I thought I was actually getting somewhere with you, but apparently not... CISC is only extreme in the breadth of what it encompasses as it's not a design philosophy, it's a "literally everything else" definition. Sure, it has been thought to describe designs similar to the Motorola 68k with a list of instructions from simple single cycle ones to ones that take well over a dozen cycles and no superscalarity, but it's always been plain wrong.

It really doesn't matter how verbose you can get when your basic argument is plain wrong. You cannot use the term CISC like you're doing as it's just too vague to serve as any useful distinction and as I mentioned, it encompasses CPUs that are more RISC-like than most actual RISC CPUs (like the i8080).

Define "RISC-like" and "RISC" then.

On a greyscale, Black is also "everything else" if you exclude White (RISC) and Grey (hybrid). I seriously don't know what your point is. You think a term that negates another definition is less valid or what? Antonyms are just as valid as the original word.


Here's the short end of it: CISC is non-RISC (so yes, "Everything else", point?), and RISC is a CPU with relatively simple instructions that execute in roughly the same amount of clock cycles, assuming register operands only. Therefore RISC won't compete in performance with CISC (sorry I mean "non-RISC") which also has those specialized instructions.

Do you fucking want me to replace CISC with "non-RISC" or what? It doesn't change a fucking thing and yet you keep insisting on it as if you had a point.

[L_A_G]

...

You know the definition of RISC as well as I do so I'm not going to fall into your "Being more verbose than someone else means you know more than they do" stupidity.

As I've pointed out to you time and time again, as a term CISC is vague to the point of being absolutely meaningless. Comparing RISC to CISC is practically like comparing a VW beetle to everything every other form of motorized transport invented by man from early steam cars to the B2 bomber.

Sure, pure RISC designs have some very clear limitations in this day and age, but talking about CISC somehow being better is completely stupid when it also encompasses designs and philosophies that are way worse. As I've told you before, if you're going to compare pure RISC to something better (in terms of achievable performance), compare it to actual philosophies like "post-RISC", which is the actual name of what you've so far been incorrectly describing as CISC.

[Weasel]

Yes repeat some more how "CISC means non-RISC" is so vague that it's meaningless. If I say "non-RISC" is that vague too even if it's the exact same thing? Or what? But if you replace CISC in your posts with "today's definition of RISC" or "post-RISC", then you might have a point about it being so vague and all.

There's nothing worse about a CISC (for performance at least), just bad CPUs (specific models I mean) not taking advantage of it. Complex instructions like "rep movsb" used to be slow but now, because CPUs started to have them designed properly and realized the importance of hardware specializations, they're faster than anything you can cook on "software" with basic instructions. It simply scales with the CPU itself since it's implemented in the CPU, so if the CPU's width or something else changes, your code won't have to: it will automatically adapt to the best way to copy memory.

This is just one example why CISC > RISC. I already gave too many -- fuck it.