On Wed, 29 Nov 2023 17:15:00 +0000, Quadibloc wrote:

> I have now modified the 17-bit shift instructions in the diagram, so
> that they can also apply to all 32 integer registers, and I have
> corrected the opcodes on the page
>
> http://www.quadibloc.com/arch/cw0101.htm

And now I have completed the process of getting back to where I was before,
by adding in the page

http://www.quadibloc.com/arch/cw0102.htm

which describes the instructions longer than 32 bits.

John Savard

BGB wrote:

> It seems to me, one should be able to get away with 3 modes:
> Machine / ISR;
> Supervisor;
> User.

I have been thinking about this for a while::

It seems to me that if one wants a robust system, the HyperVisor must
support various serviced-HyperVisors. This second (less privileged HV)
is, in essence, a HV that can crash without allowing the whole system
to crash {just like virtual machines can crash and take their applications
with them.}

Secondly:: Running an ISR at HV level is a privilege inversion issue,
the HV has to look at data structures maintained by a (not necessarily
trustable) Guest OS--possibly corrupting the HV itself.

So while a 3 level system gives you most of what you want in a modern
system, it still has its own problems--that can be solved with a 4th.

On Fri, 01 Dec 2023 18:37:17 +0000, MitchAlsup wrote:

> Why not decode assuming there is a block header and also decode as if
> there were not a block header. Then you can multiplex (choose) later
> which one prevails. This puts the choice at at least 4 gates of delay
> into the decode cycle.

You are quite correct that this is a possible technique to speed up an
implementation of the architecture, at the cost of using extra electricity
to do work that will be thrown away later.

I described things in terms of a naive implementation to make the concepts
easier to understand.

(quoting me)
>> If so, process the header, and that will directly and immediately
>> reveal where every instruction in the block begins, so again the next
>> step has all the instructions being decoded in parallel.

> You then have to route the instructions to the decoders. Are your
> decoders expensive enough in a wide implementation that this matters?
> The alternative is to have a no-header decoder running in parallel with
> a header decoder and choose which to use.

I wasn't thinking of routing instructions to decoders. Instead, the
decoders simply sit behind the physical positions in the block where
an instruction could begin, and the header (or the absence of a header)
tells them to start decoding. Or, in the type of fast implementation
you describe, to continue with decoding.

> You MAY be able to alter the headers later in the architecture's life,
> but ultimately you sacrifice forward compatibility.

As long as I can avoid sacrificing *backwards* compatibility.

>> Among the features the headers allow to be added are VLIW features,

> Why would you want this ??

So the architecture could be used for very cheap embedded systems,
in addition to heavyweight desktops and servers.

>> This allows high-performance but lightweight (non-OoO) implementations
>> if desired.

> Have any GBnOoO machines been successful ?

Ah, you don't mean out-of-order 68000 machines. Of which there was only
one, the 68050. You mean "great big not out of order" machines. Of which
there were none, the design being, no doubt, so outrageous as to not
even deserve the chance to fail, since it would have no chance to succeed.

That's a very valid point, but any ISA for a "great big" machine can have
a subset which no longer requires a "great big" machine.

John Savard

On 2023-12-01 4:58 p.m., MitchAlsup wrote:
> BGB wrote:
>
>> It seems to me, one should be able to get away with 3 modes:
>>    Machine / ISR;
>>    Supervisor;
>>    User.
>
> I have been thinking about this for a while::
>
> It seems to me that if one wants a robust system, the HyperVisor must
> support various serviced-HyperVisors. This second (less privileged HV)
> is, in essence, a HV that can crash without allowing the whole system to
> crash {just like virtual machines can crash and take their applications
> with them.}
>
> Secondly:: Running an ISR at HV level is a privilege inversion issue,
> the HV has to look at data structures maintained by a (not necessarily
> trustable) Guest OS--possibly corrupting the HV itself.
>
> So while a 3 level system gives you most of what you want in a modern
> system, it still has its own problems--that can be solved with a 4th.

In one version of Thor there were 5 modes:
ISR / Debug
Machine
Hypervisor
Supervisor
User

Having debug as a separate mode simplified things. Debug was meant as
more of a development mode.
Also had 256 privilege levels controlled by a level setting in the
memory page attributes. This was mainly intended for user mode.

mitchalsup@aol.com (MitchAlsup) writes:
>BGB wrote:
>
>> It seems to me, one should be able to get away with 3 modes:
>> Machine / ISR;
>> Supervisor;
>> User.
>
>I have been thinking about this for a while::
>
>It seems to me that if one wants a robust system, the HyperVisor must
>support various serviced-HyperVisors. This second (less privileged HV)
>is, in essence, a HV that can crash without allowing the whole system
>to crash {just like virtual machines can crash and take their applications
>with them.}

