On 2/17/2024 4:25 PM, John Levine wrote:
> According to Lawrence D'Oliveiro <ldo@nz.invalid>:
>> On Sat, 17 Feb 2024 11:41 +0000 (GMT Standard Time), John Dallman wrote:
>>
>>> But most of all,
>>> the design is based on the compilers being able to solve a problem that
>>> can't be solved in practice: static scheduling of memory loads in a
>>> system with multiple levels of cache.
>>
>> That seems insane. Since when did architectural specs dictate the levels
>> of cache you could have? Normally, that is an implementation detail, that
>> can vary between different instances of the same architecture.
>
> The point of VLIW was to schedule this stuff statically at compile
> time to make the best use of the memory architecture. It more or less
> worked in the 1980s but as memory architectures got more complex, and
> dynamic hardware scheduling got better, VLIW performance could never
> keep up.
>

Granted, this is why I am mostly speculating on its potential use had it
been deployed on low-end hardware (as opposed to the workstation/server
arena), where its main competitors would be more typically dual-issue
superscalar chips (rather than the OoO designs typically found at the
higher end).

Granted, it is possible that IA-64's ISA design might have made it too
heavyweight to be a viable competitor to something like a Cortex-A53 or
similar, in terms of cost (assuming both existing at the same time and
implemented on a similar ASIC process).

Say, how well IA-64 could perform if only given, say, 16K of L1I$ and
128K of L2 cache, ...

Granted, the large number of registers and bulky instructions are a
potential boat anchor in these areas.

A potential alternative would be something like a scaled-up 64-bit
variant of an ESP32 style design (or a 64-bit version of the Qualcomm
Hexagon).

Say, with these are "more proven" as viable in the microcontroller and
DSP spaces.

On Sat, 17 Feb 2024 17:17:09 -0600, BGB wrote:

> A potential alternative would be something like a scaled-up 64-bit
> variant of an ESP32 style design (or a 64-bit version of the Qualcomm
> Hexagon).

Would you end up with something similar to RISC-V?

On Sat, 17 Feb 2024 22:30 +0000 (GMT Standard Time), John Dallman wrote:

> To a modern understanding, it is insane.

I think that was already becoming apparent even before it finally shipped.

I think HP and Intel started the project around 1990, and it only reached
production quality by nearly the end of that decade. During that time,
RISC architectures continued to improve, with things like superscalar,
multiple function units and out-of-order execution--basically leaving
IA-64 in the dust before it could even ship.

I think it was only fear of loss of corporate face that kept the project
going when it became clear it should have been abandoned.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Sat, 17 Feb 2024 22:30 +0000 (GMT Standard Time), John Dallman wrote:
>
>> To a modern understanding, it is insane.
>
>I think that was already becoming apparent even before it finally shipped.
>
>I think HP and Intel started the project around 1990,

The HP and Intel didn't join forces on what became Itanium
until intel gave up on the P7 project in 1994.

BGB <cr88192@gmail.com> writes:
>On 2/17/2024 5:41 AM, John Dallman wrote:
>> The huge number of architectural registers (128 64-bit integer, 128
>> 82-bit floating point) would have made shrinks hard.

By the time the Itanium and Itanium II were delivered, not really. At
that time they already had the Pentium 4 with 128 physical integer
registers and 128 FP/SIMD registers
<https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2022/06/pentium4_65nm.drawio-1.png?w=905&ssl=1>
and the Pentium 4 was the bread-and-butter CPU for Intel; and if it
had been less power-hungry, it would also have been used for mobile.

>AFAIK:
>I think the idea was that they already had 100+ registers internally
>with their x86 chips (due to register renaming). And, the idea of having
>128 GPRs in the IA-64, was to eliminate the register renaming?...

No. The idea was that the IA-64 implementations would be ready in
1997, and that it would be superior in performance to the OoO
competition. That's also why they wanted to introduce it to the
market from the high end.

Another idea (and you see it in the IA-64 name that was later dropped
in favour of IPF, and in the IA-32 name that was invented around the
same time) was that in the transition to 64 bits, Intel's customers
would switch from IA-32 to IA-64, and of course that would happen on
servers and workstations first.

The reality was that IA-64 implementations were never generally
superior to the OoO competition. They were doing fine in HPC stuff,
but sucked in anything where performance is not dominated by simple
(software-pipelineable) loops.

>Except, if they could have made the chip both cheaper and faster than a
>corresponding OoO x86 chip.
>
>As I understand it, this was the promise of IA-64.

Yes. They just were not able to keep it. And the reason is that they
thought that scheduling in hardware is hard and inefficient, but it
turns out that branch prediction at compile time is so much worse than
hardware branch prediction at run-time that EPIC was not competetive
with OoO.

