RISC vs CISC and CPU architecture discussion

[Gunnar68080]

Someone just posted Coremark values for the 68080.

Have you looked into CORE mark code?
What exactly does it do?
Can you tell me this?

Can you tell me what compiler version was used to compile it?
Can you tell me what compile flags were used, was optimization for modern 68K features enabled.

How is the code written, can it use Super-Scalar or is written not good enough for this?


If you talk about benchmarks,
then try to do it properly.

First get the facts.
What does the benchmark do?
Is it reasonable?
Was the benchmark - meaningful compiled?
Was a compiler version used that gives proper code.
Where the compiler flags needed to activate all CPU feature used?


Do your stuff like a professional

[MasterOfGizmo]

It wasn't me who posted the benchmarks.

[MasterOfGizmo]

Did you just try to tell me something about - the stuff that I worked on?

Maybe. Dunno. I don't know what you did and where you worked. And I don't see how this is related to the fact that ARMs are currently appearing in datacenters. Aren't they?

[Cyprian]

Did you just try to tell me something about - the stuff that I worked on?

Maybe. Dunno. I don't know what you did and where you worked. And I don't see how this is related to the fact that ARMs are currently appearing in datacenters. Aren't they?

due to my my daily job, I'm somehow involved in DC infrastructure. And I must admit that ARM is present in every DC as a server management chip: e.g.HPE iLO/Dell iDRAC. When it comes to pure server CPU, ARM is rather as a niche, due to low performance figures vs Intel and AMD.
BTW my first touch with ARM was HP Moonshot blade server.

[MasterOfGizmo]

Don't you e.g. have some Ampere systems in your DC?

[robinsonb5]

Someone just posted Coremark values for the 68080. It's 8 times faster than the old TG68K on the MiST!

