David Brown <david.brown@hesbynett.no> writes:
>On 07/12/2023 21:14, Marcus wrote:
>> I wonder if 200 is a fundamental constant for RISC vs CISC ;-)

It's fundamental nonsense, because:

>I've always considered RISC to be parsed as (RI)SC rather than R(ISC) -
>it meant small and simple instructions, rather than a small number of
>different instructions.

Yes. John Mashey made this point in his repeated posts on this topic.

>The idea was that instructions should, on the
>whole, be single-cycle and implemented directly in the hardware, rather
>than multi-cycle using sequencers or microcode.

Somewhat: "Single-cycle" is a microarchitectural property, not an ISA
property, but yes, the idea of the first RISCs was that the ISA should
be implementable with such a microarchitecture.

Also, single-cycle means the issue rate on a pipelined processor.
There were many RISC implementations that needed two cycles of latency
for loads. And likewise, FP instructions needed multiple cycles of
latency. And finally, the MIPS R2000 integer multiplier and divider
was not even pipelined (but could run in parallel with the rest of the
integer pipeline).

There have been attempts at splitting, e.g. FP instructions into their
parts (align, add, normalize or somesuch) as a RISCier way to do
things, but it never was implemented in a mainstream processor. What
has been implemented in mainstream processors:

* no integer multiplier/divider (SPARC, HPPA, no divide on Alpha and
IA-64), instead go for multiply step, do it in the FPU, or implement
division through subtraction (Alpha) or fma (IA-64)).

* no 8-bit or 16-bit memory access: eliminates a part of the aligner
from the load data path, eliminates ECC problems for write-back
caches (but no Alpha implementation without BWX extension had such
problems).

What is common in RISCs is to split large constants into sequences of
instructions (e.g., for loading the constant from the global table).

I guess I forgot a few.

>You could have as many
>as you want, and they could be as complicated to describe as you want,
>as long as they were simple to implement. (I've worked with a few
>PowerPC microcontrollers - PowerPC is considered "RISC", but it has a
>/lot/ of instructions!)

Power(PC) is also an example of how moot it is to count instructions.
It has, e.g., load instructions with and without update, which
correspond to one load instruction with different addressing modes in
ARM A64.

>In practice, though I think RISC vs CISC is more often used to
>distinguish between positions in a range of tradeoffs common in ISA
>design, such as :
>
>* fixed-size, fixed-format instruction codes vs variable encodings

Many RISCs use variable-size instruction encodings, e.g., ROMP, ARM
A32/T32 and RISC-V with the C extension.

>* many orthogonal registers vs fewer specialised registers

VAX (the exemplary CISC) has 16 registers, like ARM A32 (first
generation RISC).

>* load/store vs advanced addressing modes

That's not a dichotomy. Many load/store architectures have more
addressing modes than, e.g., AMD64 (not a load/store architecture);
e.g. ARM A64. Power(PC), HPPA, and 88000 also have at least as many
as AMD64.

The dichotomy is between load/store and non-load/store architectures.
And that's how I usually distinguish between RISC and CISC.

However, it seems that a bigger issue is: one vs. multiple memory
references per instruction. The VAX has multiple, which complicates
many things, whereas (for the most part) AMD64 and load/store
architectures have only one. There is MOVS and REP MOVS for AMD64,
and there is ARM A32 and Power load/store multiple instructions, which
require special treatment.

One interesting aspect here is that modern general-purpose
architectures all support unaligned accesses, which may require
accessing two different cache lines and even two different pages.
Once you support that, the load-pair/store-pair instructions of ARM
A64 does not make loads and stores more complicated (but it
complicates register porting).

>* "one thing at a time" vs combing common tasks in one instruction

RISCs have done so for FP instructions, addressing modes, and by
putting multiply and divide instructions in.

>But there's no clear boundaries.

There are clear boundaries between load/store and other (the classical
RISC boundary), and between lots of other properties of instruction
sets. Of course marketing people and advocates have tried to claim
RISCness when it was cool to be a RISC. An example can be found here:

>The original 68k architecture was
>always classified as "CISC". Then the later ColdFire versions were
>called "Variable instruction length RISC", though there was a 90%
>overlap in the ISA.

Is Coldfire a load/store architecture? If not, it's not a RISC.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

David Brown wrote:

> On 07/12/2023 21:14, Marcus wrote:
>>

> I've always considered RISC to be parsed as (RI)SC rather than R(ISC) -
> it meant small and simple instructions, rather than a small number of
> different instructions. The idea was that instructions should, on the
> whole, be single-cycle and implemented directly in the hardware, rather
> than multi-cycle using sequencers or microcode.

Why should::
ADD R7,R8,#0x123456789abcdef
take any longer to execute than::
ADD R7,R8,R9
???

> You could have as many
> as you want, and they could be as complicated to describe as you want,
> as long as they were simple to implement. (I've worked with a few
> PowerPC microcontrollers - PowerPC is considered "RISC", but it has a
> /lot/ of instructions!)

> In practice, though I think RISC vs CISC is more often used to
> distinguish between positions in a range of tradeoffs common in ISA
> design, such as :

> * fixed-size, fixed-format instruction codes vs variable encodings
> * many orthogonal registers vs fewer specialised registers
> * load/store vs advanced addressing modes

Like::
lui a0, %hi(.LCPI10_2)
ld a0, %lo(.LCPI10_2)(a0)
instead of::
LD R7,[IP,,.LCPT10_2]

> * "one thing at a time" vs combing common tasks in one instruction

Like:
fmv.x.d a0, ft6
call log@plt
fmv.d.x ft0, a0
instead of::
LOG R7,R9

Scott Lurndal wrote:

> David Brown <david.brown@hesbynett.no> writes:

>>>
>>> I think that "RISC" much more commonly refers to a "load/store
>>> architecture where all instruction fit well in a pipelined
>>> design". That is, the "R" is very misleading.
>>>
>>>> [snip]
>>
>>
>>I've always considered RISC to be parsed as (RI)SC rather than R(ISC) -
>>it meant small and simple instructions, rather than a small number of
>>different instructions. The idea was that instructions should, on the
>>whole, be single-cycle and implemented directly in the hardware, rather
>>than multi-cycle using sequencers or microcode. You could have as many
>>as you want, and they could be as complicated to describe as you want,
>>as long as they were simple to implement. (I've worked with a few
>>PowerPC microcontrollers - PowerPC is considered "RISC", but it has a
>>/lot/ of instructions!)