Generally there must be a privilege level more privileged than
hypervisor, which controls the hardware - particularly if one
intends to 'schedule' multiple independent (not nested) hypervisors.

Then there is a requirement in the cloud for a nested hypervisor; this
can be done with a paravirtualized hypervisor, at some performance
cost, or with a true hardware supported nesting capability.

>
>Secondly:: Running an ISR at HV level is a privilege inversion issue,
>the HV has to look at data structures maintained by a (not necessarily
>trustable) Guest OS--possibly corrupting the HV itself.

Modern interrupt virtualization mechanisms (e.g. ARMv8 GICv4.1)
handle guest interrupts completely in the hardware, with no
hypervisor intervention involved in the most common cases
(e.g. software generated interprocessor interrupts, virtual
timer interrupts, message signaled interrupts, et alia).

>
>So while a 3 level system gives you most of what you want in a modern
>system, it still has its own problems--that can be solved with a 4th.

Scott Lurndal wrote:

> mitchalsup@aol.com (MitchAlsup) writes:
>>BGB wrote:
>>
>>> It seems to me, one should be able to get away with 3 modes:
>>> Machine / ISR;
>>> Supervisor;
>>> User.
>>
>>I have been thinking about this for a while::
>>
>>It seems to me that if one wants a robust system, the HyperVisor must
>>support various serviced-HyperVisors. This second (less privileged HV)
>>is, in essence, a HV that can crash without allowing the whole system
>>to crash {just like virtual machines can crash and take their applications
>>with them.}

> Generally there must be a privilege level more privileged than
> hypervisor, which controls the hardware - particularly if one
> intends to 'schedule' multiple independent (not nested) hypervisors.

So, call my HV System Manage Mode and call my Guest HV the HyperVisor.

> Then there is a requirement in the cloud for a nested hypervisor; this
> can be done with a paravirtualized hypervisor, at some performance
> cost, or with a true hardware supported nesting capability.

>>
>>Secondly:: Running an ISR at HV level is a privilege inversion issue,
>>the HV has to look at data structures maintained by a (not necessarily
>>trustable) Guest OS--possibly corrupting the HV itself.

> Modern interrupt virtualization mechanisms (e.g. ARMv8 GICv4.1)
> handle guest interrupts completely in the hardware, with no
> hypervisor intervention involved in the most common cases
> (e.g. software generated interprocessor interrupts, virtual
> timer interrupts, message signaled interrupts, et alia).

My 66000 has interrupt tables similar to RISC-V (in that you can have
as many tables as you want, and any table can interrupt to any priority.)