>It is like, if one looks at a Xeon, and then concludes that the Atom
>would have been impossible, because of how expensive and power hungry
>the Xeon is.

They wanted to produce superior performance by being wider than (they
thought) was practical for OoO: 6 wide for Merced and McKinley (later,
with Poulson, 12 wide). They did not produce superior performance,
and nowadays, the Cortex-X4 is 10-wide; and Golden Cove (Alder Lake
P-core) renames 6 instructions per cycle and at the same time
eliminates transitive moves and also transitive addition-by-constants.

>They could have made a chip, say, with only a tiny fraction as much
>cache, ...

Yes, they could have made a, say, 3-wide IA-64 implementation and
designed it for low power and low area. The result would have been
even slower than the implementations they actually produced. But of
course, given that they thought that their architecture would show its
strengths at wide designs, they certainly did not want to go there at
the start.

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

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Sat, 17 Feb 2024 18:08:36 GMT, Anton Ertl wrote:
>
>> One solution would be if MS finally switched to using Linux as the basis
>> for Windows.
>
>Once they brought a Linux kernel into Windows with WSL2, it seemed
>inevitable that they would rely on it more and more, until it became a
>mandatory part of a Windows install.

That's not what I mean. What I mean is to turn Windows into using the
Linux kernel rather than its current VMS-inspired kernel, and on top
of Linux provide a proprietary layer that provides the Win32 etc. ABIs
and APIs (what WINE is trying to do, but of course the WINE project
has neither the resources nor the authority of Microsoft). Similar to
Android.

The benefit for Windows-on-ARM would be that all those SoCs that
support by Android would also support Windows right away. The
disadvantage would be that this support might be just as bad and short
as for Android.

Thinking about it again, the proprietary-binary driver model of
Windows fits the tastes of these SoC manufacturers better than the
free source-level driver model of Linux, so once Windows-on-ARM
actually sells a significant number of SoCs, the SoC manufacturers
will happily provide such drivers.

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

BGB <cr88192@gmail.com> writes:
>Say, how well IA-64 could perform if only given, say, 16K of L1I$ and
>128K of L2 cache, ...

Itanium (Merced) has 16KB I-cache and 96KB L2 cache.

Itanium 2 (McKinley) has 16KB I-cache and 256KB L2 cache.

They both have L3 caches.

But these CPUs actually do fine (for their time) on HPC-style stuff,
so the cache sizes are not the main problem. They perform badly at
code where the compiler cannot predict the branches well, even on
code that tends to perform well with small caches.

Of course, the Cortex-A53 and Bonnell also performs badly, for the
same reason, and Intel learned the lesson and replaced the in-order
Bonnell with the OoO line beginning with Silvermont, and up to the
recent Gracemont (Alder Lake E-core). Apple also went for OoO
E-cores. Only ARM is sticking to in-order cores.

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

scott@slp53.sl.home (Scott Lurndal) writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>On Fri, 16 Feb 2024 23:38:03 +0000, MitchAlsup wrote:
>
>>Given the choice of an ARM-based system with some SoC-specific kernel
>>that is only supported for a few years
>
>That's a false choice. See ARM BSA and SBSA.

Ok, I found "ARM Base System Architecture" and "Server Base System
Architecture". What I have not found (and I doubt that I will find it
there) is a mainline Linux kernel that runs on our Odroid N2 (SoC:
Amlogic S922X) and where perf stat produces results. I doubt that I
will find such a kernel in BSA or SBSA. By contrast, that's something
that our complete arsenal of machines with the AMD64 architecture
manages just fine. And that's just one thing.

For a more mainstream problem, installing a new kernel on an AMD64 PC
works the same way across the whole platform (well, UEFI introduced
some excitement and problems, but for the earler machines, and the
ones from after the first years of UEFI, this went smooth). By
contrast, for the ARM-based SoCs, I have to read up about the Do!s and
Don't!s for the Uboot for this particular SoC; I don't have time for
this nonsense, so I don't remember what the specific issues are, only
that there is quite a bit of uncertainty involved.

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

jgd@cix.co.uk (John Dallman) writes:
>And they didn't start publicising it until 1998, IIRC.

Well, according to ZDNet
<https://web.archive.org/web/20080209211056/http://news.zdnet.com/2100-9584-5984747.html>,
Intel and HP announced their collaboration in 1994, and revealed more
details in 1997. I find postings about IA64 in my archive from 1997,
but I remember reading stuff about it with no details for several
years. I posted my short review of the architecture in October 1999
<https://www.complang.tuwien.ac.at/anton/ia-64-1999.txt>, so by that
time the architecture specification had already been published.

