On Saturday, June 5, 2021 at 7:16:34 AM UTC-6, Stephen Fuld wrote:

> In general, ISTM that having different sets of registers with different
> capabilities is not a good idea. You invariably want more of one type
> than there are and don't use all of another type. It also complicates
> the compiler.

That is certainly true. However, I don't think that what I have done is
_too_ bad in *that* respect, although it could be bad for other reasons.

There are 32 general registers. You will want to use maybe two or three
of them as base registers in normal code, so as not to take away too many
registers from normal use.

All that changes here is that, depending on the memory model you use,
those base registers may be drawn from a different group of 8 out of
the 32 registers.

John Savard

On Friday, June 4, 2021 at 1:20:59 PM UTC-4, MitchAlsup wrote:
> On Friday, June 4, 2021 at 12:01:09 PM UTC-5, Quadibloc wrote:
>> On Friday, May 14, 2021 at 1:21:26 PM UTC-6, Thomas Koenig wrote:
>>
>>> It killed off too many RISC architectures. There would eventually
>>> have been a consolidation, but x86_64 was not the right architecture
>>> to consolidate to...
>> So true, but there was little choice then. Now we have a second chance,
>> ARM.
> <
> Not much of a choice:
> a) mud pie
> b) mud pudding

Are you aware that AArch64 (64-bit ARM ISA) is a relatively clean RISC and that ARM is no longer developing high-performance A-profile cores that support the 32-bit ISAs? (I think an abstraction layer would be better than a traditional ISA, but the business case for such is weaker. My 66000 is better than AArch64, but AArch64 does not seem like mud pudding.)

On Sat, 5 Jun 2021 06:16:30 -0700, Stephen Fuld
<sfuld@alumni.cmu.edu.invalid> wrote:

>On 6/5/2021 6:07 AM, Quadibloc wrote:
>> On Saturday, June 5, 2021 at 4:01:28 AM UTC-6, gareth evans wrote:
>>> On 04/06/2021 23:39, Quadibloc wrote:
>>>> ... since such a subroutine
>>>> jump would specify a particular register as the location of the return
>>>> address, ...
>>
>>> Shades of the nightmare that is / was the 1802 microprocessor where
>>> you changed the register that was the current program counter,
>>> a contrivance that suggests to me that that the designer of that
>>> ISA had very limited programming experience, maybe simple programs
>>> with no nested subroutines!
>>
>> On the ARM, a _fixed_ register is the program counter.
>>
>> On my architecture, the program counter is the program counter, and not
>> one of the general registers.
>>
>> But there is no stack.
>>
>> Subroutine calls save the return address in one of the registers according
>> to whatever calling convention the user may choose. I imagine that a common
>> choice will be to place the return address in a register that the called program
>> uses as a base register, so that a return can be made by a conditional jump
>> instruction with that register as the base, a displacement of zero, and a condition
>> of always.
>>
>> This is how it was done on the IBM System/360.
>>
>> My architecture, however, _differs_ from the IBM System/360 in the following
>> respect: there are families of addressing modes which use different registers
>> as base registers.
>
>In general, ISTM that having different sets of registers with different
>capabilities is not a good idea. You invariably want more of one type
>than there are and don't use all of another type. It also complicates
>the compiler.

And when the architecture (or convention) doesn't define something
important - like which register to use for a stack - you can end up
with competing and incompatible ABIs.

Recall the joys of trying to mix code from various 68K Macintosh
toolchains that differed in using A5 or A6 for the stack.

George

> Are you aware that AArch64 (64-bit ARM ISA) is a relatively clean RISC and
> that ARM is no longer developing high-performance A-profile cores that
> support the 32-bit ISAs?

Actually, it seems they also dropped support for the 32bit ISA in the
A5x line of CPUs (at least in the Cortex-A510).

Stefan

On Saturday, June 5, 2021 at 3:46:05 PM UTC-5, John Levine wrote:
> According to MitchAlsup <Mitch...@aol.com>:
> >On Saturday, June 5, 2021 at 10:19:31 AM UTC-5, John Levine wrote:
> >> According to Quadibloc <jsa...@ecn.ab.ca>:
> >> >On the ARM, a _fixed_ register is the program counter.
> >> That's what the PDP-11 did. I don't know if it was the first architecture to put the PC
> >> in a register but it was certainly the most famous.
> >>
> >> It made relative addressing the same as indexed addressing, using the PC as the index register.
> >> It had a (R)+ and @(R)+ modes, use the register as the address and then inrement it by the address and
> >> then in the second case, use that as the indirect address.
> >> Hence (PC)+ was an immediate operand and @(PC)+ was absolute addressing.
> ><
> >It was a cute trick, but made pipelineing difficult.
> Was there ever a PDP-11 that was pipelined? This was quite a while ago.
>
> Also, the address modes were all fixed places in the first word of the
> instruction so I would think it'd be simple enough to recognize those
> two and take the words out of the instruction stream. It has to do
> roughly the same thing for the index words in indexed address modes.
<
Not nearly as hard to pipeline as VAX, but you could have a mem=mem op mem
instruction (2 mem addresses)m along with 3 register updates (not in the same
instruction, though).
<
So to achieve 1 I/C instruction rates, you had to be setup to perform 2 memory
reads and 1 memory write per cycle and up to 2 register results per cycle.
<
Basically, PDP-11, VAX, and Intel 432 taught us what NOT TO DO ! More so
VAX and 432 than PDP-11.
<
The converse is that S/360 is "Not bad at all" in a pipeline sense.
<
PDP-11 taught us that memory mapped I/O was the thing to do and in a sense
was the father of PCI.....
<
> --
> 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