Unlike RISC-V My 66000 LLC has a little machine which operates the
tables, so devices raise an interrupt by sending a message to the
little machine which sets a bit in the table {and when enabled
a core operating at lower priority than NSARFs the table update
and requests the highest priority pending and enabled interrupt
(getInterrupt "bus transaction"). When the response arrives and
the core is still operating at a lower priority level, core responds
with a claimiInterrupt (or a put Interrupt) "bus transaction" and
only at this point stops running the old context code and context
switches to irsDispatcher.

Cores send IPIs by using the little machine.....

>>
>>So while a 3 level system gives you most of what you want in a modern
>>system, it still has its own problems--that can be solved with a 4th.

On 12/1/2023 6:15 PM, MitchAlsup wrote:
> Scott Lurndal wrote:
>
>> mitchalsup@aol.com (MitchAlsup) writes:
>>> BGB wrote:
>>>
>>>> It seems to me, one should be able to get away with 3 modes:
>>>>    Machine / ISR;
>>>>    Supervisor;
>>>>    User.
>>>
>>> I have been thinking about this for a while::
>>>
>>> It seems to me that if one wants a robust system, the HyperVisor must
>>> support various serviced-HyperVisors. This second (less privileged HV)
>>> is, in essence, a HV that can crash without allowing the whole system
>>> to crash {just like virtual machines can crash and take their
>>> applications
>>> with them.}
>
>> Generally there must be a privilege level more privileged than
>> hypervisor, which controls the hardware - particularly if one
>> intends to 'schedule' multiple independent (not nested) hypervisors.
>
> So, call my HV System Manage Mode and call my Guest HV the HyperVisor.
>
>> Then there is a requirement in the cloud for a nested hypervisor; this
>> can be done with a paravirtualized hypervisor, at some performance
>> cost, or with a true  hardware supported nesting capability.
>
>>>
>>> Secondly:: Running an ISR at HV level is a privilege inversion issue,
>>> the HV has to look at data structures maintained by a (not necessarily
>>> trustable) Guest OS--possibly corrupting the HV itself.
>
>> Modern interrupt virtualization mechanisms (e.g. ARMv8 GICv4.1)
>> handle guest interrupts completely in the hardware, with no
>> hypervisor intervention involved in the most common cases
>> (e.g. software generated interprocessor interrupts, virtual
>> timer interrupts, message signaled interrupts, et alia).
>
> My 66000 has interrupt tables similar to RISC-V (in that you can have
> as many tables as you want, and any table can interrupt to any priority.)
>
> Unlike RISC-V My 66000 LLC has a little machine which operates the
> tables, so devices raise an interrupt by sending a message to the
> little machine which sets a bit in the table {and when enabled a core
> operating at lower priority than NSARFs the table update
> and requests the highest priority pending and enabled interrupt
> (getInterrupt "bus transaction"). When the response arrives and
> the core is still operating at a lower priority level, core responds
> with a claimiInterrupt (or a put Interrupt) "bus transaction" and
> only at this point stops running the old context code and context
> switches to irsDispatcher.
>
> Cores send IPIs by using the little machine.....

Fwiw, how would your system handle this function from Microsoft:

https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers

Or, would that be kernel?

>
>>>
>>> So while a 3 level system gives you most of what you want in a modern
>>> system, it still has its own problems--that can be solved with a 4th.

Chris M. Thomasson wrote:

> On 12/1/2023 6:15 PM, MitchAlsup wrote:

>>
>> Cores send IPIs by using the little machine.....

> Fwiw, how would your system handle this function from Microsoft:

> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers

> Or, would that be kernel?

Core could send multiple IPIs in a loop or core could send a single IPI
to a kernel function that performs the loop.

Since performing 1 IPI re

>>
>>>>
>>>> So while a 3 level system gives you most of what you want in a modern
>>>> system, it still has its own problems--that can be solved with a 4th.

MitchAlsup wrote:

> Chris M. Thomasson wrote:

>> On 12/1/2023 6:15 PM, MitchAlsup wrote:

>>>
>>> Cores send IPIs by using the little machine.....

>> Fwiw, how would your system handle this function from Microsoft:

>> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers

>> Or, would that be kernel?

> Core could send multiple IPIs in a loop or core could send a single IPI
> to a kernel function that performs the loop.

> Since performing 1 IPI requires 2 STs and does not require waiting on a
> response, it is probably easier if the core does the loop.

On 11/24/23 9:43 AM, Robert Finch wrote:
[snip]
> There is a lot of value in having a unique architecture.

A uniquely difficult architecture like x86 increases the barrier
to competition both from patents and organizational knowledge and
tools. While MIPS managed to suppress clones with its patent on
unaligned loads (please correct any historical inaccuracy), Intel
was better positioned to discourage software-compatible
competition — and not just financially.

I suspect that the bad reputation of x86 among computer architects
— especially with the biases from Computer Architecture: A
Quantitative Approach which substantially informs computer
architecture education — might also make finding talent more
difficult. However, the prominence of the x86 vendors (working on
something that actually gets produced and used by millions of
people is gratifying) and the challenge of working on a difficult
architecture would also attract talent (and perhaps more qualified
talent).

> The x86
> has had a lot of things bolted on to it. It has adapted over time.
> Being able to see how things have changed is valuable.

x86 provides more than one lesson on change/project management.
The binary lock-in advantage of x86 makes architectural changes
more challenging. While something like the 8080 to 8086 "assembly
compatible" transition might have been practical and long-term
beneficial from an engineering perspective, from a business
perspective such would validate binary translation, reducing the
competitive barriers.

(Itanium showed that mediocre hardware translation between x86 and
a rather incompatible architecture (and microarchitecture) would
have been problematic even if native Itanium code had competitive
performance. This seems reminiscent of the Pentium Pro's "issue"
with 16-bit code; both seem to have been at least partially
marketing failures. On the other hand, ARM designed a 64-bit
architecture that is only moderately compatible with the 32-bit
architecture — flags being one example of compatibility — and 32-
bit support is now being mostly left behind for 64-bit
implementations.)

> I suspect
> just about any architecture adapted over a 40 or 50 years period
> would look no so appealing.

Which 40 years makes a difference as does the original target
market. Binary compatibility for x86 was a larger burden because
the initial target was for a 16-bit microprocessor. x86 also
suffered from success; having the financial resources and the
market incentives to add features probably contributed to the
oddness of x86.

MIPS (even with its delayed branches, lack of variable length
encoding, etc.) would probably be a better architecture in 2023
than x86 was around 2010. The delayed branches might have been
deprecated, VLE might have been added in an additional mode, and
eventually complex-but-useful instructions would probably have
been added. (MIPS would almost certainly have caught SIMD widening
disease and had other temporarily useful extension additions, but
the tradeoffs in 1985 were closer to those of 2023.)

> I happen to like the segmented
> approach, not necessarily because it is a good way to do things,
> but it was certainly interesting and challenging. An interesting,
> challenging, and somewhat mysterious architecture may be more
> appealing than the best organized, most performant, energy
> efficient one. There is a trade-off between ‘the best’ and the
> ‘human factor’.

Elegance also has an inherent attraction. Such a 'human factor'
(enthusiasts) can help marketing somewhat, but chance and business
factors seem more important. (Enthusiasts can also harm a brand's
image or merely be less relevant for some markets.)

On 12/2/2023 9:35 AM, MitchAlsup wrote:
> MitchAlsup wrote:
>
>> Chris M. Thomasson wrote:
>
>>> On 12/1/2023 6:15 PM, MitchAlsup wrote:
>
>>>>
>>>> Cores send IPIs by using the little machine.....
>
>>> Fwiw, how would your system handle this function from Microsoft:
>
>>> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers
>
>>> Or, would that be kernel?
>
>> Core could send multiple IPIs in a loop or core could send a single IPI
>> to a kernel function that performs the loop.
>
>> Since performing 1 IPI requires 2 STs and does not require waiting on a
>> response, it is probably easier if the core does the loop.

Sounds good! Thanks. Fwiw, this can be fairly useful for certain
experimental asymmetric synchronization algorithms. Especially user mode
RCU. Something along the lines of synchronize_rcu() wrt quiescent states.

https://www.kernel.org/doc/html/latest/RCU/index.html

Paul A. Clayton wrote:

> On 11/24/23 9:43 AM, Robert Finch wrote:
> [snip]
>> There is a lot of value in having a unique architecture.

> A uniquely difficult architecture like x86 increases the barrier
> to competition both from patents and organizational knowledge and
> tools. While MIPS managed to suppress clones with its patent on
> unaligned loads (please correct any historical inaccuracy), Intel
> was better positioned to discourage software-compatible
> competition — and not just financially.

In Intel's case one must not just execute the x86 ISA but also be
bug-for-bug compatible. AMD K5 was essentially sacrificed to find
that bug-for-bug compatibility--that is they found the test vector
set that defined x86.

> I suspect that the bad reputation of x86 among computer architects
> — especially with the biases from Computer Architecture: A
> Quantitative Approach which substantially informs computer
> architecture education — might also make finding talent more
> difficult. However, the prominence of the x86 vendors (working on
> something that actually gets produced and used by millions of
> people is gratifying) and the challenge of working on a difficult
> architecture would also attract talent (and perhaps more qualified
> talent).

>> The x86
>> has had a lot of things bolted on to it. It has adapted over time.
>> Being able to see how things have changed is valuable.

> x86 provides more than one lesson on change/project management.
> The binary lock-in advantage of x86 makes architectural changes
> more challenging. While something like the 8080 to 8086 "assembly
> compatible" transition might have been practical and long-term
> beneficial from an engineering perspective, from a business
> perspective such would validate binary translation, reducing the
> competitive barriers.

> (Itanium showed that mediocre hardware translation between x86 and
> a rather incompatible architecture (and microarchitecture) would
> have been problematic even if native Itanium code had competitive

So did Transmeta.

> performance. This seems reminiscent of the Pentium Pro's "issue"
> with 16-bit code; both seem to have been at least partially
> marketing failures. On the other hand, ARM designed a 64-bit
> architecture that is only moderately compatible with the 32-bit
> architecture — flags being one example of compatibility — and 32-
> bit support is now being mostly left behind for 64-bit
> implementations.)
----------------
> MIPS (even with its delayed branches, lack of variable length
> encoding, etc.) would probably be a better architecture in 2023
> than x86 was around 2010. The delayed branches might have been
> deprecated, VLE might have been added in an additional mode, and
> eventually complex-but-useful instructions would probably have
> been added. (MIPS would almost certainly have caught SIMD widening
> disease and had other temporarily useful extension additions, but
> the tradeoffs in 1985 were closer to those of 2023.)

The early 00's were a good time to avoid being an architect--SIMD
was very appealing and is now showing its age.....

On 11/13/2023 1:58 PM, Chris M. Thomasson wrote:
> On 11/12/2023 6:44 PM, Quadibloc wrote:
>> On Mon, 13 Nov 2023 00:16:24 +0000, MitchAlsup wrote:
>>
>>> A poorly chosen starting point (dark alley)
>>
>>> Back out of the dark alley, and start from first principles again.
>>
>> By the way, I think you mean a _blind_ alley.
>>
>> A dark alley is just a dangerous place, since robbers can attack you
>> there without being seen.
>
> Expose the darkness to the light, before any adventures...? ;^)

Darkness... Likely to be eaten by a grue...

>
>>
>> A _blind_ alley is one that had no exit, one that is a dead end. That
>> seems to better fit the context of your remarks.
>>
>> John Savard
>

On Fri, 01 Dec 2023 22:10:39 +0000, Quadibloc wrote:
> On Fri, 01 Dec 2023 18:37:17 +0000, MitchAlsup wrote:
>
>> Have any GBnOoO machines been successful ?
>
> Ah, you don't mean out-of-order 68000 machines. Of which there was only
> one, the 68050. You mean "great big not out of order" machines. Of which
> there were none, the design being, no doubt, so outrageous as to not
> even deserve the chance to fail, since it would have no chance to
> succeed.
>
> That's a very valid point, but any ISA for a "great big" machine can
> have a subset which no longer requires a "great big" machine.

Also, as you are well aware, Intel has included both "performance" and
"efficiency" cores in its latest generations of CPUs, similar to the
BIG.little architecture used for some ARM processors.

And then AMD came along, with its own twist on this feature: their
"little" processors aren't so little, having the same circuitry as the
big ones, but laid out more compactly so they have to have a lower
clock speed. That way, they're not so slow as to be a total waste in
normal full-power operation, and thus add to the total core count.

Well, another way to address the efficiency/little cores being a
waste of space would be to reduce the waste by making them smaller.
If their purpose is to save power consumption when nobody's using the
computer, to just keep the OS alive while it waits for the keyboard
or the mouse to ask it to do something... then they should be made
really little.

Like Intel's _original_ Atom processors, which were in-order. As they
were standalone processors for light and cheap laptops, Intel made
the right decision to switch to out-of-order for later versions, so
they wouldn't be so slow as to be useless.

But in-order efficiency cores that are there when the demands are very
low? With features that let one optimize code for them, though?

John Savard

On Fri, 01 Dec 2023 21:15:59 +0000, Quadibloc wrote:
> On Wed, 29 Nov 2023 17:15:00 +0000, Quadibloc wrote:
>
>> I have now modified the 17-bit shift instructions in the diagram, so
>> that they can also apply to all 32 integer registers, and I have
>> corrected the opcodes on the page
>>
>> http://www.quadibloc.com/arch/cw0101.htm
>
> And now I have completed the process of getting back to where I was
> before,
> by adding in the page
>
> http://www.quadibloc.com/arch/cw0102.htm
>
> which describes the instructions longer than 32 bits.

Two further changes have been made.

On the first page of the description of the ISA, I have noted that
when VLIW features are used, indicating that instructions may be
executed in parallel must not change the result of a calculation,
since some implementations may ignore that directive.

On the page about 17-bit instructions, I have changed the format
of 128-bit floating-point numbers; instead of being a 128-bit version
of temporary real, with more significand bits, I've added one exponent
bit, subtracting one significand bit.

The reason for this is to allow, with a 130-bit internal form, the
*standard* 128-bit form for IEEE 754 floating-point numbers, which
does have a hidden first bit, to be supported.

In addition to having the sixteen even-numbered registers available for
such numbers, since 130 bits is so frustratingly shorter than 256 bits,
I also make the registers with numbers of the form 4n+1 available, using
the same scheme as I will use for 128-bit Decimal Floating Point in the
IBM format. Tweaked slightly to allow internal forms of up to 168 bits
instead of up to 160 bits.

John Savard

mitchalsup@aol.com (MitchAlsup) writes:
>Have any GBnOoO machines been successful ?

Great Big in-order machines (why write non-OoO?):

Multiflow has 7, 14, or 28 instructions per cycle, but of course its
target market is supercomputing, i.e., throughput computing, and at
the time the competition was pipelined SIMD (Cray etc.). Was it
successful? Probably not that much.

The 21164(a) is 4-wide, and was successful in its prime, but there was
no OoO competition at the time. When the Pentium Pro appeared at
200MHz, it took the SPECint95_base crown from the 300MHz 21164
<https://en.wikipedia.org/wiki/Alpha_21164#Performance>. Given that
it held SPECint and SPECfp performance crowns for some time, one can
consider it to be successful. Also, I think it was commercially
somewhat successful. The 21164 including the 21164a also had a much
longer lifespan than its predecessor, mainly due to the 21264 being
late.

The Larrabee (which eventually resulted in Knights Ferry) is a
two-wide in-order design, but with very wide (512-bit) SIMD units.
One probably cannot call it a success.

Since the victory of OoO, people mostly limited themselves to two-wide
in-order machines, probably because any more width is mostly wasted
given the limited amount of instruction-level parallelism within a
basic block. If people wanted more, they usually went to OoO (e.g.,
Bonnell->Silvermont, Knight's Ferry->Knight's Corner).

One exception is ARM, which stayed with in-order in A53, A55, A510,
A520, and switched from 2-wide to 3-wide in the A55->A510 transition,
but interestingly went from 3 to 2 ALUs in the A510->A520 transition
(but is still generally 3-wide).

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

"Paul A. Clayton" <paaronclayton@gmail.com> writes:
>A uniquely difficult architecture like x86 increases the barrier
>to competition both from patents and organizational knowledge and
>tools. While MIPS managed to suppress clones with its patent on
>unaligned loads (please correct any historical inaccuracy), Intel
>was better positioned to discourage software-compatible
>competition — and not just financially.

Really? There is software-compatible competition to Intel. Not so
much for MIPS (maybe Loongson).

>I suspect that the bad reputation of x86 among computer architects
>— especially with the biases from Computer Architecture: A
>Quantitative Approach which substantially informs computer
>architecture education

If you have looked at recent editions of this book, you would not
write that. They apparently have lost interest in discussing
instruction sets. The fifth edition from 2012 moves that discussion
to an appendix and I am not sure if a later edition has not removed it
from the printed book completely.

The discussion about OoO that I have looked at in some recent edition
seems to miss important points for latency-dominated computing. It
seems to me that the authors are mainly interested in supercomputing
these days, certainly the fifth edition looks that way.

If that's the book that biases computer architects, there is more to
worry about than just ISA. The supercomputer attitude is a mistake
that has been the bane of many architectures, even very well-funded
ones like IA-64.

>The binary lock-in advantage of x86 makes architectural changes
>more challenging. While something like the 8080 to 8086 "assembly
>compatible" transition might have been practical and long-term
>beneficial from an engineering perspective, from a business
>perspective such would validate binary translation, reducing the
>competitive barriers.

Actually while people who know nothing about instruction sets write
"x86", there are three different instruction sets on any recent Intel
or AMD CPU: 8086/286, IA-32, and AMD64. You cannot run IA-32 programs
in the same mode as AMD64 programs, just like ARM A32/T32 and ARM A64.

And while AFAIK you can switch between IA-32 and 8086 with two
user-mode bits (or prefixes), that usually does not happen. And the
addressing modes are actually very different; I bought a book that
claimed to cover CPUs up to the Pentium, but it actually did not cover
IA-32 addressing modes and instructions and therefore was totally
useless for me.

>(Itanium showed that mediocre hardware translation between x86 and
>a rather incompatible architecture (and microarchitecture) would
>have been problematic even if native Itanium code had competitive
>performance.

It seems to me that both hardware and software binary translation
would have fared much better on an OoO target CPU.

>On the other hand, ARM designed a 64-bit
>architecture that is only moderately compatible with the 32-bit
>architecture — flags being one example of compatibility

There is no compatibility at the ISA level. Using flags is a
similarity, not compatibility.

>MIPS (even with its delayed branches, lack of variable length
>encoding, etc.) would probably be a better architecture in 2023
>than x86 was around 2010.

As far as Gforth is concerned, MIPS is worse than every other
architecture that has architecture-specific support. Admittedly,
Gforth's requirements may not be that important to most, but all other
architectures satisfy them:

* Each instruction block between two branch targets stands on its own
and can be concatenated with any other such block, and perform the
effect of the first block followed by the effect of the second.
MIPS does not satisfy that because of load delay slots (and probably
also the scheduling limitations involving the multiply/division
unit).

* Direct branches are relative or absolute. MIPS has
not-quite-absolute branches that combine the top bits of the branch
address with the bottom bits coming from the instruction.

As a result, Gforth unconditionally disables dynamic native code
generation on MIPS; disabling dynamic native code generation costs a
factor 1.58-4.36 on Rocket Lake (numbers are times in seconds)

sieve bubble matrix fib fft
0.043 0.042 0.014 0.032 0.014 dynamic native code generation
0.068 0.077 0.061 0.082 0.032 --no-dynamic

There is too much supercomputer attitude in MIPS. Fortunately, its
successors Alpha and RISC-V have fixed both problems. And
interestingly, even a very supercomputer-attitude architecture like
IA-64 satisfies Gforth's requirements just fine.

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

Quadibloc <quadibloc@servername.invalid> writes:
>On Fri, 01 Dec 2023 22:10:39 +0000, Quadibloc wrote:
>> That's a very valid point, but any ISA for a "great big" machine can
>> have a subset which no longer requires a "great big" machine.
>
>Also, as you are well aware, Intel has included both "performance" and
>"efficiency" cores in its latest generations of CPUs, similar to the
>BIG.little architecture used for some ARM processors.

Which interestingly leads to recent Intel desktop and laptop CPUs not
supporting AVX-512, even on CPUs that have only the performance cores
enabled, even though the P-cores have AVX-512 implemented.

Likewise, big.LITTLE has led to ARM cores all only supporting
128-bit-wide SVE, because wider SVE would be too costly on the LITTLE
cores. It will be interesting to see what Apple does.

>Well, another way to address the efficiency/little cores being a
>waste of space would be to reduce the waste by making them smaller.
>If their purpose is to save power consumption when nobody's using the
>computer, to just keep the OS alive while it waits for the keyboard
>or the mouse to ask it to do something... then they should be made
>really little.

That's not their primary purpose, or there would only be one such
core. Intel has put 16 E-cores on Raptor Lake in order to be able to
boast 24 cores (more than AMD's desktop offering) and 32 threads (same
as AMD) total. And on tasks that can benefit from that many cores,
such as some benchmarks, they are actually quite beneficial.

ARM claims that their LITTLE in-order cores serve that purpose, but
then, why put 4 or more of them on a smartphone SoC? They are
certainly not more energy-efficient than the OoO brethren except at
their lowest performance point (and then not by much).

Apple uses OoO efficiency cores that are about as fast as a Cortex-A76
(in case of M1). Apparently they have no problem with using an OoO
core to "keep the OS alive while it waits"; given that modern cores
use very little power while they wait, that's not surprising.

>But in-order efficiency cores that are there when the demands are very
>low?

Intel runs the management engine on such a core, and AMD runs its
equivalent on several ARM cores, but these work outside of the realm
covered by the OS.

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

Anton Ertl wrote:
> "Paul A. Clayton" <paaronclayton@gmail.com> writes:
>
>> On the other hand, ARM designed a 64-bit
>> architecture that is only moderately compatible with the 32-bit
>> architecture — flags being one example of compatibility
>
> There is no compatibility at the ISA level. Using flags is a
> similarity, not compatibility.

I would say its compatibility because it allows A64 to emulate
A32 functional behavior with minimal overhead.
That could keep you customers from fleeing to other architectures.

On Sun, 03 Dec 2023 14:36:37 +0000, Anton Ertl wrote:

> mitchalsup@aol.com (MitchAlsup) writes:

> Great Big in-order machines (why write non-OoO?):

Of course, no doubt he was thinking of the Itanium, which was one
of the most resounding failures in recent years.

If one goes far enough back, of course, there's the IBM System/360
Model 85. Unlike the Model 91, it was in-order, yet it offered more
performance! This was because it had one thing the Model 91 didn't,
a cache.

The Model 85 was actually a failure for IBM in sales terms, but as
that was because of an economic slump at the time it came out, IBM
was not deterred from re-using the design, with a few additions and
tweaks, in the IBM System/370 Model 165 and 168 a few years later.
And those systems were quite successful.

I've already noted that an in-order version of a great big architecture
might make for nice lightweight efficiency cores in a BIG.little type
design. But making those cores in-order has another nice benefit.

No Spectre. No Meltdown. So, when the computer is actually active,
these cores, instead of being a total waste of space, could be put
to use as a ready-made sandbox for executing code sourced from the
Internet.

John Savard

Quadibloc wrote:

> On Sun, 03 Dec 2023 14:36:37 +0000, Anton Ertl wrote:

>> mitchalsup@aol.com (MitchAlsup) writes:

>> Great Big in-order machines (why write non-OoO?):

> Of course, no doubt he was thinking of the Itanium, which was one
> of the most resounding failures in recent years.

Itanic, Multiflow, i860, and now probably Mill.

> If one goes far enough back, of course, there's the IBM System/360
> Model 85. Unlike the Model 91, it was in-order, yet it offered more
> performance! This was because it had one thing the Model 91 didn't,
> a cache.

> The Model 85 was actually a failure for IBM in sales terms, but as
> that was because of an economic slump at the time it came out, IBM
> was not deterred from re-using the design, with a few additions and
> tweaks, in the IBM System/370 Model 165 and 168 a few years later.
> And those systems were quite successful.

Model 85 and 91 were combined into 195 but this still failed compared
to CDC 7600.

> I've already noted that an in-order version of a great big architecture
> might make for nice lightweight efficiency cores in a BIG.little type
> design. But making those cores in-order has another nice benefit.

When you deconstruct a GBOoO machine into a LBIO machine you invariably
loose issue width, which takes the pressure off {TLBs, Caches, Bus, ...}
the pipeline shrinks in stages, taking even more pressure off those.

> No Spectre. No Meltdown. So, when the computer is actually active,
> these cores, instead of being a total waste of space, could be put
> to use as a ready-made sandbox for executing code sourced from the
> Internet.

You CAN build Spectré-free, Melltdown-free, ROP-free,... in GBOoO
by following one simple rule:: No microarchitectural changes until
the causing instruction retires. AND you can do this without loosing
performance.

The existing camp of designs chooses not to.

> John Savard

On 12/3/2023 12:18 PM, MitchAlsup wrote:

snip

Is my assessment (interspersed below) of the effects of this correct?

> When you deconstruct a GBOoO machine into a LBIO machine you invariably
> loose issue width,

Which reduces performance

> which takes the pressure off {TLBs, Caches, Bus, ...}

Which allows savings in ports, etc., thus further reducing gate count,
thus chip size, thus cost.

> the pipeline shrinks in stages,

Which reduces the cost of mis-predicted branches, thus counterbalancing
"some" of the performance loss from eliminating OoO. Also, further
reduces gate count.

> taking even more pressure off those.

Overall, while the direction of the area/cost reduction, and performance
loss are clear, the magnitude of these is more difficult to predict
before actually doing it.

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

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Anton Ertl wrote:
>> There is no compatibility at the ISA level. Using flags is a
>> similarity, not compatibility.
>
>I would say its compatibility because it allows A64 to emulate
>A32 functional behavior with minimal overhead.

Emulation of A32 has not been relevant for quite a number of years,
because all cores that understood A64 also understood A32/T32. Of
course, implementing those cores was simplified by having the same
flags in the same order, but if there had been good reason, they could
just as well have built a data path hat produces both kinds of flags
(or, if they had decided to forego flags on A64, that implemented
flags just for A32/T32).

>That could keep you customers from fleeing to other architectures.

They kept customers by providing cores with both A64 and A32/T32.
Only now, many years later, are they removing A32/T32 from some of the
cores (but for now, not all of them); I guess the reason is that
customers are no longer asking for A32/T32 on all cores, and prefer
smaller (cheaper) and possibly more energy-efficient cores.

I think that this has also to do with the main target markets of ARM's
A64 implementations: Mobile phones running Android have are programmed
in high-level languages and can be easily recompiled; applications
written in Java are actually delivered in an architecture-neutral
distribution format, so switching to A64 is even easier. And software
running on ARM servers is often available in source form, so
recompiling it for A64 (if it was not delivered as A64 in the first
place) is easy.

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

On Sun, 03 Dec 2023 20:18:30 +0000, MitchAlsup wrote:

> Model 85 and 91 were combined into 195 but this still failed compared to
> CDC 7600.

I definitely remembered the Model 195.

Even if the CDC 7600 outsold it, though, in one way the Model 195 was
an enormous success. Its microarchitecture ended up being, in general
terms, copied by the Pentium Pro and the Pentium II.

So, today, all computers are made this way - OoO pipeline plus cache.

John Savard

Stephen Fuld wrote:

> On 12/3/2023 12:18 PM, MitchAlsup wrote:

> snip

> Is my assessment (interspersed below) of the effects of this correct?

>> When you deconstruct a GBOoO machine into a LBIO machine you invariably
>> loose issue width,

> Which reduces performance

>> which takes the pressure off {TLBs, Caches, Bus, ...}

> Which allows savings in ports, etc., thus further reducing gate count,
> thus chip size, thus cost.

>> the pipeline shrinks in stages,

> Which reduces the cost of mis-predicted branches, thus counterbalancing
> "some" of the performance loss from eliminating OoO. Also, further
> reduces gate count.

>> taking even more pressure off those.

> Overall, while the direction of the area/cost reduction, and performance
> loss are clear, the magnitude of these is more difficult to predict
> before actually doing it.

My last year at AMD ('06); I was working on a 1-wide x86-64, eXcel simulation
indicated ½ the performance at 1/12 the area and likely 1/10 the power.