>If they thought it
>wasn't going to work, they could have quietly cancelled it.

After the 1994 announcement, some people might have asked at one point
what become of the project, but yes.

>It seems to have been a result of groupthink that got established, rather
>than face-saving.

Yes.

>It was moderately convincing at the time; it took me a
>fair while to abandon the intuitive reaction that it ought to be very
>fast, and accept that measurement were the only true knowledge.

I certainly thought at the time that they were on the right track.
Everything we knew about the success of RISC in the 1980s and about
the difficulties of getting more instruction-level parallelism in the
early 1990s suggested that EPIC would be a good idea.

The worrying thing is that a few decades later, these ideas are still
so seductive, and the reasons of why they OoO+SIMD worked out better
are still so little-known that people still think that EPIC (and their
incarnations IA-64 and Transmeta) are basically good ideas that just
had some marketing mistake (e.g., in this thread), or just would need
a few more good ideas (e.g., the Mill with its belt rather than
rotating register files).

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

jgd@cix.co.uk (John Dallman) writes:
>In article <qOcAN.65951$6ePe.26632@fx42.iad>, scott@slp53.sl.home (Scott
>Lurndal) wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> >I think HP and Intel started the project around 1990,
>> The HP and Intel didn't join forces on what became Itanium
>> until intel gave up on the P7 project in 1994.
>
>And they didn't start publicising it until 1998, IIRC. If they thought it
>wasn't going to work, they could have quietly cancelled it.

I was at SGI in 1998, when some of SGI's compiler technology was
being considered for Merced.
>
>It seems to have been a result of groupthink that got established, rather
>than face-saving. It was moderately convincing at the time; it took me a
>fair while to abandon the intuitive reaction that it ought to be very
>fast, and accept that measurement were the only true knowledge.

While that's fair, I'd suggest that there haven't been many successes
in the industry when attempting radical new architectures (Cray aside).

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>On Fri, 16 Feb 2024 23:38:03 +0000, MitchAlsup wrote:
>>
>>>Given the choice of an ARM-based system with some SoC-specific kernel
>>>that is only supported for a few years
>>
>>That's a false choice. See ARM BSA and SBSA.
>
>Ok, I found "ARM Base System Architecture" and "Server Base System
>Architecture". What I have not found (and I doubt that I will find it
>there) is a mainline Linux kernel that runs on our Odroid N2 (SoC:
>Amlogic S922X) and where perf stat produces results.

Does the Odriod N2 claim compliance to the BSA?

(It won't claim the SBSA, since it's not a server).

All the major OS vendors participate in the SBSA, and all
work properly on SBSA-compliant ARMv8/v9 systems, provided
drivers for proprietary hardware are available upstream
in the linux tree (something high-end SoC customers usually require).

> I doubt that I
>will find such a kernel in BSA or SBSA. By contrast, that's something
>that our complete arsenal of machines with the AMD64 architecture
>manages just fine. And that's just one thing.
>
>For a more mainstream problem, installing a new kernel on an AMD64 PC
>works the same way across the whole platform (well, UEFI introduced
>some excitement and problems, but for the earler machines, and the
>ones from after the first years of UEFI, this went smooth).

All of our ARMv8 SoC's support either UEFI or uboot, it's up
to the customer to choose which to use based on their
requirements.

scott@slp53.sl.home (Scott Lurndal) writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>>On Fri, 16 Feb 2024 23:38:03 +0000, MitchAlsup wrote:
>>>
>>>>Given the choice of an ARM-based system with some SoC-specific kernel
>>>>that is only supported for a few years
>>>
>>>That's a false choice. See ARM BSA and SBSA.
>>
>>Ok, I found "ARM Base System Architecture" and "Server Base System
>>Architecture". What I have not found (and I doubt that I will find it
>>there) is a mainline Linux kernel that runs on our Odroid N2 (SoC:
>>Amlogic S922X) and where perf stat produces results.
>
>Does the Odriod N2 claim compliance to the BSA?

I have no idea.

>All the major OS vendors participate in the SBSA, and all
>work properly on SBSA-compliant ARMv8/v9 systems, provided
>drivers for proprietary hardware are available upstream
>in the linux tree (something high-end SoC customers usually require).

So the BSA label, if present, tells me that the SoC is supported by
mainline Linux. Unfortunately, most SoCs are not supported by
mainline Linux, because apparently significant hardware on the SoC is
supported only by some driver that sits on some forked Linux without
being upstreamed. And that's what results in smartphones with these
SoCs eventually not being able to get security updates.