On Saturday, June 5, 2021 at 4:01:23 PM UTC-5, Quadibloc wrote:
> On Saturday, June 5, 2021 at 7:16:34 AM UTC-6, Stephen Fuld wrote:
>
> > In general, ISTM that having different sets of registers with different
> > capabilities is not a good idea. You invariably want more of one type
> > than there are and don't use all of another type. It also complicates
> > the compiler.
> That is certainly true. However, I don't think that what I have done is
> _too_ bad in *that* respect, although it could be bad for other reasons.
>
> There are 32 general registers. You will want to use maybe two or three
> of them as base registers in normal code, so as not to take away too many
> registers from normal use.
<
/*
*******************************************************************
* Kernel 13 -- 2-D PIC (Particle In Cell)
*******************************************************************
* DO 13 L= 1,Loop
* DO 13 ip= 1,n
* i1= P(1,ip)
* j1= P(2,ip)
* i1= 1 + MOD2N(i1,64)
* j1= 1 + MOD2N(j1,64)
* P(3,ip)= P(3,ip) + B(i1,j1)
* P(4,ip)= P(4,ip) + C(i1,j1)
* P(1,ip)= P(1,ip) + P(3,ip)
* P(2,ip)= P(2,ip) + P(4,ip)
* i2= P(1,ip)
* j2= P(2,ip)
* i2= MOD2N(i2,64)
* j2= MOD2N(j2,64)
* P(1,ip)= P(1,ip) + Y(i2+32)
* P(2,ip)= P(2,ip) + Z(j2+32)
* i2= i2 + E(i2+32)
* j2= j2 + F(j2+32)
* H(i2,j2)= H(i2,j2) + 1.0
* 13 CONTINUE
*/
>
> All that changes here is that, depending on the memory model you use,
> those base registers may be drawn from a different group of 8 out of
> the 32 registers.
>
> John Savard

On Saturday, June 5, 2021 at 4:12:21 PM UTC-5, Paul A. Clayton wrote:
> On Friday, June 4, 2021 at 1:20:59 PM UTC-4, MitchAlsup wrote:
> > On Friday, June 4, 2021 at 12:01:09 PM UTC-5, Quadibloc wrote:
> >> On Friday, May 14, 2021 at 1:21:26 PM UTC-6, Thomas Koenig wrote:
> >>
> >>> It killed off too many RISC architectures. There would eventually
> >>> have been a consolidation, but x86_64 was not the right architecture
> >>> to consolidate to...
> >> So true, but there was little choice then. Now we have a second chance,
> >> ARM.
> > <
> > Not much of a choice:
> > a) mud pie
> > b) mud pudding
>
> Are you aware that AArch64 (64-bit ARM ISA) is a relatively clean RISC and that ARM is no longer developing high-performance A-profile cores that support the 32-bit ISAs? (I think an abstraction layer would be better than a traditional ISA, but the business case for such is weaker. My 66000 is better than AArch64, but AArch64 does not seem like mud pudding.)
<
While I value your opinion, you, too, will come to a different conclusion in a few years.

On 6/5/2021 10:05 AM, MitchAlsup wrote:
> On Friday, June 4, 2021 at 11:14:16 PM UTC-5, BGB wrote:
>> On 6/4/2021 5:39 PM, Quadibloc wrote:
>
>>> While that would be easy enough to remedy, since such a subroutine
>>> jump would specify a particular register as the location of the return
>>> address, that would distort the architecture, essentially warping the
>>> choice of calling conventions.
>>>
>> I used a Link Register (LR).
>>
>>
>> Implicitly, some contexts are using R1 as a secondary/stand-in Link
>> Register, and some instructions like "JMP R1" have been defined to
>> behave as-if R1 were the link register.
> <
> In Mc 88120, we used the jump-predict-table for JMP R~=0
> and we used the call-return-stack for JMP R0
>>
>

OK.

I don't have a call/return stack, but do have a special case in the
branch predictor to deal with RTSU. It is possible though that RTS and
RTSU could be merged though (with the relevant pipeline checks being
handled in hardware rather than by the compiler).

In my case it is R1 partly because that is what had ended up being used
already in this case. R1 was defined as being freely stomped and was not
otherwise used by the C ABI, but was also not used much as a stomp
register in practice, and some of the cases for which it existed as such
originally no longer exist.

While similar behavior could have also been applied to R0, the use of R0
was more often as an escape-case for encoding out-of-range branches.
Though, this later case is likely to end up subsumed into the newer "JMP
Abs48" encoding.

It can also be noted though that using R0 as a stomp register is itself
greatly reduced with the existence of a jumbo prefix.

And, at this point the main properties which R0 and R1 have are:
Special cases for Load/Store ops (eg: PC Rel, GBR Rel);
Not allowed with MOV.X or other 128-bit ops;
R0 and R1 are fixed registers for some ops (CPUID, LDTLB, ...);
R1 may be used as a stand-in for LR (or as a secondary LR);
...