> Surely then, the PDP-8 can be counted as a RISC processor. There are
> only 8 instructions defined by a 3-bit opcode, and due to the
> instruction encoding, a single operate instruction can perform multiple
> (sequential) operations.

> 000 - AND - AND the memory operand with AC.
> 001 - TAD - Two's complement ADd the memory operand to <L,AC> (a 12 bit signed value (AC) w. carry in L).
> 010 - ISZ - Increment the memory operand and Skip next instruction if result is Zero.
> 011 - DCA - Deposit AC into the memory operand and Clear AC.
> 100 - JMS - JuMp to Subroutine (storing return address in first word of subroutine!).
> 101 - JMP - JuMP.
> 110 - IOT - Input/Output Transfer (see below).
> 111 - OPR - microcoded OPeRations (see below).

PDP-8 fails to be RISC because does not have a large number of GPRs.
Does not really have LDs (has only a LD-Op).

> https://en.wikipedia.org/wiki/PDP-8#Instruction_set

On 08/12/2023 16:19, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 07/12/2023 21:14, Marcus wrote:
>>> On 2023-12-06, MitchAlsup wrote:
>>>> Paul A. Clayton wrote:
>>>>
>>>>> On 11/24/23 9:49 PM, BGB wrote:
>>
>>>>
>>>> Both ARM and RISC-V require close to 40% more instructions than My 66000.
>>>> So much for minimum path lengths.
>>>> AND, no ISA with more than about 200 instructions should be considered
>>>> RISC,
>>>
>>> I wonder if 200 is a fundamental constant for RISC vs CISC ;-)
>>>
>>
>>
>>>>> Both RISC-V and AArch64 are RISC-oriented,
>>>>
>>>> Under a perverted view of what the R in RISC stands for.
>>>
>>> I think that "RISC" much more commonly refers to a "load/store
>>> architecture where all instruction fit well in a pipelined
>>> design". That is, the "R" is very misleading.
>>>
>>>> [snip]
>>
>>
>> I've always considered RISC to be parsed as (RI)SC rather than R(ISC) -
>> it meant small and simple instructions, rather than a small number of
>> different instructions. The idea was that instructions should, on the
>> whole, be single-cycle and implemented directly in the hardware, rather
>> than multi-cycle using sequencers or microcode. You could have as many
>> as you want, and they could be as complicated to describe as you want,
>> as long as they were simple to implement. (I've worked with a few
>> PowerPC microcontrollers - PowerPC is considered "RISC", but it has a
>> /lot/ of instructions!)
>
> Surely then, the PDP-8 can be counted as a RISC processor. There are
> only 8 instructions defined by a 3-bit opcode, and due to the
> instruction encoding, a single operate instruction can perform multiple
> (sequential) operations.
>
> 000 - AND - AND the memory operand with AC.
> 001 - TAD - Two's complement ADd the memory operand to <L,AC> (a 12 bit signed value (AC) w. carry in L).
> 010 - ISZ - Increment the memory operand and Skip next instruction if result is Zero.
> 011 - DCA - Deposit AC into the memory operand and Clear AC.
> 100 - JMS - JuMp to Subroutine (storing return address in first word of subroutine!).
> 101 - JMP - JuMP.
> 110 - IOT - Input/Output Transfer (see below).
> 111 - OPR - microcoded OPeRations (see below).
>
>
> https://en.wikipedia.org/wiki/PDP-8#Instruction_set

By my logic (such as it is - I don't claim it is in any sense
"correct"), the PDP-8 would definitely be /CISC/. It only has a few
instructions, but that is irrelevant (that was my point) - the
instructions are complex, and therefore it is CISC.

There was a microcontroller that we once considered for a project, which
had only a single instruction - "move". We ended up with a different
chip, so I never got to play with it in practice.

On 08/12/2023 16:38, Anton Ertl wrote:
> David Brown <david.brown@hesbynett.no> writes:

(I'm snipping because I pretty much agree with the rest of what you wrote.)

>
> Is Coldfire a load/store architecture? If not, it's not a RISC.
>

I agree that there's a fairly clear boundary between a "load/store
architecture" and a "non-load/store architecture". And I agree that it
is usually a more important distinction than the number of instructions,
or the complexity of the instructions, or any other distinctions.

But does that mean LSA vs. NLSA should be used to /define/ RISC vs CISC?
Things have changed a lot since the term "RISC" was first coined, and
maybe architectural and ISA features are so mixed that the terms "RISC"
and "CISC" have lost any real meaning. If that's the case, then we
should simply talk about LSA and NLSA architectures, and stop using
"RISC" and "CISC". I don't think trying to redefine "RISC" to mean
something different from its original purpose helps.

According to Scott Lurndal <slp53@pacbell.net>:
>David Brown <david.brown@hesbynett.no> writes:
>>I've always considered RISC to be parsed as (RI)SC rather than R(ISC) -
>>it meant small and simple instructions, rather than a small number of
>>different instructions. The idea was that instructions should, on the
>>whole, be single-cycle and implemented directly in the hardware, rather
>>than multi-cycle using sequencers or microcode. ...
>
>Surely then, the PDP-8 can be counted as a RISC processor. There are
>only 8 instructions defined by a 3-bit opcode, and due to the
>instruction encoding, a single operate instruction can perform multiple
>(sequential) operations.

The PDP-8 was a a PDP-5 reimplemented with newer transistors. The 12
bit PDP-5 was a cut down version of the 18 bit PDP-4 which was later
reimplented as the PDP-7, -9, and somewhat fancier -15. The PDP-4 was
a redesign of the PDP-1 to make it a lot simpler and cheaper and
modestly slower.

All of them were single accumulator single address machines, single
cycle everything where the cycles were based on the memory speed. The
PDP-8 did one cycle to fetch and decode an instruction, a second cycle
to fetch the indirect address if it was a memory reference and the
indirect bit was set, and a third cycle for memory refs to fetch or
store the operand. I think that I/O instructions might sometimes have
been a little slower to allow for the time it took signals to
propagate on the I/O bus. All of the others had the same general
design. The -15, the last in the line, was tarted up with an index
register but by that time it was clear that the PDP-11 was the winner.

I suppose you could say RISC but they weren't really reduced from
anything, they were born simple. The PDP-8 did a fantastic job of
hitting a sweet spot that could be implemented cheaply using late
1960s and 1970s technology while still being capable enough to do
significant work.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

David Brown wrote:

> On 08/12/2023 16:38, Anton Ertl wrote:
>> David Brown <david.brown@hesbynett.no> writes:

> (I'm snipping because I pretty much agree with the rest of what you wrote.)

>>
>> Is Coldfire a load/store architecture? If not, it's not a RISC.
>>

> I agree that there's a fairly clear boundary between a "load/store
> architecture" and a "non-load/store architecture". And I agree that it
> is usually a more important distinction than the number of instructions,
> or the complexity of the instructions, or any other distinctions.

Would CDC 6600 be considered to have a LD/ST architecture ??

> But does that mean LSA vs. NLSA should be used to /define/ RISC vs CISC?
> Things have changed a lot since the term "RISC" was first coined, and

It HAS been 43 years since being coined.

> maybe architectural and ISA features are so mixed that the terms "RISC"
> and "CISC" have lost any real meaning. If that's the case, then we
> should simply talk about LSA and NLSA architectures, and stop using
> "RISC" and "CISC". I don't think trying to redefine "RISC" to mean
> something different from its original purpose helps.

According to David Brown <david.brown@hesbynett.no>:
>By my logic (such as it is - I don't claim it is in any sense
>"correct"), the PDP-8 would definitely be /CISC/. It only has a few
>instructions, but that is irrelevant (that was my point) - the
>instructions are complex, and therefore it is CISC.

Having actually programmed a PDP-8 I find this assertion hard to
understand. It's true, it had instructions that both fetched an
operand and did something with it, but with only one register what
else were they going to do?

It was very RISC-like in that you used a sequence of simple
instructions to do what would would be one instruction on more complex
machines. For example, you got the effect of a load by clearing the
register (CLA) and then adding the memory word. To do subtraction,
clear, add the second operand, negate, add the first operand, maybe
negate again depending on whether you wanted A-B or B-A. We all knew a
long list of these idioms.

>There was a microcontroller that we once considered for a project, which
>had only a single instruction - "move". We ended up with a different
>chip, so I never got to play with it in practice.

I saw some of those, and the one-instruction thing was a conceit. They
all had plenty of instructions, just with the details in the operand
specifiers rather than the op code.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

David Brown <david.brown@hesbynett.no> writes:
>On 08/12/2023 16:19, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 07/12/2023 21:14, Marcus wrote:
>>>> On 2023-12-06, MitchAlsup wrote:
>>>>> Paul A. Clayton wrote:
>>>>>
>>>>>> On 11/24/23 9:49 PM, BGB wrote:
>>>
>>>>>
>>>>> Both ARM and RISC-V require close to 40% more instructions than My 66000.
>>>>> So much for minimum path lengths.
>>>>> AND, no ISA with more than about 200 instructions should be considered
>>>>> RISC,
>>>>
>>>> I wonder if 200 is a fundamental constant for RISC vs CISC ;-)
>>>>
>>>
>>>
>>>>>> Both RISC-V and AArch64 are RISC-oriented,
>>>>>
>>>>> Under a perverted view of what the R in RISC stands for.
>>>>
>>>> I think that "RISC" much more commonly refers to a "load/store
>>>> architecture where all instruction fit well in a pipelined
>>>> design". That is, the "R" is very misleading.
>>>>
>>>>> [snip]
>>>
>>>
>>> I've always considered RISC to be parsed as (RI)SC rather than R(ISC) -
>>> it meant small and simple instructions, rather than a small number of
>>> different instructions. The idea was that instructions should, on the
>>> whole, be single-cycle and implemented directly in the hardware, rather
>>> than multi-cycle using sequencers or microcode. You could have as many
>>> as you want, and they could be as complicated to describe as you want,
>>> as long as they were simple to implement. (I've worked with a few
>>> PowerPC microcontrollers - PowerPC is considered "RISC", but it has a
>>> /lot/ of instructions!)
>>
>> Surely then, the PDP-8 can be counted as a RISC processor. There are
>> only 8 instructions defined by a 3-bit opcode, and due to the
>> instruction encoding, a single operate instruction can perform multiple
>> (sequential) operations.
>>
>> 000 - AND - AND the memory operand with AC.
>> 001 - TAD - Two's complement ADd the memory operand to <L,AC> (a 12 bit signed value (AC) w. carry in L).
>> 010 - ISZ - Increment the memory operand and Skip next instruction if result is Zero.
>> 011 - DCA - Deposit AC into the memory operand and Clear AC.
>> 100 - JMS - JuMp to Subroutine (storing return address in first word of subroutine!).
>> 101 - JMP - JuMP.
>> 110 - IOT - Input/Output Transfer (see below).
>> 111 - OPR - microcoded OPeRations (see below).
>>
>>
>> https://en.wikipedia.org/wiki/PDP-8#Instruction_set
>
>By my logic (such as it is - I don't claim it is in any sense
>"correct"), the PDP-8 would definitely be /CISC/. It only has a few
>instructions, but that is irrelevant (that was my point) - the
>instructions are complex, and therefore it is CISC.

Given the age of the PDP-8, I'd argue that the instructions
are anything but complex. Leaving aside the optional EAE extension
which provided multiplication and division.

A load (hooked to the adder), a store, and a few logic operations.

The IOT instruction is effectively an MMIO operation, as in
the instruction was put on the bus and the I/O controller
responded appropriately as if it were a load or store operation.

The lack of general purpose registers doesn't disqualify it
from the RISC label in my opinion.

Likewise, the complexity that RISC was attempting to address
were instructions like the Vax POLY, MOVC3/MOCV5 and the
queuing instructions (insert & remove).

The entire RISC vs CISC argument seems somewhat contrived
in these modern times.

On 08/12/2023 20:44, John Levine wrote:
> According to David Brown <david.brown@hesbynett.no>:
>> By my logic (such as it is - I don't claim it is in any sense
>> "correct"), the PDP-8 would definitely be /CISC/. It only has a few
>> instructions, but that is irrelevant (that was my point) - the
>> instructions are complex, and therefore it is CISC.
>
> Having actually programmed a PDP-8 I find this assertion hard to
> understand. It's true, it had instructions that both fetched an
> operand and did something with it, but with only one register what
> else were they going to do?

I have never used one, and don't know about the PDP-8 in any kind of
detail. I am just responding to Scott's post. I wrote that my
understanding of "RISC" was it meant simpler instructions, not fewer
instructions, and then Scott suggested that meant the PDP-8 was "RISC"
because it had few instructions. I have no idea if the PDP-8 is/was
generally considered "RISC", but I /do/ know that Scott appeared to have
got my post completely backwards.

Based solely on the information Scott gave, however, I would suggest
that the "OPR" instruction - "microcoded operation" - and the "IOT"
operation would mean it certainly was not RISC. (This is true even if
it has other attributes commonly associated with RISC architectures.)

>
> It was very RISC-like in that you used a sequence of simple
> instructions to do what would would be one instruction on more complex
> machines. For example, you got the effect of a load by clearing the
> register (CLA) and then adding the memory word. To do subtraction,
> clear, add the second operand, negate, add the first operand, maybe
> negate again depending on whether you wanted A-B or B-A. We all knew a
> long list of these idioms.
>
>> There was a microcontroller that we once considered for a project, which
>> had only a single instruction - "move". We ended up with a different
>> chip, so I never got to play with it in practice.
>
> I saw some of those, and the one-instruction thing was a conceit. They
> all had plenty of instructions, just with the details in the operand
> specifiers rather than the op code.
>

The one I am thinking of was the MAXQ. No, it is/was not a conceit - it
was a real transfer-triggered architecture.

On 08/12/2023 20:39, MitchAlsup wrote:
> David Brown wrote:
>
>> On 08/12/2023 16:38, Anton Ertl wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>
>> (I'm snipping because I pretty much agree with the rest of what you
>> wrote.)
>
>>>
>>> Is Coldfire a load/store architecture?  If not, it's not a RISC.
>>>
>
>> I agree that there's a fairly clear boundary between a "load/store
>> architecture" and a "non-load/store architecture".  And I agree that
>> it is usually a more important distinction than the number of
>> instructions, or the complexity of the instructions, or any other
>> distinctions.
>
> Would CDC 6600 be considered to have a LD/ST architecture ??

I don't know - that was /long/ before my time!

>
>> But does that mean LSA vs. NLSA should be used to /define/ RISC vs
>> CISC?   Things have changed a lot since the term "RISC" was first
>> coined, and
>
> It HAS been 43 years since being coined.
>
>> maybe architectural and ISA features are so mixed that the terms
>> "RISC" and "CISC" have lost any real meaning.  If that's the case,
>> then we should simply talk about LSA and NLSA architectures, and stop
>> using "RISC" and "CISC".  I don't think trying to redefine "RISC" to
>> mean something different from its original purpose helps.

It appears that David Brown <david.brown@hesbynett.no> said:
>Based solely on the information Scott gave, however, I would suggest
>that the "OPR" instruction - "microcoded operation" - and the "IOT"
>operation would mean it certainly was not RISC. (This is true even if
>it has other attributes commonly associated with RISC architectures.)

The PDP-5 was built in 1963 and the term RISC dates from the late 1970s
so this is a purely hypothetical argument.

The OPR opcode had a bunch of bits that did various things to the
accumulator and the link (approximately the carry bit.) It wasn't
microcoded in the modern sense, it was that you could set more than
one bit to get more than one operation, e.g. octal 7040 bit complemented
the accumulator and 7001 incremented it, so 7041 negated it.

The IOT instructions were extremely simple, a six bit device address
field it sent out on the I/O bus, and the three low bits that sent
pulses out on three control lines. The devices did whatever they did,
read the contents of the accumulator, send back a value to put in it,
or tell the CPU to skip the next instruction which was how you tested
a flag.

Keep in mind that the PDP-8 was built from 1400 discrete transistors
and 10,000 diodes. It had to be simple.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

David Brown wrote:

> On 08/12/2023 20:39, MitchAlsup wrote:
>> David Brown wrote:
>>
>>> On 08/12/2023 16:38, Anton Ertl wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> (I'm snipping because I pretty much agree with the rest of what you
>>> wrote.)
>>
>>>>
>>>> Is Coldfire a load/store architecture?  If not, it's not a RISC.
>>>>
>>
>>> I agree that there's a fairly clear boundary between a "load/store
>>> architecture" and a "non-load/store architecture".  And I agree that
>>> it is usually a more important distinction than the number of
>>> instructions, or the complexity of the instructions, or any other
>>> distinctions.
>>
>> Would CDC 6600 be considered to have a LD/ST architecture ??

> I don't know - that was /long/ before my time!

If you wrote into A1..A5 then X1..X5 was loaded from memory
If you wrote into A6..A7 then X6..X7 was stored into memory

Peripheral processes (I/O controllers) performed the job of the OS
leaving the CPUs strictly for number crunching.

>>
>>> But does that mean LSA vs. NLSA should be used to /define/ RISC vs
>>> CISC?   Things have changed a lot since the term "RISC" was first
>>> coined, and
>>
>> It HAS been 43 years since being coined.
>>
>>> maybe architectural and ISA features are so mixed that the terms
>>> "RISC" and "CISC" have lost any real meaning.  If that's the case,
>>> then we should simply talk about LSA and NLSA architectures, and stop
>>> using "RISC" and "CISC".  I don't think trying to redefine "RISC" to
>>> mean something different from its original purpose helps.

Scott Lurndal wrote:

>
> The lack of general purpose registers doesn't disqualify it
> from the RISC label in my opinion.

Then RISC is a meaningless term.

PDP-8 certainly is simple nor does it have many instructions,
but it certainly is NOT RISC.

Did not have a large GPR register file
Was Not pipelined
Was Not single cycle execution
Did not overlap instruction fetch with execution
Did not rely on compiler for good code performance

> Likewise, the complexity that RISC was attempting to address
> were instructions like the Vax POLY, MOVC3/MOCV5 and the
> queuing instructions (insert & remove).

CALL, RET, and EDIT were nightmares to pipeline, too.
But above that:: VAX address modes prevented pipelining.

> The entire RISC vs CISC argument seems somewhat contrived
> in these modern times.

According to MitchAlsup <mitchalsup@aol.com>:
>PDP-8 certainly is simple nor does it have many instructions,
>but it certainly is NOT RISC.
>
>Did not have a large GPR register file
>Was Not pipelined
>Was Not single cycle execution
>Did not overlap instruction fetch with execution
>Did not rely on compiler for good code performance

That's a reasonable set of criteria but I think the last one is the
most important. The IBM 801 ruthlessly took everything out of the
hardware that could be done as fast in software, and the rest of the
design followed from that.

Since then RISC-y designs have incorporated virtual memory and
floating point even though the 801 didn't, because they aren't things
they tried to make the 801 do, and they turn out to be a lot faster
with hardware support.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

David Brown <david.brown@hesbynett.no> writes:
>On 08/12/2023 16:38, Anton Ertl wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>
>(I'm snipping because I pretty much agree with the rest of what you wrote.)
>
>>
>> Is Coldfire a load/store architecture? If not, it's not a RISC.
>>
>
>I agree that there's a fairly clear boundary between a "load/store
>architecture" and a "non-load/store architecture". And I agree that it
>is usually a more important distinction than the number of instructions,
>or the complexity of the instructions, or any other distinctions.

Not sure what you mean by "the complexity of the instructions".

>But does that mean LSA vs. NLSA should be used to /define/ RISC vs CISC?

Skimming in Patterson and Ditzel's 1980 paper "The Case for the
Reduced Instruction Set Computer", I fail to see a definition of RISC
(which may be one of the reasons for it being particularly easy to
claim RISCness for everything under the sky). In his 1985 paper
"Reduced instruction set computers"
<https://dl.acm.org/doi/pdf/10.1145/2465.214917>, Patterson mentioned
the 801, Berkeley RISC-I and RISC-II, and Stanford MIPS as actual RISC
machines, and saw the following common characteristics among them:

|1. Operations are register-to-register, with only LOAD and STORE
| accessing memory. [...]
| |2. The operations and addressing modes are reduced. Operations
| between registers complete in one cycle, permitting a simpler,
| hardwired control for each RISC, instead of
| microcode. Multiple-cycle instructions such as floating-point
| arithmetic are either executed in software or in a special-purpose
| coprocessor. (Without a coprocessor, RISCs have mediocre
| floating-point performance.) Only two simple addressing modes,
| indexed and PC-relative, are provided. More complicated addressing
| modes can be synthesized from the simple ones.
| |3. Instruction formats are simple and do not cross word boundaries. [...]
| |4. RlSC branches avoid pipeline penalties. [... delayed branches ...]

One commonality that Patterson fails to mention is that these are all
register machines (machines where most instructions working with
addresses or scalar integers work on general-purpose registers) with
16 or more general-purpose registers. He probably did not mention
this because the VAX and the S/360 are also register machines. Let's
call this commonality "5.".

Looking at these criteria:

2. is quite implementation-oriented. The commercial MIPS R2000 and
R3000 (descendant of Stanford MIPS) have the FPU in a coprocessor,
but the R4000 already has it on the same chip as the integer unit;
is the R4000 not a RISC? Likewise for SPARC (descendant of
Berkeley RISC) and the RSC implementation of Power (the descendant
of the 801). And commercial MIPS already has multiply and divide
instructions that do not complete in one cycle (and they involve
special-purpose registers).

RISC-V (with involvement from Patterson) has the M extension which
includes integer multiply and divide instructions which typically
take more than one cycle. Is RISC-V with the M extension not a
RISC?

Where 2. is ISA-oriented, in the addressing modes, ARM (A32), HPPA
and 88000 provided more addressing modes. Are they not RISC? I
think they have enough in common with these three RISCs that they
can be considered RISC, and that this commonality between the three
research RISCs is not a relevant criterion.

3. The ROMP (the first commercial offspring of the 801) has mixed
16-bit and 32-bit instructions, and the 32-bit instructions can
cross word boundaries. This has later been adopted by the ARM
Thumb2 (T32) instruction set (after experiments with the
16-bit-only Thumb ISA), microMIPS (after the 16-bit only MIPS16e)
and in the RISC-V C extension. Are these all not RISCs? I think
they are RISCs, so that criterion has to be relaxed to include
instruction sets with two instruction sizes with a factor of two
between them. Interestingly, ARM A64 satisfies 3 in unrelaxed
form.

4. The delayed branches are an example of an implementation-oriented
instruction set feature. The ARM architects had the wisdom to
avoid it from the start, and early RISC architectures that have it
found it to be a burden after a few years. The 88000 (1988)
already had both delayed and nondelayed branches, Power (1990) and
Alpha (1992) do not have delayed branches. Are they not RISCs?

So the only commonalities that stood the test of time are 1. and 5.

And looking at ARM A64 and RISC-V (say, RV64GC), we see two recent
architectures for general-purpose computers that mostly satisfy these
criteria. Interestingly, some RISC-V advocates (not sure if it is
Patterson) now use ARM A64 as a counterexample to the RISC idea like
Patterson used the VAX in the 1980s, but I have not heard hard
criteria for that from them.

And while AMD64 includes load-and-op and RMW instructions, it mostly
just uses one memory location. The number of GPRs has been raised
with AMD64 to 16, and APX will raise it it 32, so they took lessons
from RISC principles.

> Things have changed a lot since the term "RISC" was first coined, and
>maybe architectural and ISA features are so mixed that the terms "RISC"
>and "CISC" have lost any real meaning.

Architecture is ISA. Architectural features and ISA features are the
same thing.

Sure, many people have tried to put the "RISC" label on many things,
and if you accept that, it really has no meaning; and actually, it did
not have a meaning in the 1980 paper, and was only given meaning by
looking at the commonalities of the 3-4 prototypes in 1985; and with
hindsight, we see that only commonality 1 (and the unmentioned
commonality 5) has stood the test of time.

But we see that ARM A64 and RISC-V actually satisfy 1 and 5, more than
30 years after the early research RISCs, so these criteria provide
some benefits even in the very different implementation world of the
2010s.

ARM A64 also satisfies criterion 3, so that apparently has a benefit,
too, and RISC-V C satisfies the relaxed version of 3 while AMD64 (and
VAX and 68000 do not).

So I claim that an architecture that satisfies criterion 1, 5, and the
relaxed 3 are RISCs.

As for "CISC", that term really has no meaning other than "not RISC".
I am not aware of a proper definition, nor an enumeration of
architectures that are labeled as CISCs vs. non-CISCs. Basically, we
know that Patterson considered the VAX to be a CISC. Otherwise, the
term has been often used as "non-RISC".

>If that's the case, then we
>should simply talk about LSA and NLSA architectures, and stop using
>"RISC" and "CISC".

As we see above, RISC is still a little more than just load/store
architecture.

>I don't think trying to redefine "RISC" to mean
>something different from its original purpose helps.

That would mean that "RISC" has an original definition; what is it?

As for the purpose, the purpose is still an architecture that is a
good and stable interface to software, and can be implemented
efficiently for a wide range of performance targets over a long time.
ARM A64 seems to do quite well in that respect (although they leave
the real low end to A32/T32, where they do very well), RISC-V
currently only covers the low end of the market while the
not-quite-RISC AMD64 only covers the high end. RISC criteria 1, 5,
and relaxed 3 seem to work quite well after four decades, while
criteria 2 and 4 went by the wayside quite soon.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

scott@slp53.sl.home (Scott Lurndal) writes:
>Surely then, the PDP-8 can be counted as a RISC processor.

I don't count it as a RISC, because it's too different from the
architectures that are commonly seen as RISCs:

1. It is not a load-store architecture
5. It does not have 16 or more general-purpose registers.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

mitchalsup@aol.com (MitchAlsup) writes:
>Would CDC 6600 be considered to have a LD/ST architecture ??

If I understand the description right, the load or store happen as
side effects of an operation that writes to A1..A7. And it only loads
to X1..X5 and stores from X6..X7. If somebody says that an
architecture is a load-store architecture, I certainly do not expect
such restrictions; I actually expect a register machine (i.e., with
GPRs), but the CDC-6600 has three sets of special-purpose registers.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Sat, 09 Dec 2023 08:33:14 +0000, Anton Ertl wrote:

> That would mean that "RISC" has an original definition; what is it?

It certainly does make sense to say that the _description_ of
characteristics of existing RISC implementations in the Patterson
and Ditzel paper which you cited doesn't constitute an _original_
definition of RISC.

However, Patterson also wrote a popular article about one of the
early RISC processors with which he was connected for _Scientific
American_, and he mentioned most or all of those characteristics
there, including not having hardware floating-point, because it
took more than one cycle to execute, and, although my memory may
be wrong, it seems to me that in that article he did make the leap
to treating that as a definition rather than just an observation.

Whether or not that is true, it is indeed something like the list
from Patterson and Ditzel that is being taken as the "definition"
of RISC by those who say that what passes for RISC these days is
such as to deprive the term of meaning.

Obviously, not having hardware floating-point for the sake of
RISC purism is such a stupid idea that basically no one does that
any more. Since, however, there are still many current designs
that incorporate most of the _other_ characteristics of RISC, it
would be inappropriate to draw the conclusion from this that RISC
is now a dead and obsolete concept.

On the other hand, a lot of RISC architectures - all the instructions
are 32 bits long, the register banks have at least 32 registers in
them, the architecture is load-store - currently have OoO
implementations. Like having hardware floating-point, this is done
to get the best possible speed given the much larger number of transistors
we can put on a die this day.

Unlike allowing hardware floating-point, though, I think this
change strikes directly at the _raison d'être_ of RISC itself.

If RISC exists because it's designed around making pipelining
fast and efficient, once you've got an OoO implementation, of
what benefit is RISC? Maybe the OoO circuitry doesn't have to
work so hard, or OoO plus 32 registers can delay register
hazards even longer than OoO plus 8 registers. I don't find this
so implausible as to dismiss RISC as being now nothing more than
a marketing gimmick.

Of course, there's CISC-that's-almost-as-good-as-RISC (IBM's
z/Architecture, ColdFire, maybe even Mitch's MY 66000) and
there's CISC than which _anything_ else would be better
(such as the world's most popular ISA, devised by a company
that made MOS memories, and then branched out into making
some of the world's first single-chip microprocessors)...

Given that situation, where "good CISC" is relatively
minor in its market presence compared to bad, bad, very
bad CISC, some architecture designers have chosen to
incorporate as much of Patterson's original description,
if not definition, of RISC into their designs as is
practical in order to distance themselves more convincingly
from x86 and x86-64.

In designing Concertina II, which might well be described
as a half-breed architecture from Hell that hasn't made
up its mind whether to be RISC, CISC, or VLIW, even I have
been affected by that concern.

John Savard

Anton Ertl wrote:

>

>>I don't think trying to redefine "RISC" to mean
>>something different from its original purpose helps.

> That would mean that "RISC" has an original definition; what is it?

See the classic "Case for the Reduced Instruction Set Computer"
Katevinis.

RISC was defined before CISC was coined as its contrapositive.

> - anton

Quadibloc wrote:

>

> Of course, there's CISC-that's-almost-as-good-as-RISC (IBM's
> z/Architecture, ColdFire, maybe even Mitch's MY 66000) and

My 66000 is RISC in a purer form of RISC than ARM or RISC-V.

> there's CISC than which _anything_ else would be better
> (such as the world's most popular ISA, devised by a company
> that made MOS memories, and then branched out into making
> some of the world's first single-chip microprocessors)...

> Given that situation, where "good CISC" is relatively
> minor in its market presence compared to bad, bad, very
> bad CISC, some architecture designers have chosen to
> incorporate as much of Patterson's original description,
> if not definition, of RISC into their designs as is
> practical in order to distance themselves more convincingly
> from x86 and x86-64.

Even x86 designers use RISC to distance themselves from CISC.

> In designing Concertina II, which might well be described
> as a half-breed architecture from Hell that hasn't made
> up its mind whether to be RISC, CISC, or VLIW, even I have
> been affected by that concern.

The only things in My 66000 that are not on the 7 Tenets of RISC
is the attachments of constants as replacements for registers.

> John Savard

Quadibloc <quadibloc@servername.invalid> writes:
>However, Patterson also wrote a popular article about one of the
>early RISC processors with which he was connected for _Scientific
>American_,

A short web search on that came up empty. Do you have a reference?

>On the other hand, a lot of RISC architectures - all the instructions
>are 32 bits long, the register banks have at least 32 registers in
>them, the architecture is load-store - currently have OoO
>implementations. Like having hardware floating-point, this is done
>to get the best possible speed given the much larger number of transistors
>we can put on a die this day.
>
>Unlike allowing hardware floating-point, though, I think this
>change strikes directly at the _raison d'être_ of RISC itself.

That's the interesting thing. It doesn't.

>If RISC exists because it's designed around making pipelining
>fast and efficient, once you've got an OoO implementation, of
>what benefit is RISC?

It's still simpler. With a load-and-op instruction, you have to split
the instruction into the load part and the op part, they find their
way through the OoO engine, and eventually you have to combine them
again in the ROB. With RMW, things become even more interesting; AMD
had (maybe still has) an R_W uop (ROP in AMD parlance) which works
before and after the ALU part. Obviously all doable, but it adds to
the complexity. Which was first, the PowerPC 604 or the Pentium Pro?

>Maybe the OoO circuitry doesn't have to
>work so hard,

Or the microarchitects and validators don't have to work so hard.

>or OoO plus 32 registers can delay register
>hazards even longer than OoO plus 8 registers.

Doubtful; with a given amount of physical registers, you then have 24
less registers for reordering. The more relevant reason for 32
registers is for code that has to deal with more than 16 values at the
same time; they reduce the need for loads and stores for spilling, and
for hardware-optimizing store-load dependencies. It's no surprise
that both Tiger Lake (Intel) and Zen 3 (AMD) perform store-to-load
forwarding at 0 cycle latency (which probably did cost quite a bit of
design work and who knows how much silicon), while it takes 5 cycles
or so on Firestorm (Apple); Firestorm does not need that optimization
as dearly.

>Of course, there's CISC-that's-almost-as-good-as-RISC (IBM's
>z/Architecture, ColdFire,

What makes you think so?

>there's CISC than which _anything_ else would be better
>(such as the world's most popular ISA, devised by a company
>that made MOS memories, and then branched out into making
>some of the world's first single-chip microprocessors)...

AMD made MOS memories and some of the world's first single-chip
microprocessors?

Anyway, you seem to be referring to AMD64, but the rest is unclear.
Intel and AMD have avoided the complexities of VAX in designing IA-32
and AMD64; in particular, every instruction (but MOVS and the
newfangled gather and scatter instructions, shame on Intel, and they
were rewarded with Downfall) only refers to one memory location.

>some architecture designers have chosen to
>incorporate as much of Patterson's original description,
>if not definition, of RISC into their designs as is
>practical in order to distance themselves more convincingly
>from x86 and x86-64.

I doubt that "distancing themselves from x86 and x86-64" was any
consideration in the ARM A64 and RISC-V designs. Of course they would
not design in architectural ideas where the patent has not expired,
but for load-and-op, RMW, or three-memory-address-with-autoincrement
instructions, any patents that may have existed have long expired.

The ARM A64 seem to have had no qualms at introducing features like
load-pair and store-pair that raise eyebrows among purists, so if they
thought they would gain enough by deviating from A64 being a
load-store architecture, or from sticking to fixed-width instructions,
or from it having 32 registers, they would have gone there.
Apparently they did not think so, and the IPC and performance per Watt
of Firestorm indicates that they have designed well.

The surviving RISC properties are no longer as important as they were
in the late 1980s, but they still result in fewer problems for the
microarchitects to solve, and all of what goes with lower complexity.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On 12/2/23 3:39 PM, MitchAlsup wrote:
> Paul A. Clayton wrote:
[snip]
>> (Itanium showed that mediocre hardware translation between x86 and
>> a rather incompatible architecture (and microarchitecture) would
>> have been problematic even if native Itanium code had competitive
>
> So did Transmeta.

Transmeta did not use hardware translation and actually attempted
to have decent performance. (I think originally Transmeta was
seeking high performance at lower area before switching to lower
power as a goal.) For Itanium, binary translation provided better
performance on the same hardware, so it was more evident that the
compatibility had a mediocre performance target.

On 12/6/23 9:52 AM, MitchAlsup wrote:
> Paul A. Clayton wrote:
[snip]
>> I rather suspect these benchmarks do not provide a good basis for
>> ISA design targeting minimum path length (much less performance).
>
> Both ARM and RISC-V require close to 40% more instructions than My
> 66000.
> So much for minimum path lengths.

This sort of measurement is very benchmark dependent (and
significantly compiler dependent). I seem to recall that you used
EMBC benchmarks, which may actually make My 66000 look less good
since calls outside of the ±1MiB JAL range of RISC-V and the
±128MiB of AArch64 would be less frequent. (I was surprised that
stack frames were large enough to cause problems for RISC-V, but I
am not familiar with the benchmark suite.) I think you also used
static code size not path length.

Path length is also not the ultimate goal. If it was something
with even more complex instructions than VAX would be ideal.

> AND, no ISA with more than about 200 instructions should be
> considered RISC,

That would be using the original Berkeley definition of reduced
number of instructions. Reduced work per instruction, i.e.,
simpler instructions, is also a characteristic of RISCs. (The two
are related since there are fewer simple instructions than simple
instructions plus all reasonable compositions of those simple
instructions.)

Counting defined instructions is difficult. If the I, S1, S2, S,
and d bits are considered part of the opcode, the instruction
count for My 66000 would greatly increase (32x for 2-operand
instructions); since these are somewhat regular control signals
(somewhat comparable to register fields) including them in the
opcode for instruction count is somewhat questionable (though the
effect of the bits does vary a little depending on the operation,
e.g., complement vs. negate for S1 and S2).

[snip]
> My data indicates the indexed advantage is in the 2%-3% range.

I would have guessed that for some "scientific" code the
difference would be closer to 5% (or more), but that would be just
a guess based on my impression of such frequently using array
accesses with a common index.

>> Both RISC-V and AArch64 are RISC-oriented,
>
> Under a perverted view of what the R in RISC stands for.

From John Mashey's famous post:
> The RISC characteristics:
> a) Are aimed at more performance from current compiler technology
> (i.e., enough registers).
OR
> b) Are aimed at fast pipelining
> in a virtual-memory environment
> with the ability to still survive exceptions
> without inextricably increasing the number of gate delays
> (notice that I say gate delays, NOT just how many gates).

[snip]

> MOST RISCs:
> 3a) Have 1 size of instruction in an instruction stream
> 3b) And that size is 4 bytes
> 3c) Have a handful (1-4) addressing modes) (* it is VERY
> hard to count these things; will discuss later).
> 3d) Have NO indirect addressing in any form (i.e., where you need
> one memory access to get the address of another operand in memory)
> 4a) Have NO operations that combine load/store with arithmetic,
> i.e., like add from memory, or add to memory.
> (note: this means especially avoiding operations that use the
> value of a load as input to an ALU operation, especially when
> that operation can cause an exception. Loads/stores with
> address modification can often be OK as they don't have some of
> the bad effects)
> 4b) Have no more than 1 memory-addressed operand per instruction
> 5a) Do NOT support arbitrary alignment of data for loads/stores
> 5b) Use an MMU for a data address no more than once per instruction
> 6a) Have >= 5 bits per integer register specifier
> 6b) Have >= 4 bits per FP register specifier