As for high-end, I doubt that the SoC on a EUR 100 SBC meets that
description. But I don't think I will find a high-end SoC with a
Cortex-A73, much less in an SBC with support for a GNU/Linux
distribution rather than some Android system.

Overall, there are not that many SBCs around, and even fewer SoCs that
are used in them. The Rockchip SoCs we have used (RK3399, RK3588)
seem to be better supported than the Amlogic ones (S905, S922X). The
Raspis, when they eventually arrive, have good support, but they tend
to be quite late. E.g., we have had the Rock5B (with RK3588,
Cortex-A76s and A55s) for IIRC more than half a year before any word
about the Raspi5 (with a SoC with A76 cores) reached me. The bottom
line is that, for measuring how the A73 performs, the Odroid N2(+) is
the only game in town.

>>For a more mainstream problem, installing a new kernel on an AMD64 PC
>>works the same way across the whole platform (well, UEFI introduced
>>some excitement and problems, but for the earler machines, and the
>>ones from after the first years of UEFI, this went smooth).
>
>All of our ARMv8 SoC's support either UEFI or uboot, it's up
>to the customer to choose which to use based on their
>requirements.

Yes, I have seen uboot stuff in the documentation of the SBCs we use.
But the instructions for upgrading to a new kernel on these SBCs are
worrying.

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

On Sun, 18 Feb 2024 08:59:45 GMT, Anton Ertl wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>>On Sat, 17 Feb 2024 18:08:36 GMT, Anton Ertl wrote:
>>
>>> One solution would be if MS finally switched to using Linux as the
>>> basis for Windows.
>>
>>Once they brought a Linux kernel into Windows with WSL2, it seemed
>>inevitable that they would rely on it more and more, until it became a
>>mandatory part of a Windows install.
>
> That's not what I mean. What I mean is to turn Windows into using the
> Linux kernel rather than its current VMS-inspired kernel ...

That is the next step. It would be the path of least resistance to
implement new functionality on the Linux side, and let the Windows kernel
wither away.

On Sun, 18 Feb 2024 08:59 +0000 (GMT Standard Time), John Dallman wrote:

> And they didn't start publicising it until 1998, IIRC. If they thought
> it wasn't going to work, they could have quietly cancelled it.

I certainly heard about it before then. As I understood it, things went
quiet because it was taking longer than expected to make it all work. But
there were obviously those sufficiently high up in the management chain
who were determined not to be proven wrong. Otherwise, it could have been
cancelled.

On Sun, 18 Feb 2024 11:50:49 GMT, Anton Ertl wrote:

> The worrying thing is that a few decades later, these ideas are still so
> seductive, and the reasons of why they OoO+SIMD worked out better are
> still so little-known that people still think that EPIC (and their
> incarnations IA-64 and Transmeta) are basically good ideas that just had
> some marketing mistake ...

The equivalent on the software wide would be microkernels--again, there
are those who still think they can be made to work efficiently, in spite
of mounting evidence to the contrary.

Also, SIMD, while very fashionable nowadays, with its combinatorial
explosion in the number of added instructions, does tend to make a mockery
of the “R” in “RISC”. That’s why RISC-V is resurrecting the old Cray-style
long vectors instead.

On Sun, 18 Feb 2024 16:16:10 GMT, Scott Lurndal wrote:

> ... I'd suggest that there haven't been many successes in
> the industry when attempting radical new architectures (Cray aside).

Risky ideas are risky ...

After he left CDC, one might say Seymour Cray’s only real success was the
Cray-1. Not sure if the Cray-2 made much money, and the 3 and 4 didn’t
even make it into regular production.

Lawrence D'Oliveiro wrote:

> On Sun, 18 Feb 2024 16:16:10 GMT, Scott Lurndal wrote:

>> ... I'd suggest that there haven't been many successes in
>> the industry when attempting radical new architectures (Cray aside).

> Risky ideas are risky ...

> After he left CDC, one might say Seymour Cray’s only real success was the
> Cray-1. Not sure if the Cray-2 made much money, and the 3 and 4 didn’t
> even make it into regular production.

Seymour's talent was in packaging not in computer architecture.
Thornton was the computer µarchitect of the group.

Lawrence D'Oliveiro wrote:

> On Sun, 18 Feb 2024 11:50:49 GMT, Anton Ertl wrote:

>> The worrying thing is that a few decades later, these ideas are still so
>> seductive, and the reasons of why they OoO+SIMD worked out better are
>> still so little-known that people still think that EPIC (and their
>> incarnations IA-64 and Transmeta) are basically good ideas that just had
>> some marketing mistake ...

