The Motorola 68000 has 16 (somewhat) general-purpose registers of 32 bits each, a generous complement by the standards of its day. I would expect these to take a significant fraction of the die area. (If they didn't, there would be little reason for competing microprocessors like the 8086 to fail to provide something similar.)

Back of the envelope calculation, 16x32x6 (static memory takes six transistors per bit) = 3072 transistors. The 68k is reckoned to have 40k transistors if you don't count microcode, almost 70k if you do. So the memory cells for the registers should take somewhere around 5% of the die; maybe it's closer to 10% if you also take the access circuitry into account?

That is surprisingly small, sufficiently so that it seems like 32 registers could've been provided. (The ARM-1 did exactly that, somewhat later but with similar process technology.) Maybe the instruction encoding space would have been considered a problem. Or maybe the designers were considering use of compiled languages, and noting contemporary compilers were not good at using lots of registers.

Trying to find an annotated die photo, I found this: http://www.easy68k.com/paulrsm/doc/dpbm68k2.htm

Which... doesn't mention the registers at all, nor leave any unaccounted space where they could be.

Is there an error in the annotation? or are the registers part of one of the marked units?

On Thursday, July 6, 2023 at 12:30:54 PM UTC-5, Russell Wallace wrote:
> The Motorola 68000 has 16 (somewhat) general-purpose registers of 32 bits each, a generous complement by the standards of its day. I would expect these to take a significant fraction of the die area. (If they didn't, there would be little reason for competing microprocessors like the 8086 to fail to provide something similar.)
>
> Back of the envelope calculation, 16x32x6 (static memory takes six transistors per bit) = 3072 transistors. The 68k is reckoned to have 40k transistors if you don't count microcode, almost 70k if you do. So the memory cells for the registers should take somewhere around 5% of the die; maybe it's closer to 10% if you also take the access circuitry into account?
>
> That is surprisingly small, sufficiently so that it seems like 32 registers could've been provided. (The ARM-1 did exactly that, somewhat later but with similar process technology.) Maybe the instruction encoding space would have been considered a problem. Or maybe the designers were considering use of compiled languages, and noting contemporary compilers were not good at using lots of registers.
>
> Trying to find an annotated die photo, I found this: http://www.easy68k.com/paulrsm/doc/dpbm68k2.htm
<
The register files are easy to see. Go to the address lower section block. Towards the right is a rectangular
stippled section--this is the register file.
<
Now go to the address high block, and towards the left hand side is a rectangular section twice as wide.
This is the register file. They did this so the 2 arithmetic units would be closer (for carry).
<
Over in the data section, towards the left is another rectangular section the same size as the lower address
section with the same stipple pattern. These are the data registers.
<
The PC is in both address units, and there are a couple of address and data registers that only
microcode uses.
<
If you find a picture without the words on top, I can illustrate where the ALUs are and the shifters,.....
>
> Which... doesn't mention the registers at all, nor leave any unaccounted space where they could be.
>
> Is there an error in the annotation? or are the registers part of one of the marked units?

On 7/6/2023 10:30 AM, Russell Wallace wrote:
> The Motorola 68000 has 16 (somewhat) general-purpose registers of 32 bits each, a generous complement by the standards of its day. I would expect these to take a significant fraction of the die area. (If they didn't, there would be little reason for competing microprocessors like the 8086 to fail to provide something similar.)

As has been mentioned here recently, and many time before and in other
places, the 8086 was designed as an almost upward compatible successor
to the 8080, which was an accumulator design with few registers. Intel
didn't add more registers till later.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Thursday, July 6, 2023 at 7:31:00 PM UTC+1, MitchAlsup wrote:
> The register files are easy to see. Go to the address lower section block.. Towards the right is a rectangular
> stippled section--this is the register file.
> <
> Now go to the address high block, and towards the left hand side is a rectangular section twice as wide.
> This is the register file. They did this so the 2 arithmetic units would be closer (for carry).
> <
> Over in the data section, towards the left is another rectangular section the same size as the lower address
> section with the same stipple pattern. These are the data registers.
> <
> The PC is in both address units, and there are a couple of address and data registers that only
> microcode uses.

Aha! Thanks.

> If you find a picture without the words on top, I can illustrate where the ALUs are and the shifters,.....

This is a more detailed, non-annotated picture:
http://www.visual6502.org/images/68000/Motorola_68000_die_20x_1a_top_10000w..png

On Thursday, July 6, 2023 at 7:49:14 PM UTC+1, Stephen Fuld wrote:
> As has been mentioned here recently, and many time before and in other
> places, the 8086 was designed as an almost upward compatible successor
> to the 8080, which was an accumulator design with few registers. Intel
> didn't add more registers till later.

Oh, indeed! But it only needed to be compatible at the assembly level, not binary machine code. They could have added more registers.

Indeed, they never did voluntarily add more registers to x86, only when AMD forced their hand, much later, with x64.

On Thursday, July 6, 2023 at 11:30:54 AM UTC-6, Russell Wallace wrote:

> That is surprisingly small, sufficiently so that it seems like 32 registers could've been provided.

The Motorola 68000 divided the 16 registers it did provide into two
groups; the general registers and the address registers. So it needed
three-bit fields to specify a register in either group.

The Motorola 68000 was a CISC processor; it didn't "need" more than
eight registers in a register bank. Providing 32 registers is something
RISC processors do - for them, it's worth the opcode space, because
opcode space is saved elsewhere (mainly by making all memory-reference
instructions only loads and stores).

John Savard

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Thursday, July 6, 2023 at 11:30:54 AM UTC-6, Russell Wallace wrote:
>
>> That is surprisingly small, sufficiently so that it seems like 32 registers could've been provided.
>
> The Motorola 68000 divided the 16 registers it did provide into two
> groups; the general registers and the address registers. So it needed
> three-bit fields to specify a register in either group.
>
> The Motorola 68000 was a CISC processor; it didn't "need" more than
> eight registers in a register bank.

Considering other microprocessors at the time, this was sheer luxury.

I found an interesting article about the design of the M68K at
http://www.easy68k.com/paulrsm/doc/dpbm68k1.htm . I also found
the section on microcode interesting, especially knowing what we
know now about RISC designs and the different tradeoffs they used.

One should also not forget bus width, which also costs money.
The ARM2 was able to beat the 68000 on speed by a large factor
with a lower transistor count, but it also had a 32-bit data bus
(which, considering periphery, might have been too expensive when
the 68000 was designed).

Quadibloc wrote:
> On Thursday, July 6, 2023 at 11:30:54 AM UTC-6, Russell Wallace wrote:
>
>> That is surprisingly small, sufficiently so that it seems like 32 registers could've been provided.
>
> The Motorola 68000 divided the 16 registers it did provide into two
> groups; the general registers and the address registers. So it needed
> three-bit fields to specify a register in either group.
>
> The Motorola 68000 was a CISC processor; it didn't "need" more than
> eight registers in a register bank. Providing 32 registers is something
> RISC processors do - for them, it's worth the opcode space, because
> opcode space is saved elsewhere (mainly by making all memory-reference
> instructions only loads and stores).
>
> John Savard

CISC's require temp registers to hold intermediate values,
which becomes overhead if unused. Also this can create internal
RAW dependencies that cause stalls which, because they are internal,
cannot be avoided by rearranging your instruction order.

RISC's make such intermediate values explicit and can sometimes move
the RAW dependencies so they don't stall. Registers not used to hold
such intermediates don't sit idle and are available to programmers.

CISC's have many optional instruction features, and that buggers up
in-order pipeline designs which like everything to be the same.
So a CISC could wind up having to insert multiple pipeline stages,
increasing the latency, just to support some rarely used features.

RISC's make the consumer of a rare and complex features pay.
If your program needs double-indirect auto-increment addressing **ptr++
then only you pay the cost in terms of clocks, temp registers, and stalls.

This isn't just RISC performance advantages, but also lower R&D costs
that are amortized across units sold, shortens time to market and how
quickly you can utilized new processes to gain a product advantage,
and minimizes time to generate revenue and return on investment.

The 68000 probably took dozens of engineers 3 years to design.
The Stanford MIPS and RISC-I took about two grad students 6 months
(excluding costs for all the software tools they had to develop).

Quadibloc <jsavard@ecn.ab.ca> writes:
>The Motorola 68000 divided the 16 registers it did provide into two
>groups; the general registers and the address registers. So it needed
>three-bit fields to specify a register in either group.
>
>The Motorola 68000 was a CISC processor; it didn't "need" more than
>eight registers in a register bank.

Counterexamples: IBM S/360, VAX, AMD64, all of which have ~16
general-purpose registers.

I think that the 16-bit memory interface of the 68000 meant that they
wanted to have many instructions that fit in 16 bits, and with more
than 8 registers this becomes difficult (see also the PDP-11). The
8086 is an example that trying to fit useful instructions in 8 bits
leads to even more limitations.

Another example is the RISC-V C extension (16-bit wide instructions),
where a number of these instructions can access only 8 of the 32
registers of the architecture.

>Providing 32 registers is something
>RISC processors do - for them, it's worth the opcode space, because
>opcode space is saved elsewhere

No, it's because they have the opcode space. All those with 32
registers have 32-bit memory interfaces and therefore could afford
32-bit instructions, so they could afford encoding registers in 5
bits. ARM1/2 also has a 32-bit memory interface and 32-bit
instructions, but only 16 GPRs (maybe due to area concerns, maybe
because the 801 only has 16 registers), and used the extra bits for
stuff like shifts or conditions.

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

On Sunday, July 9, 2023 at 12:53:49 AM UTC-5, Quadibloc wrote:
> On Thursday, July 6, 2023 at 11:30:54 AM UTC-6, Russell Wallace wrote:
>
> > That is surprisingly small, sufficiently so that it seems like 32 registers could've been provided.
> The Motorola 68000 divided the 16 registers it did provide into two
> groups; the general registers and the address registers. So it needed
> three-bit fields to specify a register in either group.
<
8 DATA registers and 8 Address registers.
>
> The Motorola 68000 was a CISC processor; it didn't "need" more than
> eight registers in a register bank. Providing 32 registers is something
> RISC processors do - for them, it's worth the opcode space, because
> opcode space is saved elsewhere (mainly by making all memory-reference
> instructions only loads and stores).
<
It is more correct to say, the designers did not think they needed more
registers, time has shown that they would have performed better with
more.
>
> John Savard

On Sunday, July 9, 2023 at 4:30:01 AM UTC-5, Thomas Koenig wrote:
> Quadibloc <jsa...@ecn.ab.ca> schrieb:
> > On Thursday, July 6, 2023 at 11:30:54 AM UTC-6, Russell Wallace wrote:
> >
> >> That is surprisingly small, sufficiently so that it seems like 32 registers could've been provided.
> >
> > The Motorola 68000 divided the 16 registers it did provide into two
> > groups; the general registers and the address registers. So it needed
> > three-bit fields to specify a register in either group.
> >
> > The Motorola 68000 was a CISC processor; it didn't "need" more than
> > eight registers in a register bank.
> Considering other microprocessors at the time, this was sheer luxury.
>
> I found an interesting article about the design of the M68K at
> http://www.easy68k.com/paulrsm/doc/dpbm68k1.htm . I also found
> the section on microcode interesting, especially knowing what we
> know now about RISC designs and the different tradeoffs they used.
<
That section is standard Wilke's Microcode asperation--which was
in vogue at the time.
<
It took pipeline RISC designs to shake the tree and have the apple
fall to the ground.
>
> One should also not forget bus width, which also costs money.
> The ARM2 was able to beat the 68000 on speed by a large factor
> with a lower transistor count, but it also had a 32-bit data bus
> (which, considering periphery, might have been too expensive when
> the 68000 was designed).

On Sunday, July 9, 2023 at 10:26:45 AM UTC-5, EricP wrote:
> Quadibloc wrote:
> > On Thursday, July 6, 2023 at 11:30:54 AM UTC-6, Russell Wallace wrote:
> >
> >> That is surprisingly small, sufficiently so that it seems like 32 registers could've been provided.
> >
> > The Motorola 68000 divided the 16 registers it did provide into two
> > groups; the general registers and the address registers. So it needed
> > three-bit fields to specify a register in either group.
> >
> > The Motorola 68000 was a CISC processor; it didn't "need" more than
> > eight registers in a register bank. Providing 32 registers is something
> > RISC processors do - for them, it's worth the opcode space, because
> > opcode space is saved elsewhere (mainly by making all memory-reference
> > instructions only loads and stores).
> >
> > John Savard
> CISC's require temp registers to hold intermediate values,
> which becomes overhead if unused. Also this can create internal
> RAW dependencies that cause stalls which, because they are internal,
> cannot be avoided by rearranging your instruction order.
<
Generally these registers are only used when running a multi-step
microcode routine.
>
> RISC's make such intermediate values explicit and can sometimes move
> the RAW dependencies so they don't stall. Registers not used to hold
> such intermediates don't sit idle and are available to programmers.
>
> CISC's have many optional instruction features, and that buggers up
> in-order pipeline designs which like everything to be the same.
> So a CISC could wind up having to insert multiple pipeline stages,
> increasing the latency, just to support some rarely used features.
<
Certainly PDP-11, VAX, 68K, N32K, and a few more had those features.
Other CISCs did not: 360/370, Interdata, S.E.L, ...
>
> RISC's make the consumer of a rare and complex features pay.
> If your program needs double-indirect auto-increment addressing **ptr++
> then only you pay the cost in terms of clocks, temp registers, and stalls..
<
It ends up that one can pipeline away the cache reads in a 360-like ISA
that cannot be pipelined away in a PDP-11/VAX-like ISA; making an
inbound memory read "almost" equal in latency as a register read.
>
> This isn't just RISC performance advantages, but also lower R&D costs
> that are amortized across units sold, shortens time to market and how
> quickly you can utilized new processes to gain a product advantage,
> and minimizes time to generate revenue and return on investment.
>
> The 68000 probably took dozens of engineers 3 years to design.
> The Stanford MIPS and RISC-I took about two grad students 6 months
> (excluding costs for all the software tools they had to develop).

On 7/9/2023 10:34 AM, Anton Ertl wrote:
> Quadibloc <jsavard@ecn.ab.ca> writes:
>> The Motorola 68000 divided the 16 registers it did provide into two
>> groups; the general registers and the address registers. So it needed
>> three-bit fields to specify a register in either group.
>>
>> The Motorola 68000 was a CISC processor; it didn't "need" more than
>> eight registers in a register bank.
>
> Counterexamples: IBM S/360, VAX, AMD64, all of which have ~16
> general-purpose registers.
>
> I think that the 16-bit memory interface of the 68000 meant that they
> wanted to have many instructions that fit in 16 bits, and with more
> than 8 registers this becomes difficult (see also the PDP-11). The
> 8086 is an example that trying to fit useful instructions in 8 bits
> leads to even more limitations.
>
> Another example is the RISC-V C extension (16-bit wide instructions),
> where a number of these instructions can access only 8 of the 32
> registers of the architecture.
>

FWIW:
Both SuperH (and also BJX2) can use 16 GPRs for the 16-bit instruction
encodings.

However, in both ISA's, they are effectively Load/Store with typically
only 2R encodings for the 16-bit ops.

In my case, there are some 16-bit ops with access to R16..R31, but
mostly limited to special cases:
MOV, ADD
MOV.{L/Q} (SP, Disp4), Rn
...
Nothing in 16-bit land has access to R32..R63 though.

Both RISC-V C and Thumb tried for 3R encodings within the 16-bit opcode
space. But, arguably this doesn't seem terribly worthwhile as the "hit
rate" for being limited to 8 registers is lower than that for being
limited to, say: "Rn=Rn+Rm;" and similar.

Comparably, both RV-C and Thumb had a lot of hair in terms of their
16-bit encodings as well.

MSP430 managed 16-bit instructions, 16 registers, and CISC-like Reg/Mem
operations, but paid for this by having an absurdly small opcode space
(with a lot of instructions being encoded by playing trickery with the
register fields and addressing modes).

>> Providing 32 registers is something
>> RISC processors do - for them, it's worth the opcode space, because
>> opcode space is saved elsewhere
>
> No, it's because they have the opcode space. All those with 32
> registers have 32-bit memory interfaces and therefore could afford
> 32-bit instructions, so they could afford encoding registers in 5
> bits. ARM1/2 also has a 32-bit memory interface and 32-bit
> instructions, but only 16 GPRs (maybe due to area concerns, maybe
> because the 801 only has 16 registers), and used the extra bits for
> stuff like shifts or conditions.
>

In my case, I have some encodings (and an operating mode) which have
6-bit register fields, conditional execution, etc.

But, compared with most RISC's (with a 32-bit instruction size), mine
has comparably small immediate fields.

Though, interestingly, XG2 Mode has typically the same sized immediate
fields as SH-5 (which also had 6-bit register fields).

Baseline mode only has 5-bit register fields for the most part, whereas
XG2 gains 6-bit fields at the expense of making the 16-bit ops N/E.

I don't see the smaller immediate fields as too big of a loss though:
There is a reasonably good hit-rate with the current immediate fields;
The ISA design does not overly penalize cases where an immediate can't
fit in the immediate-field;
There are also Jumbo prefixes.

In contrast, in RISC-V, if one exceeds the 12-bit immediate field one is
typically looking at a 3 instruction fallback case.

But, OTOH, my ISA has both:
ADD Rm, Imm9u, Rn
And:
ADD Imm16s, Rn

Whereas RISC-V only has:
ADD Rd, Rs, Imm12s

Partly because some tasks (like adjusting the stack pointer) don't map
over well to a 9-bit immediate field.

Also the first version of my ISA design only had 5-bit immediate fields,
but these were quickly revealed to be... insufficient...

If I were to try to shoe-horn my entire "wish-list" into a 32-bit
instruction word (and have an OK amount of opcode space), would mostly
end up needing to reduce most immediate values to 6 bits (with ~ 12 bits
for 2RI encodings), which is "less good".

So, it seemed "less bad" to not be able to encode some features in some
combinations, than to be able to encode them but then have nearly
everything being limited to 6-bit immediate fields.

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:

> I think that the 16-bit memory interface of the 68000 meant that they
> wanted to have many instructions that fit in 16 bits, and with more
> than 8 registers this becomes difficult (see also the PDP-11). The
> 8086 is an example that trying to fit useful instructions in 8 bits
> leads to even more limitations.

This is a bit into an alternative past...

A load-store architecture with 16-bit instruction words could have
16 registers, a = a op b instructions. This would leave 256 opcodes.

However, a strict 16-bit word would probably not work too well
well because lack of constants, the familar RISC problem made more
pressing by having fewer bits. Putting in "load register lower" and
"load regster upper" might have been possible, but would have
eaten into the opcode space big time. More flexibility could
probably have been achieved using one register as second operand
as marker for a constant following in the instruction stream.

It might be fun to design an alternative to the PDP-11, but one
should not forget code size: In the days of core memory, memory
was _really_ expensive. I am not sure how such a proto-RISC
would compete on code size.

On 7/9/2023 1:57 PM, Thomas Koenig wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>
>> I think that the 16-bit memory interface of the 68000 meant that they
>> wanted to have many instructions that fit in 16 bits, and with more
>> than 8 registers this becomes difficult (see also the PDP-11). The
>> 8086 is an example that trying to fit useful instructions in 8 bits
>> leads to even more limitations.
>
> This is a bit into an alternative past...
>
> A load-store architecture with 16-bit instruction words could have
> 16 registers, a = a op b instructions. This would leave 256 opcodes.
>

Example: SuperH...

They used the layouts:
ZnmZ
ZnZZ
Znii (ADD/MOV)
ZZii
Ziii (BRA/BSR)

Also some of my own designs followed a similar pattern.

> However, a strict 16-bit word would probably not work too well
> well because lack of constants, the familar RISC problem made more
> pressing by having fewer bits. Putting in "load register lower" and
> "load regster upper" might have been possible, but would have
> eaten into the opcode space big time. More flexibility could
> probably have been achieved using one register as second operand
> as marker for a constant following in the instruction stream.
>

Yeah, this issue sucked on SuperH...

Though, the main mechanism in the official ISA was to do PC relative
memory loads. This kinda sucked, as it is both inefficient and awkward
for the compiler (more so as the constant needed to appear within the
code-stream within a relatively short distance of the instruction that
needed it).

One workaround used in my own modified variant was to add an LDSH
instruction which did R0=(R0<<8)|Imm8 ...

So, say:
MOV 0x12, R0
LDSH 0x34, R0
LDSH 0x56, R0
LDSH 0x78, R0
Could load 0x12345678 into R0 (then R0 could be used as a constant for
another instruction).

Apparently, SH-5 had done something similar, but called their
instruction "SHORI" instead.

> It might be fun to design an alternative to the PDP-11, but one
> should not forget code size: In the days of core memory, memory
> was _really_ expensive. I am not sure how such a proto-RISC
> would compete on code size.

Yeah.

I think the story was that SH went on to inspire Thumb, though Thumb's
design is quite different from SH in many regards.

Code density from SH tends to be a little worse than that from 16/32
designs (like Thumb-2 or RV-C).

According to Thomas Koenig <tkoenig@netcologne.de>:
>One should also not forget bus width, which also costs money.
>The ARM2 was able to beat the 68000 on speed by a large factor
>with a lower transistor count, but it also had a 32-bit data bus
>(which, considering periphery, might have been too expensive when
>the 68000 was designed).

The original 68000 came in 16 and 8 bit bus versions, just like the 8086 and 8088.

Legend says that if Moto had been able to ship the 68008 in quantity,
IBM would have used it in the IBM PC rather than the 8088. If only.

--
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

On 7/9/2023 2:55 PM, John Levine wrote:
> According to Thomas Koenig <tkoenig@netcologne.de>:
>> One should also not forget bus width, which also costs money.
>> The ARM2 was able to beat the 68000 on speed by a large factor
>> with a lower transistor count, but it also had a 32-bit data bus
>> (which, considering periphery, might have been too expensive when
>> the 68000 was designed).
>
> The original 68000 came in 16 and 8 bit bus versions, just like the 8086 and 8088.
>
> Legend says that if Moto had been able to ship the 68008 in quantity,
> IBM would have used it in the IBM PC rather than the 8088. If only.
>

I guess a question is if it had been used in the PC instead of x86, if
Motorola could have then made it performance competitive with what later
x86 systems became?...

Like, seemingly, relative to clock-speed, the M68K was giving comparably
weak performance compared with many other architectures (and AFAIK part
of why Apple had jumped from M68K to PPC?).

OTOH, the instruction encoding does seem at least cleaner than x86...

I guess another mystery could have been if a 32-bit RISC design could
have been made more viable with an 8 or 16 bit memory bus?...

From what I can gather, processors from that era didn't really use L1
or L2 caches though. This wouldn't likely bode well.

It appears that MitchAlsup <MitchAlsup@aol.com> said:
>> CISC's have many optional instruction features, and that buggers up
>> in-order pipeline designs which like everything to be the same.
>> So a CISC could wind up having to insert multiple pipeline stages,
>> increasing the latency, just to support some rarely used features.
><
>Certainly PDP-11, VAX, 68K, N32K, and a few more had those features.
>Other CISCs did not: 360/370, Interdata, S.E.L, ...

The 360 architecture allows you to store into the next instruction and
it has to work. Back in the day people did that to patch field lengths
and I/O addresses. It also has an execute instruction that takes an
instruction at an arbitrary place in memory and sticks it into the
instruction stream, sort of a one instruction branch and return. There
was a clever hack that ORs the low byte of a register into the second
byte of the executed instruction, which usual way to handle variable
length operands since the field length is in the second byte of the
instruction so you can't just cache the instruction.

On modern systems code is usually stored in read-only pages and there
are new string move and compare instructions that take the length
directly from a register, but zSeries still hass EX and lets you store
into the next instruction if storage permisssions permit.

--
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

On Sunday, July 9, 2023 at 1:16:13 PM UTC-5, BGB wrote:
> On 7/9/2023 10:34 AM, Anton Ertl wrote:
> > Quadibloc <jsa...@ecn.ab.ca> writes:
> >> The Motorola 68000 divided the 16 registers it did provide into two
> >> groups; the general registers and the address registers. So it needed
> >> three-bit fields to specify a register in either group.
> >>
> >> The Motorola 68000 was a CISC processor; it didn't "need" more than
> >> eight registers in a register bank.
> >
> > Counterexamples: IBM S/360, VAX, AMD64, all of which have ~16
> > general-purpose registers.
> >
> > I think that the 16-bit memory interface of the 68000 meant that they
> > wanted to have many instructions that fit in 16 bits, and with more
> > than 8 registers this becomes difficult (see also the PDP-11). The
> > 8086 is an example that trying to fit useful instructions in 8 bits
> > leads to even more limitations.
> >
> > Another example is the RISC-V C extension (16-bit wide instructions),
> > where a number of these instructions can access only 8 of the 32
> > registers of the architecture.
> >
> FWIW:
> Both SuperH (and also BJX2) can use 16 GPRs for the 16-bit instruction
> encodings.
>
> However, in both ISA's, they are effectively Load/Store with typically
> only 2R encodings for the 16-bit ops.
>
> In my case, there are some 16-bit ops with access to R16..R31, but
> mostly limited to special cases:
> MOV, ADD
> MOV.{L/Q} (SP, Disp4), Rn
> ...
> Nothing in 16-bit land has access to R32..R63 though.
>
>
> Both RISC-V C and Thumb tried for 3R encodings within the 16-bit opcode
> space. But, arguably this doesn't seem terribly worthwhile as the "hit
> rate" for being limited to 8 registers is lower than that for being
> limited to, say: "Rn=Rn+Rm;" and similar.
>
> Comparably, both RV-C and Thumb had a lot of hair in terms of their
> 16-bit encodings as well.
>
>
>
> MSP430 managed 16-bit instructions, 16 registers, and CISC-like Reg/Mem
> operations, but paid for this by having an absurdly small opcode space
> (with a lot of instructions being encoded by playing trickery with the
> register fields and addressing modes).
> >> Providing 32 registers is something
> >> RISC processors do - for them, it's worth the opcode space, because
> >> opcode space is saved elsewhere
> >
> > No, it's because they have the opcode space. All those with 32
> > registers have 32-bit memory interfaces and therefore could afford
> > 32-bit instructions, so they could afford encoding registers in 5
> > bits. ARM1/2 also has a 32-bit memory interface and 32-bit
> > instructions, but only 16 GPRs (maybe due to area concerns, maybe
> > because the 801 only has 16 registers), and used the extra bits for
> > stuff like shifts or conditions.
> >
> In my case, I have some encodings (and an operating mode) which have
> 6-bit register fields, conditional execution, etc.
>
> But, compared with most RISC's (with a 32-bit instruction size), mine
> has comparably small immediate fields.
>
> Though, interestingly, XG2 Mode has typically the same sized immediate
> fields as SH-5 (which also had 6-bit register fields).
>
> Baseline mode only has 5-bit register fields for the most part, whereas
> XG2 gains 6-bit fields at the expense of making the 16-bit ops N/E.
>
>
>
> I don't see the smaller immediate fields as too big of a loss though:
> There is a reasonably good hit-rate with the current immediate fields;
> The ISA design does not overly penalize cases where an immediate can't
> fit in the immediate-field;
> There are also Jumbo prefixes.
>
> In contrast, in RISC-V, if one exceeds the 12-bit immediate field one is
> typically looking at a 3 instruction fallback case.
<
I think they (THEY) would argue mostly 1 becomes 2 instructions.
Almost all displacements greater than 12-bits become a 2 instruction
sequence; THEY would argue that this is where most big immediates
come from.
<
>
> But, OTOH, my ISA has both:
> ADD Rm, Imm9u, Rn
> And:
> ADD Imm16s, Rn
>
> Whereas RISC-V only has:
> ADD Rd, Rs, Imm12s
<
Whereas My 66000 has:
ADD Rd,Rs,#Imm16
ADD Rd,+Rs1,+Rs2
ADD Rd,+Rs1,-Rs2
ADD Rd,-Rs1,+Rs2
ADD Rd,-Rs1,-Rs2
ADD Rd,+Rs,#Imm32
ADD Rd,-Rs,#Imm32
ADD Rd,+Rs,#Imm64
ADD Rd,-Rs,#Imm64
ADD Rd,Rs,+#imm5
ADD Rd,Rs,-#Imm5
ADD Rd,+#imm5,Rs
ADD Rd,-#imm5,Rs
ADD Rd,#Imm32,+Rs
ADD Rd,#Imm32,-Rs
ADD Rd,#Imm64,+Rs
ADD Rd,#Imm64,-Rs
>
> Partly because some tasks (like adjusting the stack pointer) don't map
> over well to a 9-bit immediate field.
<
I have 16-bits........
>
> Also the first version of my ISA design only had 5-bit immediate fields,
> but these were quickly revealed to be... insufficient...
>
They tidy up::
<
SLL Rd,#1,Rs
>
> If I were to try to shoe-horn my entire "wish-list" into a 32-bit
> instruction word (and have an OK amount of opcode space), would mostly
> end up needing to reduce most immediate values to 6 bits (with ~ 12 bits
> for 2RI encodings), which is "less good".
>
I did the opposite and still achieved a small OpCode set and a large
expression set simultaneously.
>
> So, it seemed "less bad" to not be able to encode some features in some
> combinations, than to be able to encode them but then have nearly
> everything being limited to 6-bit immediate fields.
<
I looked at it from a different perspective.
<
The OpCode describes the arithmetic manipulation
<
Something else describes how operands are routed to the calculation unit.
It is here that all the constants were added. And all OpCodes of a particular
group get all the same routing that every other OpCode in the same group
gets.

On Sunday, July 9, 2023 at 2:55:22 PM UTC-5, John Levine wrote:
> According to Thomas Koenig <tko...@netcologne.de>:
> >One should also not forget bus width, which also costs money.
> >The ARM2 was able to beat the 68000 on speed by a large factor
> >with a lower transistor count, but it also had a 32-bit data bus
> >(which, considering periphery, might have been too expensive when
> >the 68000 was designed).
<
> The original 68000 came in 16 and 8 bit bus versions, just like the 8086 and 8088.
<
The 68000 with 8-bit bus was a year later than 8086 with 8-bit bus.
{{And required more glue gates than the Intel bus}}
>
> Legend says that if Moto had been able to ship the 68008 in quantity,
> IBM would have used it in the IBM PC rather than the 8088. If only.
<
Its lateness was what drove the decision.
>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

According to BGB <cr88192@gmail.com>:
>> The original 68000 came in 16 and 8 bit bus versions, just like the 8086 and 8088.
>>
>> Legend says that if Moto had been able to ship the 68008 in quantity,
>> IBM would have used it in the IBM PC rather than the 8088. If only.
>
>I guess a question is if it had been used in the PC instead of x86, if
>Motorola could have then made it performance competitive with what later
>x86 systems became?...

Hard to say. At that point Intel just executed better than Moto.

>OTOH, the instruction encoding does seem at least cleaner than x86...

No S* Sherlock. And the huge win of flat rather than segmented addressing.

>I guess another mystery could have been if a 32-bit RISC design could
>have been made more viable with an 8 or 16 bit memory bus?...
>
> From what I can gather, processors from that era didn't really use L1
>or L2 caches though. This wouldn't likely bode well.

Cache? What's a cache? The PC was shipped in 1981 and the first
general purpose CPU chips I know with a cache were the 68030 in 1987
and i486 in 1989.
--
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

On Sunday, July 9, 2023 at 3:20:57 PM UTC-5, BGB wrote:
> On 7/9/2023 2:55 PM, John Levine wrote:
> > According to Thomas Koenig <tko...@netcologne.de>:
> >> One should also not forget bus width, which also costs money.
> >> The ARM2 was able to beat the 68000 on speed by a large factor
> >> with a lower transistor count, but it also had a 32-bit data bus
> >> (which, considering periphery, might have been too expensive when
> >> the 68000 was designed).
> >
> > The original 68000 came in 16 and 8 bit bus versions, just like the 8086 and 8088.
> >
> > Legend says that if Moto had been able to ship the 68008 in quantity,
> > IBM would have used it in the IBM PC rather than the 8088. If only.
> >
> I guess a question is if it had been used in the PC instead of x86, if
> Motorola could have then made it performance competitive with what later
> x86 systems became?...
<
If 68K was used instead of 8086, PC would have been more like LISA.
{{which evolved into MacIntosh.}
>
> Like, seemingly, relative to clock-speed, the M68K was giving comparably
> weak performance compared with many other architectures (and AFAIK part
> of why Apple had jumped from M68K to PPC?).
<
68K was out performing 8086 in that era
After 486 it was all done.
>
> OTOH, the instruction encoding does seem at least cleaner than x86...
>
Well, Mrs. Lincoln, how did you like the play ??
>
>
> I guess another mystery could have been if a 32-bit RISC design could
> have been made more viable with an 8 or 16 bit memory bus?...
>
> From what I can gather, processors from that era didn't really use L1
> or L2 caches though. This wouldn't likely bode well.
<
There was an entire paradigm shift at the CISC->RISC boundary.

On 7/9/2023 3:38 PM, MitchAlsup wrote:
> On Sunday, July 9, 2023 at 1:16:13 PM UTC-5, BGB wrote:
>> On 7/9/2023 10:34 AM, Anton Ertl wrote:
>>> Quadibloc <jsa...@ecn.ab.ca> writes:
>>>> The Motorola 68000 divided the 16 registers it did provide into two
>>>> groups; the general registers and the address registers. So it needed
>>>> three-bit fields to specify a register in either group.
>>>>
>>>> The Motorola 68000 was a CISC processor; it didn't "need" more than
>>>> eight registers in a register bank.
>>>
>>> Counterexamples: IBM S/360, VAX, AMD64, all of which have ~16
>>> general-purpose registers.
>>>
>>> I think that the 16-bit memory interface of the 68000 meant that they
>>> wanted to have many instructions that fit in 16 bits, and with more
>>> than 8 registers this becomes difficult (see also the PDP-11). The
>>> 8086 is an example that trying to fit useful instructions in 8 bits
>>> leads to even more limitations.
>>>
>>> Another example is the RISC-V C extension (16-bit wide instructions),
>>> where a number of these instructions can access only 8 of the 32
>>> registers of the architecture.
>>>
>> FWIW:
>> Both SuperH (and also BJX2) can use 16 GPRs for the 16-bit instruction
>> encodings.
>>
>> However, in both ISA's, they are effectively Load/Store with typically
>> only 2R encodings for the 16-bit ops.
>>
>> In my case, there are some 16-bit ops with access to R16..R31, but
>> mostly limited to special cases:
>> MOV, ADD
>> MOV.{L/Q} (SP, Disp4), Rn
>> ...
>> Nothing in 16-bit land has access to R32..R63 though.
>>
>>
>> Both RISC-V C and Thumb tried for 3R encodings within the 16-bit opcode
>> space. But, arguably this doesn't seem terribly worthwhile as the "hit
>> rate" for being limited to 8 registers is lower than that for being
>> limited to, say: "Rn=Rn+Rm;" and similar.
>>
>> Comparably, both RV-C and Thumb had a lot of hair in terms of their
>> 16-bit encodings as well.
>>
>>
>>
>> MSP430 managed 16-bit instructions, 16 registers, and CISC-like Reg/Mem
>> operations, but paid for this by having an absurdly small opcode space
>> (with a lot of instructions being encoded by playing trickery with the
>> register fields and addressing modes).
>>>> Providing 32 registers is something
>>>> RISC processors do - for them, it's worth the opcode space, because
>>>> opcode space is saved elsewhere
>>>
>>> No, it's because they have the opcode space. All those with 32
>>> registers have 32-bit memory interfaces and therefore could afford
>>> 32-bit instructions, so they could afford encoding registers in 5
>>> bits. ARM1/2 also has a 32-bit memory interface and 32-bit
>>> instructions, but only 16 GPRs (maybe due to area concerns, maybe
>>> because the 801 only has 16 registers), and used the extra bits for
>>> stuff like shifts or conditions.
>>>
>> In my case, I have some encodings (and an operating mode) which have
>> 6-bit register fields, conditional execution, etc.
>>
>> But, compared with most RISC's (with a 32-bit instruction size), mine
>> has comparably small immediate fields.
>>
>> Though, interestingly, XG2 Mode has typically the same sized immediate
>> fields as SH-5 (which also had 6-bit register fields).
>>
>> Baseline mode only has 5-bit register fields for the most part, whereas
>> XG2 gains 6-bit fields at the expense of making the 16-bit ops N/E.
>>
>>
>>
>> I don't see the smaller immediate fields as too big of a loss though:
>> There is a reasonably good hit-rate with the current immediate fields;
>> The ISA design does not overly penalize cases where an immediate can't
>> fit in the immediate-field;
>> There are also Jumbo prefixes.
>>
>> In contrast, in RISC-V, if one exceeds the 12-bit immediate field one is
>> typically looking at a 3 instruction fallback case.
> <
> I think they (THEY) would argue mostly 1 becomes 2 instructions.
> Almost all displacements greater than 12-bits become a 2 instruction
> sequence; THEY would argue that this is where most big immediates
> come from.
> <

Well, say, you have:
XORI X10, X11, 511 //OK, fine.
Vs:
XORI X10, X11, 65521 //Now what?

You get, maybe:
LUI X5, 16
ADDI X5, X5, -15
XOR X10, X11, X5

This is kinda weak...

Meanwhile, in BJX2 (without jumbo), you can fake, say:
ADD R4, 16777213, R7
As a 2-op sequence:
LDIZ 16777213, R0
ADD R4, R0, R7

Which is part of why I burnt such a big chunk of encoding space on a
"Load Imm24 into R0" instruction; 2 actually:
LDIZ Imm24u, R0 //Zero-Extend
LDIN Imm24n, R0 //One-Extend
Which can be seen as a virtual:
MOV Imm25s, R0

But, it sort of paid off as this instruction left encoding space that
could also be used for things like Jumbo Prefixes and PrWEX encodings,
which in some of my other design attempts I had attempted
(unsuccessfully) to conjoin them with the Branch instructions (where
trying to WEX a branch instruction is also invalid in my designs).

There are also a relatively limited number of combinations where A+B~=32
and A+A+C=64, ...

But, 24+9=33 works well as 33 bits can represent both the entire signed
32-bit range and the entire 32-bit unsigned range, thus covering all
32-bit constants. Likewise, 24+24+16=64, so this is also good.

But, I had only ended up going with 20 bits for branches, as +/- 1MB has
thus far been "mostly" sufficient.

For a branch within the same EXE/DLL, most likely sufficient. For a
branch outside the current DLL; one isn't going to be using a normal
PC-relative branch in the first place.

If this fails, there was a fallback case:
MOV Disp25s, R0
JSR R0 //Call to (PC+R0)

Or, failing this:
MOV DispHi16, R0
LDSH DispLo16, R0
JSR R0

But, have since added 64-bit jumbo-based encodings for:
BSR Disp33s
And:
BSR Abs48

But, these don't exist on the smaller cores, but then again, a smaller
core is less likely to exceed the 20 and 25 bit cases.

I explicitly chose not to have a relative branch longer than 33 bits (in
these cases, one can either do an absolute branch, or fake it manually
using ALU ops).

Granted, one could argue that RISC-V has a "slight" advantage for
long-distance branches as they can (indirectly) perform a branch like:
AUIPC X5, DispHi20
JALR X1, X5, DispLo12

Without needing a jumbo prefix or other similar mechanism.

Exceeding the Load/Store displacements is still a bit of an issue though
with RISC-V; as there is not really a "good" fallback that I can think
of at the moment.

>>
>> But, OTOH, my ISA has both:
>> ADD Rm, Imm9u, Rn
>> And:
>> ADD Imm16s, Rn
>>
>> Whereas RISC-V only has:
>> ADD Rd, Rs, Imm12s
> <
> Whereas My 66000 has:
> ADD Rd,Rs,#Imm16
> ADD Rd,+Rs1,+Rs2
> ADD Rd,+Rs1,-Rs2
> ADD Rd,-Rs1,+Rs2
> ADD Rd,-Rs1,-Rs2
> ADD Rd,+Rs,#Imm32
> ADD Rd,-Rs,#Imm32
> ADD Rd,+Rs,#Imm64
> ADD Rd,-Rs,#Imm64
> ADD Rd,Rs,+#imm5
> ADD Rd,Rs,-#Imm5
> ADD Rd,+#imm5,Rs
> ADD Rd,-#imm5,Rs
> ADD Rd,#Imm32,+Rs
> ADD Rd,#Imm32,-Rs
> ADD Rd,#Imm64,+Rs
> ADD Rd,#Imm64,-Rs
>>
>> Partly because some tasks (like adjusting the stack pointer) don't map
>> over well to a 9-bit immediate field.
> <
> I have 16-bits........

I have:
ADD Imm16s, Rn

But, yeah, relatively few ops with 16-bit immediate values in my case.

Even then, they have mostly ended up being overshadowed by "MOV
Imm10{u/n}, Rn" and "ADD Imm10{u/n}, Rn" ops, which ended up with the
advantage of being in a part of the encoding space (the F2 block) where
they are "more versatile" (can be used in PrWEX and XGPR encodings).

When used as part of an Op96 encoding, the F8 block transforms partly;
effectively the entire block mostly goes over to being MOV and ADD.
MOV Imm64, Rn //R0..R63
ADD Imm64, Rn //R0..R63

Whereas otherwise:
MOV Imm16, Rn //R0..R31
ADD Imm16, Rn //R0..R31

Things like:
LDSH Imm64, Rn
Being N/E as its encoding space effectively got eaten by ADD.

Whereas, for things like:
ADD Rm, Imm64, Rn
There is currently no way to encode this directly, but it doesn't come up.

On Sunday, July 9, 2023 at 5:57:47 PM UTC-5, BGB wrote:
> On 7/9/2023 3:38 PM, MitchAlsup wrote:
> > On Sunday, July 9, 2023 at 1:16:13 PM UTC-5, BGB wrote:
> >> On 7/9/2023 10:34 AM, Anton Ertl wrote:
> >>> Quadibloc <jsa...@ecn.ab.ca> writes:
> >>>> The Motorola 68000 divided the 16 registers it did provide into two
> >>>> groups; the general registers and the address registers. So it needed
> >>>> three-bit fields to specify a register in either group.
> >>>>
> >>>> The Motorola 68000 was a CISC processor; it didn't "need" more than
> >>>> eight registers in a register bank.
> >>>
> >>> Counterexamples: IBM S/360, VAX, AMD64, all of which have ~16
> >>> general-purpose registers.
> >>>
> >>> I think that the 16-bit memory interface of the 68000 meant that they
> >>> wanted to have many instructions that fit in 16 bits, and with more
> >>> than 8 registers this becomes difficult (see also the PDP-11). The
> >>> 8086 is an example that trying to fit useful instructions in 8 bits
> >>> leads to even more limitations.
> >>>
> >>> Another example is the RISC-V C extension (16-bit wide instructions),
> >>> where a number of these instructions can access only 8 of the 32
> >>> registers of the architecture.
> >>>
> >> FWIW:
> >> Both SuperH (and also BJX2) can use 16 GPRs for the 16-bit instruction
> >> encodings.
> >>
> >> However, in both ISA's, they are effectively Load/Store with typically
> >> only 2R encodings for the 16-bit ops.
> >>
> >> In my case, there are some 16-bit ops with access to R16..R31, but
> >> mostly limited to special cases:
> >> MOV, ADD
> >> MOV.{L/Q} (SP, Disp4), Rn
> >> ...
> >> Nothing in 16-bit land has access to R32..R63 though.
> >>
> >>
> >> Both RISC-V C and Thumb tried for 3R encodings within the 16-bit opcode
> >> space. But, arguably this doesn't seem terribly worthwhile as the "hit
> >> rate" for being limited to 8 registers is lower than that for being
> >> limited to, say: "Rn=Rn+Rm;" and similar.
> >>
> >> Comparably, both RV-C and Thumb had a lot of hair in terms of their
> >> 16-bit encodings as well.
> >>
> >>
> >>
> >> MSP430 managed 16-bit instructions, 16 registers, and CISC-like Reg/Mem
> >> operations, but paid for this by having an absurdly small opcode space
> >> (with a lot of instructions being encoded by playing trickery with the
> >> register fields and addressing modes).
> >>>> Providing 32 registers is something
> >>>> RISC processors do - for them, it's worth the opcode space, because
> >>>> opcode space is saved elsewhere
> >>>
> >>> No, it's because they have the opcode space. All those with 32
> >>> registers have 32-bit memory interfaces and therefore could afford
> >>> 32-bit instructions, so they could afford encoding registers in 5
> >>> bits. ARM1/2 also has a 32-bit memory interface and 32-bit
> >>> instructions, but only 16 GPRs (maybe due to area concerns, maybe
> >>> because the 801 only has 16 registers), and used the extra bits for
> >>> stuff like shifts or conditions.
> >>>
> >> In my case, I have some encodings (and an operating mode) which have
> >> 6-bit register fields, conditional execution, etc.
> >>
> >> But, compared with most RISC's (with a 32-bit instruction size), mine
> >> has comparably small immediate fields.
> >>
> >> Though, interestingly, XG2 Mode has typically the same sized immediate
> >> fields as SH-5 (which also had 6-bit register fields).
> >>
> >> Baseline mode only has 5-bit register fields for the most part, whereas
> >> XG2 gains 6-bit fields at the expense of making the 16-bit ops N/E.
> >>
> >>
> >>
> >> I don't see the smaller immediate fields as too big of a loss though:
> >> There is a reasonably good hit-rate with the current immediate fields;
> >> The ISA design does not overly penalize cases where an immediate can't
> >> fit in the immediate-field;
> >> There are also Jumbo prefixes.
> >>
> >> In contrast, in RISC-V, if one exceeds the 12-bit immediate field one is
> >> typically looking at a 3 instruction fallback case.
> > <
> > I think they (THEY) would argue mostly 1 becomes 2 instructions.
> > Almost all displacements greater than 12-bits become a 2 instruction
> > sequence; THEY would argue that this is where most big immediates
> > come from.
> > <
> Well, say, you have:
> XORI X10, X11, 511 //OK, fine.
> Vs:
> XORI X10, X11, 65521 //Now what?
>
> You get, maybe:
> LUI X5, 16
> ADDI X5, X5, -15
> XOR X10, X11, X5
>
> This is kinda weak...
>
I agree with you that it is weak.
>
> Meanwhile, in BJX2 (without jumbo), you can fake, say:
> ADD R4, 16777213, R7
> As a 2-op sequence:
> LDIZ 16777213, R0
> ADD R4, R0, R7
<
Even::
<
ADD Rd,Rs,#0x123456789abcdef
<
Is 1 (One, single) instruction. It occupies 3 words, but it is 1 instruction.
<
So is::
<
STD #0x123456789abcdef,[Rd,Rs<<3,#0x123456789abcdef]
<
1 instruction, this time it occupies 5 words, but it remains 1 instruction.
RISC-V code for this is atrocious.
>
> Which is part of why I burnt such a big chunk of encoding space on a
> "Load Imm24 into R0" instruction; 2 actually:
> LDIZ Imm24u, R0 //Zero-Extend
> LDIN Imm24n, R0 //One-Extend
> Which can be seen as a virtual:
> MOV Imm25s, R0
>
You are still wasting instructions pasting bits together that can be "had"
and a constant. This consumes pipeline cycles, registers, forwarding
energy,... There is no cheaper way to deliver an operand into calculation
than as a constant.
>
> But, it sort of paid off as this instruction left encoding space that
> could also be used for things like Jumbo Prefixes and PrWEX encodings,
> which in some of my other design attempts I had attempted
> (unsuccessfully) to conjoin them with the Branch instructions (where
> trying to WEX a branch instruction is also invalid in my designs).
>
Yes, go ahead and pat yourself on the back for something I consider
to be poor.
>
> There are also a relatively limited number of combinations where A+B~=32
> and A+A+C=64, ...
>
> But, 24+9=33 works well as 33 bits can represent both the entire signed
> 32-bit range and the entire 32-bit unsigned range, thus covering all
> 32-bit constants. Likewise, 24+24+16=64, so this is also good.
>
>
> But, I had only ended up going with 20 bits for branches, as +/- 1MB has
> thus far been "mostly" sufficient.
<
Not surprising.
>
> For a branch within the same EXE/DLL, most likely sufficient. For a
> branch outside the current DLL; one isn't going to be using a normal
> PC-relative branch in the first place.
>
I call from one DLL to another in a single instruction (which loads IP from
GOT[function#].) The linker can change this back to LDA ip,[GOT[function#]]
when an extern function() becomes a local function (and avoid changing
code size--and thus label values).
>
>
>
> Granted, one could argue that RISC-V has a "slight" advantage for
> long-distance branches as they can (indirectly) perform a branch like:
> AUIPC X5, DispHi20
> JALR X1, X5, DispLo12
<
CALA [DISP32] // 32-bit address
CALA [DISP64] // 64-bit address
<
CALX [GOT32[function#]] // 32-bit GOT 64-bit address
CALX [GOT64[function#]] // 64-bit GOT 64-bit address
<
And none of these require wasting a register.
>
> Without needing a jumbo prefix or other similar mechanism.
>
>
> Exceeding the Load/Store displacements is still a bit of an issue though
> with RISC-V; as there is not really a "good" fallback that I can think
> of at the moment.
> >>
> >> But, OTOH, my ISA has both:
> >> ADD Rm, Imm9u, Rn
> >> And:
> >> ADD Imm16s, Rn
> >>
> >> Whereas RISC-V only has:
> >> ADD Rd, Rs, Imm12s
> > <
> > Whereas My 66000 has:
> > ADD Rd,Rs,#Imm16
> > ADD Rd,+Rs1,+Rs2
> > ADD Rd,+Rs1,-Rs2
> > ADD Rd,-Rs1,+Rs2
> > ADD Rd,-Rs1,-Rs2
> > ADD Rd,+Rs,#Imm32
> > ADD Rd,-Rs,#Imm32
> > ADD Rd,+Rs,#Imm64
> > ADD Rd,-Rs,#Imm64
> > ADD Rd,Rs,+#imm5
> > ADD Rd,Rs,-#Imm5
> > ADD Rd,+#imm5,Rs
> > ADD Rd,-#imm5,Rs
> > ADD Rd,#Imm32,+Rs
> > ADD Rd,#Imm32,-Rs
> > ADD Rd,#Imm64,+Rs
> > ADD Rd,#Imm64,-Rs
> >>
> >> Partly because some tasks (like adjusting the stack pointer) don't map
> >> over well to a 9-bit immediate field.
> > <
> > I have 16-bits........
> I have:
> ADD Imm16s, Rn
<
You also write operands and results in the wrong direction....................

On 7/9/2023 6:44 PM, MitchAlsup wrote:
> On Sunday, July 9, 2023 at 5:57:47 PM UTC-5, BGB wrote:
>> On 7/9/2023 3:38 PM, MitchAlsup wrote:
>>> On Sunday, July 9, 2023 at 1:16:13 PM UTC-5, BGB wrote:
>>>> On 7/9/2023 10:34 AM, Anton Ertl wrote:
>>>>> Quadibloc <jsa...@ecn.ab.ca> writes:
>>>>>> The Motorola 68000 divided the 16 registers it did provide into two
>>>>>> groups; the general registers and the address registers. So it needed
>>>>>> three-bit fields to specify a register in either group.
>>>>>>
>>>>>> The Motorola 68000 was a CISC processor; it didn't "need" more than
>>>>>> eight registers in a register bank.
>>>>>
>>>>> Counterexamples: IBM S/360, VAX, AMD64, all of which have ~16
>>>>> general-purpose registers.
>>>>>
>>>>> I think that the 16-bit memory interface of the 68000 meant that they
>>>>> wanted to have many instructions that fit in 16 bits, and with more
>>>>> than 8 registers this becomes difficult (see also the PDP-11). The
>>>>> 8086 is an example that trying to fit useful instructions in 8 bits
>>>>> leads to even more limitations.
>>>>>
>>>>> Another example is the RISC-V C extension (16-bit wide instructions),
>>>>> where a number of these instructions can access only 8 of the 32
>>>>> registers of the architecture.
>>>>>
>>>> FWIW:
>>>> Both SuperH (and also BJX2) can use 16 GPRs for the 16-bit instruction
>>>> encodings.
>>>>
>>>> However, in both ISA's, they are effectively Load/Store with typically
>>>> only 2R encodings for the 16-bit ops.
>>>>
>>>> In my case, there are some 16-bit ops with access to R16..R31, but
>>>> mostly limited to special cases:
>>>> MOV, ADD
>>>> MOV.{L/Q} (SP, Disp4), Rn
>>>> ...
>>>> Nothing in 16-bit land has access to R32..R63 though.
>>>>
>>>>
>>>> Both RISC-V C and Thumb tried for 3R encodings within the 16-bit opcode
>>>> space. But, arguably this doesn't seem terribly worthwhile as the "hit
>>>> rate" for being limited to 8 registers is lower than that for being
>>>> limited to, say: "Rn=Rn+Rm;" and similar.
>>>>
>>>> Comparably, both RV-C and Thumb had a lot of hair in terms of their
>>>> 16-bit encodings as well.
>>>>
>>>>
>>>>
>>>> MSP430 managed 16-bit instructions, 16 registers, and CISC-like Reg/Mem
>>>> operations, but paid for this by having an absurdly small opcode space
>>>> (with a lot of instructions being encoded by playing trickery with the
>>>> register fields and addressing modes).
>>>>>> Providing 32 registers is something
>>>>>> RISC processors do - for them, it's worth the opcode space, because
>>>>>> opcode space is saved elsewhere
>>>>>
>>>>> No, it's because they have the opcode space. All those with 32
>>>>> registers have 32-bit memory interfaces and therefore could afford
>>>>> 32-bit instructions, so they could afford encoding registers in 5
>>>>> bits. ARM1/2 also has a 32-bit memory interface and 32-bit
>>>>> instructions, but only 16 GPRs (maybe due to area concerns, maybe
>>>>> because the 801 only has 16 registers), and used the extra bits for
>>>>> stuff like shifts or conditions.
>>>>>
>>>> In my case, I have some encodings (and an operating mode) which have
>>>> 6-bit register fields, conditional execution, etc.
>>>>
>>>> But, compared with most RISC's (with a 32-bit instruction size), mine
>>>> has comparably small immediate fields.
>>>>
>>>> Though, interestingly, XG2 Mode has typically the same sized immediate
>>>> fields as SH-5 (which also had 6-bit register fields).
>>>>
>>>> Baseline mode only has 5-bit register fields for the most part, whereas
>>>> XG2 gains 6-bit fields at the expense of making the 16-bit ops N/E.
>>>>
>>>>
>>>>
>>>> I don't see the smaller immediate fields as too big of a loss though:
>>>> There is a reasonably good hit-rate with the current immediate fields;
>>>> The ISA design does not overly penalize cases where an immediate can't
>>>> fit in the immediate-field;
>>>> There are also Jumbo prefixes.
>>>>
>>>> In contrast, in RISC-V, if one exceeds the 12-bit immediate field one is
>>>> typically looking at a 3 instruction fallback case.
>>> <
>>> I think they (THEY) would argue mostly 1 becomes 2 instructions.
>>> Almost all displacements greater than 12-bits become a 2 instruction
>>> sequence; THEY would argue that this is where most big immediates
>>> come from.
>>> <
>> Well, say, you have:
>> XORI X10, X11, 511 //OK, fine.
>> Vs:
>> XORI X10, X11, 65521 //Now what?
>>
>> You get, maybe:
>> LUI X5, 16
>> ADDI X5, X5, -15
>> XOR X10, X11, X5
>>
>> This is kinda weak...
>>
> I agree with you that it is weak.
>>
>> Meanwhile, in BJX2 (without jumbo), you can fake, say:
>> ADD R4, 16777213, R7
>> As a 2-op sequence:
>> LDIZ 16777213, R0
>> ADD R4, R0, R7
> <
> Even::
> <
> ADD Rd,Rs,#0x123456789abcdef
> <
> Is 1 (One, single) instruction. It occupies 3 words, but it is 1 instruction.
> <
> So is::
> <
> STD #0x123456789abcdef,[Rd,Rs<<3,#0x123456789abcdef]
> <
> 1 instruction, this time it occupies 5 words, but it remains 1 instruction.
> RISC-V code for this is atrocious.

Yeah...
BJX2 can't do this either.

With jumbo encodings, one can at least do:
ADD R4, 0x12345678, R7
As a single 64-bit instruction.

Could in theory do:
ADD R4, 0x123456789abcde, R7

As a 96-bit encoding, if it were common enough to justify the LUT cost
of enabling it. Granted, these exist implicitly if one enables the SIMD
vector immediate values, since the SIMD immediate values need the same
mechanism.

Still no 64-bit displacements, mostly for timing reasons.

Despite there being a 96-bit mode, only the low 48 bits are subject to
address calculation, and only with a 33 bit displacement.

The compiler can mostly gloss over this though, seeing if a person uses
'long' as an array index.

Though, annoyingly, this does mean that it needs to end up falling back
to a slower case if one uses 'size_t' or 'ssize_t' rather than 'int' for
their array index.

>>
>> Which is part of why I burnt such a big chunk of encoding space on a
>> "Load Imm24 into R0" instruction; 2 actually:
>> LDIZ Imm24u, R0 //Zero-Extend
>> LDIN Imm24n, R0 //One-Extend
>> Which can be seen as a virtual:
>> MOV Imm25s, R0
>>
> You are still wasting instructions pasting bits together that can be "had"
> and a constant. This consumes pipeline cycles, registers, forwarding
> energy,... There is no cheaper way to deliver an operand into calculation
> than as a constant.

As noted, this is excluding "jumbo", which eliminates most of the
multi-op bit-pasting, but isn't regarded as part of the core ISA in the
smaller profiles (and didn't exist in early forms of the ISA design).

Then again, one option could be to promote the jumbo prefixes to the
core ISA, in a similar way to what happened with predicated instructions.

Early on, I realized that the underlying logic for predicated
instructions was still needed for conditional branches, so there wasn't
any good reason *not* to promote it to core.

>>
>> But, it sort of paid off as this instruction left encoding space that
>> could also be used for things like Jumbo Prefixes and PrWEX encodings,
>> which in some of my other design attempts I had attempted
>> (unsuccessfully) to conjoin them with the Branch instructions (where
>> trying to WEX a branch instruction is also invalid in my designs).
>>
> Yes, go ahead and pat yourself on the back for something I consider
> to be poor.

Well:
MOV Imm25s, R0
Is sort of a sledgehammer solution, but like, it is workable in the
majority of cases...