AArch64 has 3a, 3b, 3d (not sure how many addressing modes it
has), 4a (if one excludes atomics; I would count such as partial
exceptions), 4b, 5b (if one excludes unaligned data as potentially
requiring two MMU uses), 6a, and 6b. RISC-V has 3c, 3d, 4a (again
excluding atomics), 4b, 5b, 6a, and 6b.

By this measure both are RISCy.

[snip]
> Captain Obvious strikes again.

Fighting a never ending battle for truth, justice, and — well, at
least making an occasional effort to state something that has some
truthful content.

On 12/3/23 10:01 AM, Anton Ertl wrote:
> "Paul A. Clayton" <paaronclayton@gmail.com> writes:
>> A uniquely difficult architecture like x86 increases the barrier
>> to competition both from patents and organizational knowledge and
>> tools. While MIPS managed to suppress clones with its patent on
>> unaligned loads (please correct any historical inaccuracy), Intel
>> was better positioned to discourage software-compatible
>> competition — and not just financially.
>
> Really? There is software-compatible competition to Intel. Not so
> much for MIPS (maybe Loongson).

There is also less economic incentive to seek binary compatibility
with MIPS. Even when MIPS was used by multiple UNIX system
vendors, binaries would not be compatible across UNIXes. Targeting
workstations also influenced the economics of cloning.