On 6/5/2021 2:07 PM, MitchAlsup wrote:
> On Saturday, June 5, 2021 at 10:19:31 AM UTC-5, John Levine wrote:
>> According to Quadibloc <jsa...@ecn.ab.ca>:
>>> On the ARM, a _fixed_ register is the program counter.
>> That's what the PDP-11 did. I don't know if it was the first architecture to put the PC
>> in a register but it was certainly the most famous.
>>
>> It made relative addressing the same as indexed addressing, using the PC as the index register.
>> It had a (R)+ and @(R)+ modes, use the register as the address and then inrement it by the address and
>> then in the second case, use that as the indirect address.
>> Hence (PC)+ was an immediate operand and @(PC)+ was absolute addressing.
> <
> It was a cute trick, but made pipelineing difficult.

The MSP430 also did this.

To me, it seemed functionally equivalent to a variable-length
instruction, just with a more awkward encoding.

AFAIK, the MSP430 was pipelined.

>>
>> Considering how expensive transistors were in 1969, it was a cute hack to simplify the architecture
>> and remove what otherwise would have been special cases.
>>
>> The IBM 360 made you use a general register to address your code. In
>> retrospect that was a mistake which they fixed by adding relative
>> branches much later.
>>
>> --
>> 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

On Saturday, June 5, 2021 at 4:24:27 PM UTC-6, MitchAlsup wrote:
> On Saturday, June 5, 2021 at 4:12:21 PM UTC-5, Paul A. Clayton wrote:
> > On Friday, June 4, 2021 at 1:20:59 PM UTC-4, MitchAlsup wrote:
> > > On Friday, June 4, 2021 at 12:01:09 PM UTC-5, Quadibloc wrote:

> > >> So true, but there was little choice then. Now we have a second chance,
> > >> ARM.

> > > Not much of a choice:
> > > a) mud pie
> > > b) mud pudding

> > Are you aware that AArch64 (64-bit ARM ISA) is a relatively clean RISC
> > and that ARM is no longer developing high-performance A-profile cores
> > that support the 32-bit ISAs? (I think an abstraction layer would be better
> > than a traditional ISA, but the business case for such is weaker. My 66000
> > is better than AArch64, but AArch64 does not seem like mud pudding.)

> While I value your opinion, you, too, will come to a different conclusion in a few years.

Your point is, perhaps, that experience has already proven that the people
responsible for ARM are sufficiently market-driven that as the years go on,
they will not resist the temptation to add features to future iterations of
their architecture?

John Savard

On Sunday, June 6, 2021 at 1:24:27 AM UTC+3, MitchAlsup wrote:
> On Saturday, June 5, 2021 at 4:12:21 PM UTC-5, Paul A. Clayton wrote:
> > On Friday, June 4, 2021 at 1:20:59 PM UTC-4, MitchAlsup wrote:
> > > On Friday, June 4, 2021 at 12:01:09 PM UTC-5, Quadibloc wrote:
> > >> On Friday, May 14, 2021 at 1:21:26 PM UTC-6, Thomas Koenig wrote:
> > >>
> > >>> It killed off too many RISC architectures. There would eventually
> > >>> have been a consolidation, but x86_64 was not the right architecture
> > >>> to consolidate to...
> > >> So true, but there was little choice then. Now we have a second chance,
> > >> ARM.
> > > <
> > > Not much of a choice:
> > > a) mud pie
> > > b) mud pudding
> >
> > Are you aware that AArch64 (64-bit ARM ISA) is a relatively clean RISC and that ARM is no longer developing high-performance A-profile cores that support the 32-bit ISAs? (I think an abstraction layer would be better than a traditional ISA, but the business case for such is weaker. My 66000 is better than AArch64, but AArch64 does not seem like mud pudding.)
> <
> While I value your opinion, you, too, will come to a different conclusion in a few years.

Does it mean that you expect that in few years (how many?) the best available (== shipping, sold and bought, *not* paper) high-performance CPU would be neither mud pie nor mud pudding nor mud pastry (i.e. POWER) ?

In article <5c085551-bbe4-4e26-9ca2-a2d9c8cabc99n@googlegroups.com>,
jsavard@ecn.ab.ca (Quadibloc) wrote:

> Your point is, perhaps, that experience has already proven that the
> people responsible for ARM are sufficiently market-driven that as
> the years go on, they will not resist the temptation to add features
> to future iterations of their architecture?

They are engaged in doing this. ARM v8 has had levels v8.1 to v8.5, and
now v9 added.

A hopefully-significant difference is that they aren't doing this in the
manner of 32-bit ARM, where there were large numbers of unconnected
additions. Those were intended for embedded use, where broad software
compatibility was seen as irrelevant.

With 64-bit ARM, the baseline instruction set is quite capable, and the
additions are compatible: v8.3 includes v8.1 and v8.2, so software people
only have to cope with changes along a single path, AFAIK.

John

On Sunday, June 6, 2021 at 1:31:22 AM UTC-5, Quadibloc wrote:
> On Saturday, June 5, 2021 at 4:24:27 PM UTC-6, MitchAlsup wrote:
> > On Saturday, June 5, 2021 at 4:12:21 PM UTC-5, Paul A. Clayton wrote:
> > > On Friday, June 4, 2021 at 1:20:59 PM UTC-4, MitchAlsup wrote:
> > > > On Friday, June 4, 2021 at 12:01:09 PM UTC-5, Quadibloc wrote:
>
> > > >> So true, but there was little choice then. Now we have a second chance,
> > > >> ARM.
>
> > > > Not much of a choice:
> > > > a) mud pie
> > > > b) mud pudding
>
> > > Are you aware that AArch64 (64-bit ARM ISA) is a relatively clean RISC
> > > and that ARM is no longer developing high-performance A-profile cores
> > > that support the 32-bit ISAs? (I think an abstraction layer would be better
> > > than a traditional ISA, but the business case for such is weaker. My 66000
> > > is better than AArch64, but AArch64 does not seem like mud pudding.)
>
> > While I value your opinion, you, too, will come to a different conclusion in a few years.
> Your point is, perhaps, that experience has already proven that the people
> responsible for ARM are sufficiently market-driven that as the years go on,
> they will not resist the temptation to add features to future iterations of
> their architecture?
<
No my point is/was that the words "relative" and "clean" are not appropriate
in describing AArch64.
>
> John Savard