Someone's done a coremark score for the TG68K? Neat - where did you find that? [Edit: elsewhere in this very forum, apparently!]
(When I looked at coremark in the past it had a restrictive license, so I didn't bother with it. I've just looked again and see that they've since opened it up - might be time to take another look...)

[Thenesis]

Someone just posted Coremark values for the 68080.

Have you looked into CORE mark code?
What exactly does it do?
Can you tell me this?

Can you tell me what compiler version was used to compile it?
Can you tell me what compile flags were used, was optimization for modern 68K features enabled.

How is the code written, can it use Super-Scalar or is written not good enough for this?


If you talk about benchmarks,
then try to do it properly.

First get the facts.
What does the benchmark do?
Is it reasonable?
Was the benchmark - meaningful compiled?
Was a compiler version used that gives proper code.
Where the compiler flags needed to activate all CPU feature used?


Do your stuff like a professional

I think he is trolling you, it is endless.

[mfro]

Don't you e.g. have some Ampere systems in your DC?

Multi-CPU ARM servers are already pretty common in data centers that want to (or have to) look for energy efficiency.

[Cyprian]

Don't you e.g. have some Ampere systems in your DC?

I dont think so but I'll ask my colleague.

Counterpoint-Intel-AMD-CPU-serwery.png

[MasterOfGizmo]

Of course. That's why I said that we _start_ to see them.

[1st1]

It's not that simple.

Do you see the "Complex Instruction" in CISC?

What does that mean on an instrcution which takes 4 cycles? Answer: One instrcution does "complex things", that means four things where every thing takes one clock cycle.

RISC uses simple instructions which do only one thing per instruction, so, they need only one clock cycle. But maybe, to make the same as the CISC instruction, the RISC processor needs four separate instructions to do the same.

[1st1]

due to my my daily job, I'm somehow involved in DC infrastructure. And I must admit that ARM is present in every DC as a server management chip: e.g.HPE iLO/Dell iDRAC. When it comes to pure server CPU, ARM is rather as a niche, due to low performance figures vs Intel and AMD.
BTW my first touch with ARM was HP Moonshot blade server.

That's no that simple. The ARM consumes much less power than current XEON series or similar from AMD. And for example Apple M3 ARM CPU is quite powerfull. If you would add that much ARM processors that they would consume that much power as a single Intel/AMD server CPU, they would outperform them on applications whch can run massive parallel.

[1st1]

But he sais that it's significantly easier to optimize a small core for speed than a more complex one. So in the end the RISC can be clocked higher.

But is this really the case?

fact: the CISC Intel CPU run over 6 GHz clock speed
fact: the CISC IBM Z Prozessor runs over 5 GHz clock speed

Where is an RISC ARM CPU that reaches over 5 or 6 GHz?
There is none!


Please don't fall for repeating modern fairy tales or marketing blabla

Always look at the fact and think logical !

It's not that simple... Those CISC processors today from Intel and AMD (no idea about IBM Z) in reality are RISC CPUs (since the first generation of Core2...). The x86 CISC CPU in fact is just an emulation on a RISC machine... The real "work" of executing the x86 CISC machine code is done by "microcode" which runs on a RISC processor inside the chip which understands this microcode. So every x86 CISC instruction stands for a sequence of RISC instruction in "microcode" language. You can not see this microcode except if Intel/AMD dectects an error in it's CPU and they publish microcode updates through BIOS, Windows or Linux updates. And fun fact, the clock of that internal RISC machine is much higher than the official clock speed of that processor, maybe double clock speed.

[1st1]

Let me compare x86 with 68k which CPU is better.
Well this depends which core I pick from their group
68060 versus 386 - 68k wins
68000 versus Pentium 3 - x86 wins

You really make crazy unfair comparison. Why not comparing i4004 vs. Core i9 processor 14900K ???
Compare Z80 4MHz vs 6502 1 Mhz (Z80 looses as 6502 is RISC like)
Compare 8086-8 vs. 68000-8 (8086 looses)
Compare 80286-16 vs 68000-16 (80286 looses)
Compare 80386-16 vs 68020-16 (...
Compare 80386-33 vs. 68030-32 (...
Compare 80486-33 vs 68040-32 (...
Compare 80486DX2/66 (or DX50) vs. 68060-50 (...
Compare Pentium II 266 vs. Coldfire 266 MHz (Coldfire looses as the benchmark fails due to missing instruction in CPU)

Then, officially there was no faster 680x0 from Motorola.

[kolla]

Don't forget that I worked for IBM.

How can one, you bring this up constantly. But about that… “worked” - the relationship with IBM ended. Was it IBM or was it you?

[ijor]

Did you wonder why the 68000 CPU needs minimum 4 cycle per instruction? This can be easy explained.
In fact the 68000 is not a true/REAL CISC. The 68000 has inside a RISC like core which kind of emulates the good CISC instruction set doing this in several cycles. How this is done is called microcode.

Now that things seems to be more quite, this is something I wanted to address a few days ago already. Perhaps just for the record because it is not very significant to the discussion. But I think this is, at least, not exact.

There are more than one reason why instructions on the 68000 take at least 4 cycles. But the most fundamental reason is because a bus cycle takes 4 clock cycles.

The 68K is not superscalar, it doesn't perform pipeline overlapping like the 020, not even the 010 loop mode, and of course it has no cache. Therefore, every instructions (well, except STOP) must perform at least one bus cycle to refill the prefetch queue. That means that even if, say, NOP would have dedicated hardware support and wouldn't execute from microcode, it would still take 4 cycles anyway.

This is why the fastest instructions in the 68020 (still a fully microcode based CPU) take now only 3 cycles in the "worst" case. Because the 020 bus cycle is shorter than the 68K and can be as fast as 3 clock cycles. And this is also why the "cache case" of those instructions is only two cycles. Even when they always execute from the same microcode.

Now, of course that mircocode plays its role. The 68K needs a minimum of two cycles to execute a single microinstruction. And also a macro instruction needs at least two microinstructions. This means that any instruction in the 68K would need at least 4 clock cycles anyway, even if it wouldn't perform any bus cycle at all. But this likely could have been optimized if it would have been useful, as it was implemented on the 020. But on the 68K, as explained above, it wouldn't help.

Btw, Gunnar probably already knows that, but the 68K microcode is not anything like RISC. The micrcocode operates at a much lower level, much closer to the hardware than a typical RISC code.

[1st1]

I don't think that what you call "microcode" in the 68k can be compared to microcode in modern Intel/AMD processors. The 68k microcode is more like a hardwired mealy automate where every instruction has hardwired processes and is controlled by input signals like registers, clock, prevoius command, etc. and comands have different number of single steps (flow control of the single steps to do) to accomplish (like: load data in register a, load data in register b, add a+b, load result in register c and set some flags like result is zero) while modern microcode is risc-processor inside of cisc-processor.