RISCs were also so simple that "anyone" could make one. Binary
translation for a fixed-length instruction RISC would also be much
easier than for even S/360.

x86 had an early dual-source agreement (which introduced AMD,
correct?) and earlier x86 vendors gained use of the ISA when Intel
would probably have preferred a purer monopoly.

>> I suspect that the bad reputation of x86 among computer architects
>> — especially with the biases from Computer Architecture: A
>> Quantitative Approach which substantially informs computer
>> architecture education
>
> If you have looked at recent editions of this book, you would not
> write that. They apparently have lost interest in discussing
> instruction sets. The fifth edition from 2012 moves that discussion
> to an appendix and I am not sure if a later edition has not removed it
> from the printed book completely.

That could be considered worse; ISA is so obvious (or unimportant)
that the considerations are presented in an appendix.

Your later comments are interesting, but I have not thought about
them enough to write a decent response or affirmation. I did
appreciate the read (and the future opportunity to think).

I tend to like "horses for courses", where VLIW deserves a place
in a study of computer architecture (it is used for special-
purpose DSPs such as for hearing aids). The architecture and
microarchitecture of a GPU are interesting and not the same as for
a "general-purpose" CPU.

> The discussion about OoO that I have looked at in some recent edition
> seems to miss important points for latency-dominated computing. It
> seems to me that the authors are mainly interested in supercomputing
> these days, certainly the fifth edition looks that way.
>
> If that's the book that biases computer architects, there is more to
> worry about than just ISA. The supercomputer attitude is a mistake
> that has been the bane of many architectures, even very well-funded
> ones like IA-64.
>
>> The binary lock-in advantage of x86 makes architectural changes
>> more challenging. While something like the 8080 to 8086 "assembly
>> compatible" transition might have been practical and long-term
>> beneficial from an engineering perspective, from a business
>> perspective such would validate binary translation, reducing the
>> competitive barriers.
>
> Actually while people who know nothing about instruction sets write
> "x86", there are three different instruction sets on any recent Intel
> or AMD CPU: 8086/286, IA-32, and AMD64. You cannot run IA-32 programs
> in the same mode as AMD64 programs, just like ARM A32/T32 and ARM A64.
>
> And while AFAIK you can switch between IA-32 and 8086 with two
> user-mode bits (or prefixes), that usually does not happen. And the
> addressing modes are actually very different; I bought a book that
> claimed to cover CPUs up to the Pentium, but it actually did not cover
> IA-32 addressing modes and instructions and therefore was totally
> useless for me.
>
>> (Itanium showed that mediocre hardware translation between x86 and
>> a rather incompatible architecture (and microarchitecture) would
>> have been problematic even if native Itanium code had competitive
>> performance.
>
> It seems to me that both hardware and software binary translation
> would have fared much better on an OoO target CPU.
>
>> On the other hand, ARM designed a 64-bit
>> architecture that is only moderately compatible with the 32-bit
>> architecture — flags being one example of compatibility
>
> There is no compatibility at the ISA level. Using flags is a
> similarity, not compatibility.
>
>> MIPS (even with its delayed branches, lack of variable length
>> encoding, etc.) would probably be a better architecture in 2023
>> than x86 was around 2010.
>
> As far as Gforth is concerned, MIPS is worse than every other
> architecture that has architecture-specific support. Admittedly,
> Gforth's requirements may not be that important to most, but all other
> architectures satisfy them:
>
> * Each instruction block between two branch targets stands on its own
> and can be concatenated with any other such block, and perform the
> effect of the first block followed by the effect of the second.
> MIPS does not satisfy that because of load delay slots (and probably
> also the scheduling limitations involving the multiply/division
> unit).
>
> * Direct branches are relative or absolute. MIPS has
> not-quite-absolute branches that combine the top bits of the branch
> address with the bottom bits coming from the instruction.
>
> As a result, Gforth unconditionally disables dynamic native code
> generation on MIPS; disabling dynamic native code generation costs a
> factor 1.58-4.36 on Rocket Lake (numbers are times in seconds)
>
> sieve bubble matrix fib fft
> 0.043 0.042 0.014 0.032 0.014 dynamic native code generation
> 0.068 0.077 0.061 0.082 0.032 --no-dynamic
>
> There is too much supercomputer attitude in MIPS. Fortunately, its
> successors Alpha and RISC-V have fixed both problems. And
> interestingly, even a very supercomputer-attitude architecture like
> IA-64 satisfies Gforth's requirements just fine.
>
> - anton
>