> The equivalent on the software wide would be microkernels--again, there
> are those who still think they can be made to work efficiently, in spite
> of mounting evidence to the contrary.

When context switches take 1,000+ cycles but CALL/RET only take 5, µKernels
will never succeed. {That is a full context switch including ASID, IP, ROOT
pointers, complete register file, and all associated thread-state.}

µKernels can only succeed when context switch times are similar with CALL/RET.
Otherwise the performance requirements will end up dictating monolithic design.

> Also, SIMD, while very fashionable nowadays, with its combinatorial
> explosion in the number of added instructions, does tend to make a mockery
> of the “R” in “RISC”. That’s why RISC-V is resurrecting the old Cray-style
> long vectors instead.

Which is my point over the last ~year~ to stress that the R in RISC needs to
actually mean REDUCED. {{Any ISA with more than 200 instructions cannot be
called RISC.}}

On 2/17/2024 6:24 PM, Lawrence D'Oliveiro wrote:
> On Sat, 17 Feb 2024 17:17:09 -0600, BGB wrote:
>
>> A potential alternative would be something like a scaled-up 64-bit
>> variant of an ESP32 style design (or a 64-bit version of the Qualcomm
>> Hexagon).
>
> Would you end up with something similar to RISC-V?

Well, like RISC-V with explicitly parallel instructions (rather than
implicitly via superscalar).

Both ESP32 and Hexagon had used instruction words that could be tagged
to execute in parallel. RISC-V doesn't do this, so the CPU would need to
look at the instructions (and check for register conflicts), before
deciding to do so. For a cost-effective implementation, this logic is
necessarily conservative.

Or, something like my own BJX2 ISA, but it seems, it isn't *that* far
from RISC-V in some areas, and trying to support both in the same CPU
core has led to some amount of convergence (many cases where RV64 had a
feature, but BJX2 lacked a corresponding feature, has resulted in BJX2
gaining the feature in question, albeit often slightly modified; as the
mechanisms often don't demand that exactly the same instruction be
implemented in exactly the same way).

Say, for example, GT and LT are mirrors of each other, immediate size
and encoding matters a lot to the decoder but is mostly ephemeral to the
execute stage logic, etc...

Well, and some major features, such as the presence or absence of ALU
status flags, didn't matter as neither ISA uses ALU status flags.

In my case, SR.T doesn't really count in my case, as it is used almost
exclusively as a predication-control flag. If I were to do a new ISA
with a similar design, likely SR.T would be made exclusively for
predication control, and I would find some other way to do "ADD with
Carry" and similar.

In my case, there are 1/4 as many hardware registers as IA-64, and 1/3
as would be needed for the RISC-V Privileged spec.

Though, would still face the potential issue that WEX (Wide-EXecute)
eats some amount of encoding space, and on a "good" superscalar
implementation, or with OoO, its existence would become mostly moot (it
mostly mattering for cores in the area of too cheap to do superscalar
effectively, but expensive enough to justify being able to execute
instructions in parallel, if the compiler helps them out).

Looks like scaling this up past a width of 2 or 3 becomes mostly no-go,
and say a core with 4+ lanes would almost invariably need to be OoO.

Say, the cost of the Execute stages goes up steadily, but the ability of
the compiler to static schedule things becomes steadily less effective
(seemingly doesn't really work much past 3-wide and a naive
strictly-in-order pipeline).

In practice, this part of the space seems to be mostly dominated by
higher-end microcontrollers, and DSPs (with non-budget "application
class" chips and above mostly going over to OoO).

Meanwhile, the low-end of the microcontroller space tends to be
dominated by 8/16 bit scalar processors, and this probably isn't going
to change anytime quickly (like, if you don't need more than a 16-bit
ALU and 2K of RAM, why go for anything bigger?...).

Like, the processing requirements for keyboards and mice hasn't changed
much (and the main thing they mostly need to deal with is the needless
complexity of the USB protocol).

In my case:

The gains of 3 wide over 2 are small; and main reasons it is 3-wide in
my case is because if I am already needing to pay for 96-bit decode and
a 6R3W register file to get full advantage of the 2-wide case, the
nominal cost increase of a 3rd ALU and similar is low).

Though, did save the cost of eliminating Lane3 integer shift, since
Lane3 integer shift is rare and the integer shift logic isn't cheap (at
least, vs ADD/SUB/AND/OR/XOR, and MOV/EXTS/EXTU). Like, Lane3 existing
mostly for spare register ports and the occasional MOV or ALU op.