On Sunday, June 6, 2021 at 8:39:23 AM UTC-6, MitchAlsup wrote:

> No my point is/was that the words "relative" and "clean" are not appropriate
> in describing AArch64.

Ah. So you find it to be _already_ as bad as x86, and just think that he will
eventually see that too. But then I would ask - how is it that it can be as bad
as x86 without being as _obviously_ bad as x86?

John Savard

On 6/6/2021 5:34 AM, Michael S wrote:
> On Sunday, June 6, 2021 at 1:24:27 AM UTC+3, MitchAlsup wrote:
>> On Saturday, June 5, 2021 at 4:12:21 PM UTC-5, Paul A. Clayton wrote:
>>> On Friday, June 4, 2021 at 1:20:59 PM UTC-4, MitchAlsup wrote:
>>>> On Friday, June 4, 2021 at 12:01:09 PM UTC-5, Quadibloc wrote:
>>>>> On Friday, May 14, 2021 at 1:21:26 PM UTC-6, Thomas Koenig wrote:
>>>>>
>>>>>> It killed off too many RISC architectures. There would eventually
>>>>>> have been a consolidation, but x86_64 was not the right architecture
>>>>>> to consolidate to...
>>>>> So true, but there was little choice then. Now we have a second chance,
>>>>> ARM.
>>>> <
>>>> Not much of a choice:
>>>> a) mud pie
>>>> b) mud pudding
>>>
>>> Are you aware that AArch64 (64-bit ARM ISA) is a relatively clean RISC and that ARM is no longer developing high-performance A-profile cores that support the 32-bit ISAs? (I think an abstraction layer would be better than a traditional ISA, but the business case for such is weaker. My 66000 is better than AArch64, but AArch64 does not seem like mud pudding.)
>> <
>> While I value your opinion, you, too, will come to a different conclusion in a few years.
>
>
> Does it mean that you expect that in few years (how many?) the best available (== shipping, sold and bought, *not* paper) high-performance CPU would be neither mud pie nor mud pudding nor mud pastry (i.e. POWER) ?
>

Weighing in with my opinions here...

It seems almost inevitable that an ISA will end up messy in some areas
absent frequent redesign efforts and which break binary compatibility.

Adding features, and trying to avoid breaking existing binaries, will
mean that new features don't necessarily mesh cleanly with older
features, ...

So, eg, AArch64 deals with 32 and 64 bit operations in a roughly similar
way to x86-64, but then has funkiness to deal with sign or zero
extending inputs (rather than keeping the values themselves in a sign or
zero extended form).

It also uses condition-code flags, which personally I am not
particularly a fan of (I consider the "1 bit predicate" to be a
different system).

One other drawback with most traditional RISC designs is that to run
multiple ops in parallel, it is necessary for the hardware to be able to
figure out whether or not parallel execution is possible, which is more
difficult and more resource intensive than encoding it explicitly.

Though it is a tradeoff, in that now compiled code needs to care about
things like how wide the target machine is, ...

So, a wider machine would likely need to fall back to using the
superscalar approach if compiling code specifically for that width is
not viable.

I was almost doing OK in my current ISA, though recent efforts towards
expanding the GPR space to R0..R63 haven't been super clean.

But, why? Mostly because when writing things like rasterizer and
edge-walking loops in my OpenGL rasterizer (in ASM) I was frequently
running into issues with running out of GPRs and needing to fall back to
(gasp) spilling variables to memory.

Initially, I did an extension which only worked on SIMD ops, which
worked well enough:
These ops only used even pairs, meaning one can do R0..R63 in a 5-bit
register field. However, this was still fairly limiting.

I had recently tried the Op24 experiment, where I carved off some of the
remaining (unused) 16-bit encoding space for 24-bit instructions (7zzz
and 9zzz). They are kinda terrible though, so I decided not to have them
in the main ISA.

More recently, I have reused the same encoding space for 'XGPR' encodings:
7wnm-ZeoZ (F0zz)
9wnm-Zeii (F2zz / F1zz)

Where the 'w' field is (wnmo):
w: WEX bit;
nm: Bit 5 for Rm/Rn
o: Bit 5 of Ro, or F2/F1 selector

Which expands the main GPR space, but with a few drawbacks:
It is not possible to predicate these instructions;
ADD?T R47, R31, R55 // N/E
The non-contiguous encoding space is fairly ugly;
Encodings are mutually exclusive with Op24.

At present, I will consider them an optional feature.

It is possible that predicated forms could have been added which also
encode the full R0..R63 range, but this would basically "eat" the entire
16-bit encoding space (and effectively require the instruction decoder
to be modal, which is undesirable).