Granted, my compiler's strategy is fairly naive:
First emit code as-if it were a plain RISC style ISA;
Feed it through a stage that tries to shuffle and bundle instructions.
Shuffle first to try to untangle RAW dependencies;
Bundle to try to increase ILP;
Though, typically increases the number of RAW dependencies.

Code which is has a big pile of mostly independent operations tends to
do better here (and code with a lots of parallel expressions and lots of
variables, seems to be an area where my ISA is beating RISC-V).

Note that for code with "small tight loops", it is a lot closer, and in
some cases, this is an area where some of RISC-V's design choices make
more sense.

For example, the use of 2-register compare-and-branch operations, are in
general kind of expensive, but seem to be useful in some cases with
tightly running loops:
while(cs<cse)
*ct++=*cs++;

But, in terms of facing off against RISC-V in terms of performance, I
have ended up partly re-evaluating them.

And, in the case of tight loops, even the limitation in my case of them
only having an 8-bit displacement, is less of an issue:
XG2:
BRLT Rm, Rn, Disp8s //Branch if Rn<Rm, +/- 256B
BRLT Rn, Disp13s //Branch if Rn< 0, +/- 8K
CMPGT Rn, Rm; BT Disp23s //Branch if Rm>Rn, +/- 8MB
Baseline:
BRLT Rm, Rn, Disp8s //Branch if Rn<Rm, +/- 256B
BRLT Rn, Disp11s //Branch if Rn< 0, +/- 2K
CMPGT Rn, Rm; BT Disp20s //Branch if Rm>Rn, +/- 1MB

If the loop is tight, then the branch target is much more likely to be
within the 256 byte window (well, and if the CPU has the RV decoder; it
already needs to pay for the EX logic needed to support this
instruction). So, it is more an open question of "is it worthwhile to
have this instruction in a CPU that doesn't have a RISC-V decoder?".

But, looks like, "for best performance", it may be inescapable.
For the 32-bit encoding, displacement doesn't get any bigger, but it is
possible to use a jumbo-encoding to expand it to a 32-bit displacement.

Main weak points on the RV side are still the usual:
Lack of indexed load/store;
Poor handling of constants that don't fit in 12 bits.

So, say, Imm12s for ALU ops is arguably better than Imm9u/Imm9n/Imm10s
(or Imm10u/Imm10n/Imm11s), but not by enough to offset the ISA
effectively falling on its face when Imm12s fails.
Could be helped though if RV added a "LI Xd, Imm17s" instruction.

The "SHnADD" can instruction can help with indexed Load/Store, but would
not entirely "close the gap" for programs like Doom or similar (may or
may not make a difference for Dhrystone, where things are pretty tight,
but seemingly much of this is due to a relative lack of array-oriented
code in Dhrystone, so SHnADD would, similarly, not gain so much here).

But, yeah, higher priorities, if I were to redo things:
Put GBR and LR into GPR space;
Having these in CR space negatively effects prologs and epilogs;
Make encoding rules more consistent;
...

As noted, some of my ideas would make the first 4 registers special:
R0: ZR / PC
R1: LR / TBR (TP)
R2: SP
R3: GBR (GP)

But, likely keep similar register assignments to my existing ISA (but,
unlike my existing register space, could also be directly compatible
with the RISC-V ABI; without something like the existing XG2RV hack).
Putting LR and GBR in GPR space would help with prolog/epilog sequences;
A zero register would eliminate a lot of special cases.

But, this is not compatible with my existing ABI.
Where R2/R3 are used by the existing ABI, and R15 is SP.

But, unclear if it would be worthwhile, since any "redo" would still
have many of my existing issues, and is possibly moot *unless* it can
also either have a significant performance advantage over both RISC-V
and my existing ISA design, or if I instead switched over to RISC-V as
the primary ISA (and implemented the privileged spec) to potentially
leverage the ability to run an existing OS (such as Linux).

But, this latter point would likely only really matter if I found
detailed documentation, say, on SiFive's memory map and hardware
interfaces, and also cloned this (otherwise, a custom CPU core still
isn't going to be able to run an "off the shelf" Linux build; even if
the ISA itself matches up).

Though, a more intermediate option might just be to consider eliminating
the Read-Only pages range (from 0x00010000..0x00FFFFFF), and instead
moving this over to RAM (with 00000000..0000BFFF as ROM, and
0000C000..0000FFFF as SRAM), which would make the hardware memory map
more compatible with what GCC expects (though, would need to take care
such that loading the kernel doesn't stomp the Video RAM or similar,
which had otherwise been mapped into this "hidden" part of the RAM space).

Well, and any OS porting attempts needing to deal with things like the
different hardware interfaces and different approaches to interrupt
handling and similar (this more effects ones' ASM code)

But, I guess, one limitation seems to be:
Vs the existing ISA's, there is little real way to gain much additional
performance for normal integer workloads (at the ISA level);
Similarly, not much obvious way to either make the core significantly
cheaper, nor to make significant gains in terms of clock-speed via ISA
level design choices.

On Sun, 18 Feb 2024 21:41:55 +0000, MitchAlsup1 wrote:

> Seymour's talent was in packaging not in computer architecture.

Bit unlikely, considering his supers didn’t use any very fancy packaging
techniques at all.

On 2/18/2024 3:08 PM, Lawrence D'Oliveiro wrote:
> On Sun, 18 Feb 2024 11:50:49 GMT, Anton Ertl wrote:
>
>> The worrying thing is that a few decades later, these ideas are still so
>> seductive, and the reasons of why they OoO+SIMD worked out better are
>> still so little-known that people still think that EPIC (and their
>> incarnations IA-64 and Transmeta) are basically good ideas that just had
>> some marketing mistake ...
>
> The equivalent on the software wide would be microkernels--again, there
> are those who still think they can be made to work efficiently, in spite
> of mounting evidence to the contrary.
>

I suspect it is relative costs:
System call vs task switch;
Number of calls or task switches needed for a request;
...

Say:
Monolithic kernel:
OS request is 1 syscall.
Microkernel:
OS request is (2n)^d context switches.

Say, if a file IO request is handled directly by a system call, this is
faster than if one context switches to a VFS, then to the FS driver,
then to the block-device driver, and then all the way back up the path.

Hybrid approaches can work, say, where normal memory and filesystem
calls are handled by the kernel, but things like GUI can be handled with
IPC calls.

Granted, none of the mainstream OS's run the GUI directly in the kernel,
so this may not not be a factor.

> Also, SIMD, while very fashionable nowadays, with its combinatorial
> explosion in the number of added instructions, does tend to make a mockery
> of the “R” in “RISC”. That’s why RISC-V is resurrecting the old Cray-style
> long vectors instead.

This is partly why I say, it can be done, but preferably to go down the
"x" path, and not the "x^2" path.

NEON and the RISC-V 'P' extension are examples of what happens if one
goes head-first into the x^2 path...

Though, I suspect a partial reason why seemingly no one seriously
promotes the 'P' extension is that it is fairly obvious that this is
most likely unworkable.

On Sun, 18 Feb 2024 18:13:42 -0600, BGB wrote:

> ... things like GUI can be handled with IPC calls.

Which is how X11 and Wayland do it. The bottleneck is in the user response
time, so the overhead of message-passing calls is insignificant.

> Granted, none of the mainstream OS's run the GUI directly in the kernel,
> so this may not not be a factor.

Both Microsoft and Apple do tie their GUIs quite inextricably into the OS
kernel. That’s why you can’t customize them--at least, not in any easy way
that doesn’t threaten the stability of the system.

Anton Ertl wrote:

> jgd@cix.co.uk (John Dallman) writes:
>>And they didn't start publicising it until 1998, IIRC.

> Well, according to ZDNet
> <https://web.archive.org/web/20080209211056/http://news.zdnet.com/2100-9584-5984747.html>,
> Intel and HP announced their collaboration in 1994, and revealed more
> details in 1997. I find postings about IA64 in my archive from 1997,
> but I remember reading stuff about it with no details for several
> years. I posted my short review of the architecture in October 1999
> <https://www.complang.tuwien.ac.at/anton/ia-64-1999.txt>, so by that
> time the architecture specification had already been published.

>>If they thought it
>>wasn't going to work, they could have quietly cancelled it.

> After the 1994 announcement, some people might have asked at one point
> what become of the project, but yes.

>>It seems to have been a result of groupthink that got established, rather
>>than face-saving.

> Yes.

>>It was moderately convincing at the time; it took me a
>>fair while to abandon the intuitive reaction that it ought to be very
>>fast, and accept that measurement were the only true knowledge.

> I certainly thought at the time that they were on the right track.

In 1991 when I first heard of what became Itanic while designing a 6-wide
GBOoO machine; we had a quick look-see and came to the conclusion it was
doomed from the start.

> Everything we knew about the success of RISC in the 1980s and about
> the difficulties of getting more instruction-level parallelism in the
> early 1990s suggested that EPIC would be a good idea.

We came to the opposite conclusion.

> The worrying thing is that a few decades later, these ideas are still
> so seductive, and the reasons of why they OoO+SIMD worked out better
> are still so little-known that people still think that EPIC (and their
> incarnations IA-64 and Transmeta) are basically good ideas that just
> had some marketing mistake (e.g., in this thread), or just would need
> a few more good ideas (e.g., the Mill with its belt rather than
> rotating register files).

> - anton

On Mon, 19 Feb 2024 02:42:17 +0000, MitchAlsup1 wrote:

> We came to the opposite conclusion.

As they say, hindsight is 6/6.

On 2/18/2024 8:13 PM, Lawrence D'Oliveiro wrote:
> On Sun, 18 Feb 2024 18:13:42 -0600, BGB wrote:
>
>> ... things like GUI can be handled with IPC calls.
>
> Which is how X11 and Wayland do it. The bottleneck is in the user response
> time, so the overhead of message-passing calls is insignificant.
>

IIRC, X11 had worked by passing message buffers over Unix sockets (with
Xlib as a wrapper interface over the socket-level interface).

These sockets apparently used a datagram based structure, similar to
UDP, except that message delivery was reliable and order preserving
(whereas UDP could deliver messages out of order, duplicated, or not at
all).

Though, admittedly, haven't looked in too much detail as to how the X11
protocol's messaging worked, as I didn't want to go this direction
(seemed like a needlessly high overhead way to approach a GUI).

In my experimental GUI API used in TestKern (also used for full-screen
display as well), it instead maps a COM Object style interface over
system calls.

IIRC, Syscall Numbers:
1000..11FF: Plain Syscall
1200..13FF: Method Number (IPC Object)

When a method number is given, an object is supplied which receives the
method call, and may be redirected to the task containing the exported
object. There are two sub-variants of the mechanism, one where the
object on the client is merely a placeholder stub, and the actual object
only exists in the target task; and another variant where the object is
shared with the client task, but method calls (from any other task) will
redirect to the owning task.

The former type was used for TKGDI, whereas the latter was used for
TKRA-GL's OpenGL context.

There was an idea that any task could export an object (spawning an
appropriate handler task for the object's interface), but this part
isn't implemented as of yet (so, TKGDI and TKRA-GL exist mostly as
kernel-tasks).

Generally, exported interfaces would be identified by one of:
A pair of FOURCC or EIGHTCC values (general idea is that FOURCC values
exist by being zero-extended to 64 bits);
A 128-bit GUID, effectively using the EIGHTCC pair as a GUID (it is
possible to distinguish between the FOURCC, EIGHTCC, and GUID values,
mostly by looking at the bit-pattern in the pair of 64-bit values).

Where, the idea is that "public" interfaces would be described using
FOURCC or EIGHTCC values, and "private" interfaces and object instances
would use GUIDs.

Though, more work is still needed in these areas.

The existing implementation is a bit hacky and a bunch of stuff is still
hard-coded (say, requests for interfaces are routed directly, rather
than be registering an interface object and directing interface queries
through the registered interfaces, ...).

There is also a distinction between "local" and "global" memory, where
only global memory will necessarily be visible from other tasks.

Though, the model in this case is more like, every time a program
allocates memory with "GlobalAlloc", it is like it is a shared-memory
object that is simultaneously mapped to the same address in every
process on the system.

In this case, there would be separate address ranges for process-local
memory, say:
0000_00000000..3FFF_FFFFFFFF: Global
4000_00000000..7FFF_FFFFFFFF: Local
8000_00000000..BFFF_FFFFFFFF: System (Supervisor Mode, Memory)
C000_00000000..FFFF_FFFFFFFF: Special (Supervisor Mode, Hardware)
C000_00000000..CFFF_FFFFFFFF: No MMU, Cached
D000_00000000..DFFF_FFFFFFFF: No MMU, No-Cache
E000_00000000..EFFF_FFFFFFFF: Reserved
F000_00000000..FFFF_FFFFFFFF: MMIO

>> Granted, none of the mainstream OS's run the GUI directly in the kernel,
>> so this may not not be a factor.
>
> Both Microsoft and Apple do tie their GUIs quite inextricably into the OS
> kernel. That’s why you can’t customize them--at least, not in any easy way
> that doesn’t threaten the stability of the system.

AFAIK, Windows runs its GUI via service processes and IPC, rather than
by having the GUI as part of the kernel itself.

Apparently, there was a thing early on in the WinNT line where they
didn't want to have graphics drivers running in kernel space either, but
eventually folded on this one as apparently trying to run the graphics
drivers in a user-space process was unacceptable in terms of performance.

Though, still it is more tightly coupled than, say, the X11 Server,
which ran as a userspace process, with the window manager as another
process, ...

But, I guess I can contrast both of them with my project, where
effectively the existing GUI is part of the kernel, just forked off into
a kernel task (along with the systemcall handler task, ...).

....