On Sunday, June 6, 2021 at 10:07:03 AM UTC-5, Quadibloc wrote:
> On Sunday, June 6, 2021 at 8:39:23 AM UTC-6, MitchAlsup wrote:
>
> > No my point is/was that the words "relative" and "clean" are not appropriate
> > in describing AArch64.
<
> Ah. So you find it to be _already_ as bad as x86, and just think that he will
> eventually see that too. But then I would ask - how is it that it can be as bad
> as x86 without being as _obviously_ bad as x86?
<
It is not as bad as x86 which is significantly better than 432.
<
But it is far from as clean as <say> MIPS in the R3000 days.
>
> John Savard

On Sunday, June 6, 2021 at 11:31:15 AM UTC-5, BGB wrote:
> On 6/6/2021 5:34 AM, Michael S wrote:
> > On Sunday, June 6, 2021 at 1:24:27 AM UTC+3, MitchAlsup wrote:
> >> On Saturday, June 5, 2021 at 4:12:21 PM UTC-5, Paul A. Clayton wrote:
> >>> On Friday, June 4, 2021 at 1:20:59 PM UTC-4, MitchAlsup wrote:
> >>>> On Friday, June 4, 2021 at 12:01:09 PM UTC-5, Quadibloc wrote:
> >>>>> On Friday, May 14, 2021 at 1:21:26 PM UTC-6, Thomas Koenig wrote:
> >>>>>
> >>>>>> It killed off too many RISC architectures. There would eventually
> >>>>>> have been a consolidation, but x86_64 was not the right architecture
> >>>>>> to consolidate to...
> >>>>> So true, but there was little choice then. Now we have a second chance,
> >>>>> ARM.
> >>>> <
> >>>> Not much of a choice:
> >>>> a) mud pie
> >>>> b) mud pudding
> >>>
> >>> Are you aware that AArch64 (64-bit ARM ISA) is a relatively clean RISC and that ARM is no longer developing high-performance A-profile cores that support the 32-bit ISAs? (I think an abstraction layer would be better than a traditional ISA, but the business case for such is weaker. My 66000 is better than AArch64, but AArch64 does not seem like mud pudding.)
> >> <
> >> While I value your opinion, you, too, will come to a different conclusion in a few years.
> >
> >
> > Does it mean that you expect that in few years (how many?) the best available (== shipping, sold and bought, *not* paper) high-performance CPU would be neither mud pie nor mud pudding nor mud pastry (i.e. POWER) ?
> >
> Weighing in with my opinions here...
>
> It seems almost inevitable that an ISA will end up messy in some areas
> absent frequent redesign efforts and which break binary compatibility.
<
This is one of the BIG reasons My 66000 has about 30% of the major OpCode space
unallocated at present. This gives plenty of room to grow, without having to squirrel
things into odd corners.
>
> Adding features, and trying to avoid breaking existing binaries, will
> mean that new features don't necessarily mesh cleanly with older
> features, ...
<
This is another BIG reason I ended up preferring instruction modifiers over instructions
when extending the ISA to cover seldom used features (CARRY is the prime example).
>
>
> So, eg, AArch64 deals with 32 and 64 bit operations in a roughly similar
> way to x86-64, but then has funkiness to deal with sign or zero
> extending inputs (rather than keeping the values themselves in a sign or
> zero extended form).
<
I completely agree
>
> It also uses condition-code flags, which personally I am not
> particularly a fan of (I consider the "1 bit predicate" to be a
> different system).
<
I completely agree, here, too.
>
>
> One other drawback with most traditional RISC designs is that to run
> multiple ops in parallel, it is necessary for the hardware to be able to
> figure out whether or not parallel execution is possible, which is more
> difficult and more resource intensive than encoding it explicitly.
<
When I built the "wide" machine, we configured the instruction cache to
have more bits per instruction to encode the intra instruction dependencies..
If an instruction in the packet consumed a result as an operand, the register
specifier had the HoB set and the lower part of the field pointed at the
instruction which would deliver said result. When an instruction produces
a result that did not survive the end of the packet, we marked it as dead
so we did not even allocate a destination register for it.
<
This isolated all of this fairly hard BigO( n^3-to-n^3 ) into the packet builder;
which had execution window cycles to build packets and write the instruction
cache. When running out-of-Icache we only decoded 1 instruction per cycle
and used the inter-packet dependency logic to deal with dependencies. We
remembered these dependencies while the instruction(!) executed, and then
we used the info when packing instructions into the packet.
<
When running in-packet, you get 6-8 instructions per access and can transfer
control to 2 (or 3) different target addresses for the next fetch. There is no
arithmetic in the selection process, merely a "tag" from the packet and "take"
(or "agree") bits from the predictor(s).
<
Were I to do this today, I would do 2 instruction per cycle running out-of Icache.
>
> Though it is a tradeoff, in that now compiled code needs to care about
> things like how wide the target machine is, ...
<
The major thing the compiler should be concerned with is generating the
fewest instructions possible to calculate the semantics of the program;
AND the fewest control transfers possible (i.e., use PRED instead of Branch).
>
> So, a wider machine would likely need to fall back to using the
> superscalar approach if compiling code specifically for that width is
> not viable.
<
I want code compiled for a 1-wide in-order machine to run within spitting
distance (10%-ish) of the best code possible for the Great Big Out-of-Order
Machine.
>
>
>
>
> I was almost doing OK in my current ISA, though recent efforts towards
> expanding the GPR space to R0..R63 haven't been super clean.
>
> But, why? Mostly because when writing things like rasterizer and
> edge-walking loops in my OpenGL rasterizer (in ASM) I was frequently
> running into issues with running out of GPRs and needing to fall back to
> (gasp) spilling variables to memory.
<
I consider a rasterizer to be a dedicated unit that spits out long vectors
of pixels needed to be passed through a pixel processing kernel. you feed
it triangles, it feeds you vectors of pixels with interpolated coordinates.
That is: this is really one of those things you want dedicated HW for if
you want to run fast.
<
I understand the the HW BGB is working with does not provide the area
to be able to do this.
>
> Initially, I did an extension which only worked on SIMD ops, which
> worked well enough:
> These ops only used even pairs, meaning one can do R0..R63 in a 5-bit
> register field. However, this was still fairly limiting.
>
> I had recently tried the Op24 experiment, where I carved off some of the
> remaining (unused) 16-bit encoding space for 24-bit instructions (7zzz
> and 9zzz). They are kinda terrible though, so I decided not to have them
> in the main ISA.
>
>
> More recently, I have reused the same encoding space for 'XGPR' encodings:
> 7wnm-ZeoZ (F0zz)
> 9wnm-Zeii (F2zz / F1zz)
>
> Where the 'w' field is (wnmo):
> w: WEX bit;
> nm: Bit 5 for Rm/Rn
> o: Bit 5 of Ro, or F2/F1 selector
>
> Which expands the main GPR space, but with a few drawbacks:
> It is not possible to predicate these instructions;
> ADD?T R47, R31, R55 // N/E
> The non-contiguous encoding space is fairly ugly;
> Encodings are mutually exclusive with Op24.
>
> At present, I will consider them an optional feature.
>
>
>
> It is possible that predicated forms could have been added which also
> encode the full R0..R63 range, but this would basically "eat" the entire
> 16-bit encoding space (and effectively require the instruction decoder
> to be modal, which is undesirable).

On Sunday, June 6, 2021 at 3:20:08 PM UTC-6, MitchAlsup wrote:

> This is one of the BIG reasons My 66000 has about 30% of the major OpCode space
> unallocated at present. This gives plenty of room to grow, without having to squirrel
> things into odd corners.

That certainly makes it vastly better than the current iteration of my Concertina II
architecture in that respect. While there is indeed a vast amount of unallocated opcode
space in the _secondary_ opcode space... the _main_ opcode space is starting life with
things squirreled into odd corners. (However, a _part_ of the main opcode space actually
does have room to grow, the register-to-register operate instructions. Only the
memory-reference instructions are squeezed so tightly no real room is left.)

Since things like carry and full base-index addressing are found on _historical_
architectures, I've included them in the standard instruction set, not concerning
myself about whether they're "rarely used". Saturating multiply, on the other hand,
is not common on historical architectures, so I wasn't familiar with any requirement
for it.

John Savard

On Sunday, June 6, 2021 at 3:20:08 PM UTC-6, MitchAlsup wrote:

> I want code compiled for a 1-wide in-order machine to run within spitting
> distance (10%-ish) of the best code possible for the Great Big Out-of-Order
> Machine.

If you mean that you want the code _compiled_ for 1-wide in-order to
run within 10% of code specifically tailored to the GBOoO machine...
*also on the same GBOoO machine*, that's actually a very conventional
design goal.

In fact, that's partly _why_ we _have_ out-of-order machines instead of
VLIW or similar techniques being common. Cache and OoO are both
ways of making programs run faster without forcing existing code to
be re-written. That was what IBM was up to back when it came up with
the Model 85 with cache and the Model 91 with OoO.

When I first read that sentence, though, I thought you might have been
talking about code compiled for a 1-wide in-order machine running within
10%... while it was running on the 1-wide in-order machine. That, of course,
is flat-out impossible (unless the 1-wide in-order machine has faster
transistors) but I have no doubt that you know that perfectly well.

John Savard

MitchAlsup wrote:
> On Sunday, June 6, 2021 at 11:31:15 AM UTC-5, BGB wrote:
>> Though it is a tradeoff, in that now compiled code needs to care about
>> things like how wide the target machine is, ...
> <
> The major thing the compiler should be concerned with is generating the
> fewest instructions possible to calculate the semantics of the program;
> AND the fewest control transfers possible (i.e., use PRED instead of Branch).

Totally by coincidence (?), that's almost exactly the same heuristic I
use when writing (i.e. optimizing) asm. :-)

Keep it short _and_ branchless if possible.

Since I often end up with some funky lookup tables to handle the most
complicated logic, I also try to minimize the (working set) size of
those tables. My word counter is a good example:

Count characters, words and lines, with user-specified word and line
separator sets. 256 bytes processed in a straight unrolled block using
just 2 or 3 instructions/byte.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 2021-06-06, MitchAlsup wrote:
> On Sunday, June 6, 2021 at 11:31:15 AM UTC-5, BGB wrote:
>> On 6/6/2021 5:34 AM, Michael S wrote:
>>> On Sunday, June 6, 2021 at 1:24:27 AM UTC+3, MitchAlsup wrote:
>>>> On Saturday, June 5, 2021 at 4:12:21 PM UTC-5, Paul A. Clayton wrote:
>>>>> On Friday, June 4, 2021 at 1:20:59 PM UTC-4, MitchAlsup wrote:
>>>>>> On Friday, June 4, 2021 at 12:01:09 PM UTC-5, Quadibloc wrote:
>>>>>>> On Friday, May 14, 2021 at 1:21:26 PM UTC-6, Thomas Koenig wrote:
>>>>>>>
>>>>>>>> It killed off too many RISC architectures. There would eventually
>>>>>>>> have been a consolidation, but x86_64 was not the right architecture
>>>>>>>> to consolidate to...
>>>>>>> So true, but there was little choice then. Now we have a second chance,
>>>>>>> ARM.
>>>>>> <
>>>>>> Not much of a choice:
>>>>>> a) mud pie
>>>>>> b) mud pudding
>>>>>
>>>>> Are you aware that AArch64 (64-bit ARM ISA) is a relatively clean RISC and that ARM is no longer developing high-performance A-profile cores that support the 32-bit ISAs? (I think an abstraction layer would be better than a traditional ISA, but the business case for such is weaker. My 66000 is better than AArch64, but AArch64 does not seem like mud pudding.)
>>>> <
>>>> While I value your opinion, you, too, will come to a different conclusion in a few years.
>>>
>>>
>>> Does it mean that you expect that in few years (how many?) the best available (== shipping, sold and bought, *not* paper) high-performance CPU would be neither mud pie nor mud pudding nor mud pastry (i.e. POWER) ?
>>>
>> Weighing in with my opinions here...
>>
>> It seems almost inevitable that an ISA will end up messy in some areas
>> absent frequent redesign efforts and which break binary compatibility.
> <
> This is one of the BIG reasons My 66000 has about 30% of the major OpCode space
> unallocated at present. This gives plenty of room to grow, without having to squirrel
> things into odd corners.

Opcode space usage (and hence extensibility) was a main concern when
designing the MRISC32 ISA. I currently have almost 40% of the major
opcode space unallocated (and that's _with_ support for vector
operations, packed/SIMD operations as well as DSP-style fixed point
operations such as saturating arithmetic). In addition to that I also
have two unallocated 28-bit pages for future extensions (e.g. for
new instruction encoding formats, or for extending the existing
formats with more opcode space).

Granted, this is only for the user space ISA, but I expect that
supervisor mode instructions will not eat up too much of the opcode
space.

>>
>> Adding features, and trying to avoid breaking existing binaries, will
>> mean that new features don't necessarily mesh cleanly with older
>> features, ...
> <
> This is another BIG reason I ended up preferring instruction modifiers over instructions
> when extending the ISA to cover seldom used features (CARRY is the prime example).
>>
>>
>> So, eg, AArch64 deals with 32 and 64 bit operations in a roughly similar
>> way to x86-64, but then has funkiness to deal with sign or zero
>> extending inputs (rather than keeping the values themselves in a sign or
>> zero extended form).
> <
> I completely agree
>>
>> It also uses condition-code flags, which personally I am not
>> particularly a fan of (I consider the "1 bit predicate" to be a
>> different system).
> <
> I completely agree, here, too.
>>
>>
>> One other drawback with most traditional RISC designs is that to run
>> multiple ops in parallel, it is necessary for the hardware to be able to
>> figure out whether or not parallel execution is possible, which is more
>> difficult and more resource intensive than encoding it explicitly.
> <
> When I built the "wide" machine, we configured the instruction cache to
> have more bits per instruction to encode the intra instruction dependencies.
> If an instruction in the packet consumed a result as an operand, the register
> specifier had the HoB set and the lower part of the field pointed at the
> instruction which would deliver said result. When an instruction produces
> a result that did not survive the end of the packet, we marked it as dead
> so we did not even allocate a destination register for it.
> <
> This isolated all of this fairly hard BigO( n^3-to-n^3 ) into the packet builder;
> which had execution window cycles to build packets and write the instruction
> cache. When running out-of-Icache we only decoded 1 instruction per cycle
> and used the inter-packet dependency logic to deal with dependencies. We
> remembered these dependencies while the instruction(!) executed, and then
> we used the info when packing instructions into the packet.
> <
> When running in-packet, you get 6-8 instructions per access and can transfer
> control to 2 (or 3) different target addresses for the next fetch. There is no
> arithmetic in the selection process, merely a "tag" from the packet and "take"
> (or "agree") bits from the predictor(s).
> <
> Were I to do this today, I would do 2 instruction per cycle running out-of Icache.
>>
>> Though it is a tradeoff, in that now compiled code needs to care about
>> things like how wide the target machine is, ...
> <
> The major thing the compiler should be concerned with is generating the
> fewest instructions possible to calculate the semantics of the program;
> AND the fewest control transfers possible (i.e., use PRED instead of Branch).
>>
>> So, a wider machine would likely need to fall back to using the
>> superscalar approach if compiling code specifically for that width is
>> not viable.
> <
> I want code compiled for a 1-wide in-order machine to run within spitting
> distance (10%-ish) of the best code possible for the Great Big Out-of-Order
> Machine.
>>
>>
>>
>>
>> I was almost doing OK in my current ISA, though recent efforts towards
>> expanding the GPR space to R0..R63 haven't been super clean.
>>
>> But, why? Mostly because when writing things like rasterizer and
>> edge-walking loops in my OpenGL rasterizer (in ASM) I was frequently
>> running into issues with running out of GPRs and needing to fall back to
>> (gasp) spilling variables to memory.
> <
> I consider a rasterizer to be a dedicated unit that spits out long vectors
> of pixels needed to be passed through a pixel processing kernel. you feed
> it triangles, it feeds you vectors of pixels with interpolated coordinates.
> That is: this is really one of those things you want dedicated HW for if
> you want to run fast.
> <
> I understand the the HW BGB is working with does not provide the area
> to be able to do this.
>>
>> Initially, I did an extension which only worked on SIMD ops, which
>> worked well enough:
>> These ops only used even pairs, meaning one can do R0..R63 in a 5-bit
>> register field. However, this was still fairly limiting.
>>
>> I had recently tried the Op24 experiment, where I carved off some of the
>> remaining (unused) 16-bit encoding space for 24-bit instructions (7zzz
>> and 9zzz). They are kinda terrible though, so I decided not to have them
>> in the main ISA.
>>
>>
>> More recently, I have reused the same encoding space for 'XGPR' encodings:
>> 7wnm-ZeoZ (F0zz)
>> 9wnm-Zeii (F2zz / F1zz)
>>
>> Where the 'w' field is (wnmo):
>> w: WEX bit;
>> nm: Bit 5 for Rm/Rn
>> o: Bit 5 of Ro, or F2/F1 selector
>>
>> Which expands the main GPR space, but with a few drawbacks:
>> It is not possible to predicate these instructions;
>> ADD?T R47, R31, R55 // N/E
>> The non-contiguous encoding space is fairly ugly;
>> Encodings are mutually exclusive with Op24.
>>
>> At present, I will consider them an optional feature.
>>
>>
>>
>> It is possible that predicated forms could have been added which also
>> encode the full R0..R63 range, but this would basically "eat" the entire
>> 16-bit encoding space (and effectively require the instruction decoder
>> to be modal, which is undesirable).

On Monday, June 7, 2021 at 7:47:00 AM UTC-5, Marcus wrote:
> On 2021-06-06, MitchAlsup wrote:
> > On Sunday, June 6, 2021 at 11:31:15 AM UTC-5, BGB wrote:

> > This is one of the BIG reasons My 66000 has about 30% of the major OpCode space
> > unallocated at present. This gives plenty of room to grow, without having to squirrel
> > things into odd corners.
<
> Opcode space usage (and hence extensibility) was a main concern when
> designing the MRISC32 ISA. I currently have almost 40% of the major
> opcode space unallocated (and that's _with_ support for vector
> operations, packed/SIMD operations as well as DSP-style fixed point
> operations such as saturating arithmetic). In addition to that I also
> have two unallocated 28-bit pages for future extensions (e.g. for
> new instruction encoding formats, or for extending the existing
> formats with more opcode space).
<
The Major Opcode space in My 66000 is chopped into 4 regions: 00 OpCode
expansion, 01 Control Transfer, 10 memory ref with 16-bit immediate, 11
integer and logical with 16-bit immediate.
<
The OpCode expansion is further partitioned into 2 sub regions 000 OpCode
expansion with immediates, 001 OpCOde expansion without immediate.
There are 2 of 8 in 000, and 4 of 8 in 001. All large constants are accessed
through 001.
<
Control transfer is partitioned into 2 sub regions, one 010 is empty, and
011 has 5 branch and call instructions in it.
<
Now, from this Major OpCOde region, certain major opcodes are reserved
indefinitely, so that there is a very high probability of taking an ILLEGAL
OpCode exception if one transfers control into integer of floating point
data. {The MMU tables can also prevent this.}
>
> Granted, this is only for the user space ISA, but I expect that
> supervisor mode instructions will not eat up too much of the opcode
> space.
<
My 66000 has no (zero, nada, zilch) supervisor instructions.
>

On Monday, June 7, 2021 at 11:49:08 AM UTC-6, MitchAlsup wrote:

> My 66000 has no (zero, nada, zilch) supervisor instructions.

No doubt it uses some other mechanism for allowing the operating
system to enforce stuff on user processes, such as doing everything
by means of memory mapping. (How you avoid having supervisor
instructions to *manage the memory map*, though, is perhaps the
question.)

My only potential concern might be that system software writers might
experience difficulty in adapting to a novel approach.

John Savard

On Monday, June 7, 2021 at 3:07:21 PM UTC-5, Quadibloc wrote:
> On Monday, June 7, 2021 at 11:49:08 AM UTC-6, MitchAlsup wrote:
>
> > My 66000 has no (zero, nada, zilch) supervisor instructions.
<
> No doubt it uses some other mechanism for allowing the operating
> system to enforce stuff on user processes, such as doing everything
> by means of memory mapping. (How you avoid having supervisor
> instructions to *manage the memory map*, though, is perhaps the
> question.)
<
If your MMU tables allow you to read an write, then you can control
something--like enabling a thread to run, disabling a thread from
running,..... There will be some threads in the system with permission
to read and write your {or his or hers} MMU tables. These control access
to memory and thus to all things contained in memory--and all registers
and thread state have a "place" in memory. HW is more like a cache
in spilling and filling machine registers.
>
> My only potential concern might be that system software writers might
> experience difficulty in adapting to a novel approach.
<
The *visor merely has to enable the thread, and then disable itself and
the machine does the rest. No saving registers, and state, no restoring
registers and state. All state associated with a thread/task is HW
managed at context switch time and software managed at all other
times.
<
Since the *visor has access to the enable bit of the thread, it also has
access to the register file and can thus read arguments to system calls
or deliver return values back to the caller.
<
If/when a debugger assesses your register file and the thread is running,
the thread comes to a quiescent point, the register is read, and the thread
resumes. Same for thread state registers. Use the same address whether
the thread is running or quiescent.
>
> John Savard

On 2021-06-07, MitchAlsup wrote:
> My 66000 has no (zero, nada, zilch) supervisor instructions.

Interesting. I read your explanation about MMU tables. How about other
things, like cache control and interrupt & exception control? Machine
status & feature registers? Is that handled via protected memory mapped
registers?

/Marcus