On Tuesday, June 1, 2021 at 6:51:46 PM UTC-5, Quadibloc wrote:
> On Monday, May 31, 2021 at 11:47:20 PM UTC-6, Quadibloc wrote:
> > On Monday, May 31, 2021 at 5:46:49 PM UTC-6, MitchAlsup wrote:
>
> > > The flavor with both registers and displacement is only used on the
> > > order of 2% of the time.
>
> > Well, that may be. But I have a basic goal of allowing code to be
> > produced that is as functional, and as dense, as that of the IBM
> > System/360.
<
S/360 did not have "all that good" code density partially due to 12-bit displacements
and base register addressing for everything. In order to even branch within a sub-
routine, one has to get a hold of the PC using a BALR instruction to the next instruction.
If the subroutine is bigger that 4096 bytes, you may have to do this more than once.
......
<
> So, the idea is:
>
> A register-to-register arithmetic instruction takes only 16 bits on the IBM 360!
>
> Well, all right, there are 16-bit register-to-register instructions on this architecture,
> although they come with certain restrictions those on the 360 don't have.
>
> Memory-reference instructions with full base-index addressing take only 32 bits
> on the IBM 360!
<
Make that Rd,[base+index+disp12] in a single 32-bit instruction. RX format.
>
> Load and store instructions with full base-index addressing are provided in this
> architecture, despite the fact that register banks have 32 registers instead of 15,
<
16 int registers 4 FP.
<
> and a 16-bit displacement (to match that used on the 68000 and many other modern
> architectures) instead of a 12-bit displacement is used.
>
> Aside from only allowing load and store instructions, other restrictions include having
> only seven possible index registers instead of fifteen, only seven possible base registers
<
S.E.L. (n.e., Gould) used this same idea, which did not work out as well as it should have.
<
> instead of fifteen, and only allowing the addresses of aligned operands to be specified
> (a trick, used on the SEL 32 minicomputer is used to allow this limitation to provide additional
> opcode space).
<
The trick, for the uninitiated, was that when you know data has to be aligned, the lower
order bits of the displacement have to be zeros, so you can "encode" stuff using these bits.
>
> There's also an extended mode, which allows only seven instruction slots instead of eight
> per 256-bit block. In that mode, some restrictions are lifted.
>
> Load and store instructions no longer are limited to only aligned operands.
<
A misaligned memory model simply works better than the aligned only memory model:
and the HW cost is low enough that this is the only sensible choice these days.
>
> Memory-reference operate instructions (for the most common and standard arithmetic
> operations) are provided. These are restricted to aligned operands, and they also have an
> additional restriction, in that the form with 16-bit displacements is not available.
>
> In addition to the seven of the general registers which may be used as base registers
> with 16-bit displacements, one register may also be used as the base register for a 15-bit
> displacement, and another seven registers may be used as base registers with 12-bit
> displacements. The remaining modes when the one with 16-bit displacements is removed
> are available for these instructions.
>
> And the extended mode also provides for instructions like the string and packed-decimal
> instructions of the 360. These have a 48-bit form which matches the length of the corresponding
> System/360 instructions, but which has the restriction that 16-bit displacements are not
> available, and they also have a 64-bit form which does allow 16-bit displacements, and
> even indexing.
>
> Attempting to approach the instruction density of the System/360 may seem like a fairly
> useless goal in itself, except possibly for marketing purposes, but attention has _also_
> been paid to minimizing the overhead impacts of meeting that goal. So effort may have been
> apparently wasted in keeping some rare instructions short, but this has not led to more common
> instructions becoming *longer*.
>
> John Savard

On Tuesday, June 1, 2021 at 6:10:40 PM UTC-6, MitchAlsup wrote:

> S/360 did not have "all that good" code density partially due to 12-bit displacements
> and base register addressing for everything. In order to even branch within a sub-
> routine, one has to get a hold of the PC using a BALR instruction to the next instruction.
> If the subroutine is bigger that 4096 bytes, you may have to do this more than once.

Well, if its code density is not all that good, that's a good reason not to do even worse!

But I thought if a subroutine is bigger than 4,096 bytes, you use one BALR instruction,
and just fill several base registers with BASE, BASE+4,096, BASE+8,192 and so on.
After all, if you have any forwards branches, it would be too late for another BALR
when you cross the boundary...

> > Load and store instructions no longer are limited to only aligned operands.

> A misaligned memory model simply works better than the aligned only memory model:
> and the HW cost is low enough that this is the only sensible choice these days.

Which is _why_ I rush to provide load and store instructions without an alignment
requirement in the 'enhanced' mode, which has a low overhead cost.

For many computations, one can get by with only aligned operands. The ability to
use an unaligned operand doesn't bring any benefits. But when it is needed, the
instructions with that ability are easily available.

So it isn't as if I'm offering an "aligned-only memory model", I'm just using the SEL
trick to increase code density, but operations on unaligned operands are an
easily-accessible option.

Of course, an assembler that doesn't require the programmer to keep track of
when a program crosses a block boundary will be complex, as it will have to process
up to eight instructions at a time before deciding what format of block to generate.

To me, _that_ is the "flaw" in my architecture, but it is a nearly unavoidable consequence
of offering VLIW features.

Aside from the affectation of allowing the System/360 to determine how long an
instruction has the right to be, its goals may be questionable. The instruction set looks
a lot like RISC, can go into a VLIW mode with instruction predication and explicit
indication of parallelism, and includes the functions found on a CISC architecture.

So it hasn't made up its mind what kind of a computer it wants to be. One can have a
great big OoO implementation, and one can have a tiny VLIW-centric implementation
that only runs efficiently if you use the VLIW mode features correctly. An architecture
that can be implemented across a range of systems, of course, is the great idea that
made the System/360 famous.

But these days, the equivalent of a microprogrammed Model 30 is hardly worth using
in a pocket calculator - and in my architecture, programs should be written differently
for efficient operation on different sized implementations, which somewhat reduces the
benefits of a common instruction set.

John Savard

On Tuesday, June 1, 2021 at 9:04:00 PM UTC-5, Quadibloc wrote:
> On Tuesday, June 1, 2021 at 6:10:40 PM UTC-6, MitchAlsup wrote:
>
> > S/360 did not have "all that good" code density partially due to 12-bit displacements
> > and base register addressing for everything. In order to even branch within a sub-
> > routine, one has to get a hold of the PC using a BALR instruction to the next instruction.
> > If the subroutine is bigger that 4096 bytes, you may have to do this more than once.
<
> Well, if its code density is not all that good, that's a good reason not to do even worse!
>
> But I thought if a subroutine is bigger than 4,096 bytes, you use one BALR instruction,
> and just fill several base registers with BASE, BASE+4,096, BASE+8,192 and so on.
> After all, if you have any forwards branches, it would be too late for another BALR
> when you cross the boundary...
<
Right, so you burn up 2,3,4 registers for branch base registers, and burn up another 2,3,4
registers for large arrays, and then you remember you only have 13 usable registers, so
you are left with 6 registers in which to "do work". This is the problem of base register
machines and why modern machines have "different arithmetic" for branching [ip+disp]
as compared to memory referencing [Rbase+disp].
<
> > > Load and store instructions no longer are limited to only aligned operands.
>
> > A misaligned memory model simply works better than the aligned only memory model:
> > and the HW cost is low enough that this is the only sensible choice these days.
<
> Which is _why_ I rush to provide load and store instructions without an alignment
> requirement in the 'enhanced' mode, which has a low overhead cost.
>
> For many computations, one can get by with only aligned operands. The ability to
> use an unaligned operand doesn't bring any benefits. But when it is needed, the
> instructions with that ability are easily available.
>
> So it isn't as if I'm offering an "aligned-only memory model", I'm just using the SEL
> trick to increase code density, but operations on unaligned operands are an
> easily-accessible option.
<
I worked at S.E.L. 1980-1983 and they were adamant that it was not SEL.
>
> Of course, an assembler that doesn't require the programmer to keep track of
> when a program crosses a block boundary will be complex, as it will have to process
> up to eight instructions at a time before deciding what format of block to generate.
>
> To me, _that_ is the "flaw" in my architecture, but it is a nearly unavoidable consequence
> of offering VLIW features.
<
Which gets at the heart of my critique:: why offer VLIW features at all ??
>
> Aside from the affectation of allowing the System/360 to determine how long an
> instruction has the right to be, its goals may be questionable. The instruction set looks
> a lot like RISC, can go into a VLIW mode with instruction predication and explicit
> indication of parallelism, and includes the functions found on a CISC architecture.
<
While S/360 has warts, it is massively better than x86.
<
And LD-Ops work surprisingly well and you can even build pipelines that make the LD
parts that hit int he cache to appear to operate at register speeds. In effect, you put
AGEN after DECODE and you put EXECUTE after LD-ALIGN.
>
> So it hasn't made up its mind what kind of a computer it wants to be. One can have a
> great big OoO implementation, and one can have a tiny VLIW-centric implementation
> that only runs efficiently if you use the VLIW mode features correctly. An architecture
> that can be implemented across a range of systems, of course, is the great idea that
> made the System/360 famous.
<
I contend that what makes S/360 ISA reasonable across a large scale of implementations
is NOT adding too many features !! and keeping those offered features clean. And I consider
the VLIW section to be a bridge too far.
>
> But these days, the equivalent of a microprogrammed Model 30 is hardly worth using
> in a pocket calculator - and in my architecture, programs should be written differently
> for efficient operation on different sized implementations, which somewhat reduces the
> benefits of a common instruction set.
<
Today, the smallest scale should be no smaller than R3000+FPU, and can be as big as
8-wide SuperScalar Out of Order with execution window of ~224 instructions.
<
Have you considered how you can make a machine using your ISA that can decode and
execute more than 1 bundle but smaller than 2 bundles per cycle ??
>
> John Savard

On Tuesday, June 1, 2021 at 8:29:28 PM UTC-6, MitchAlsup wrote:
> On Tuesday, June 1, 2021 at 9:04:00 PM UTC-5, Quadibloc wrote:

> > But I thought if a subroutine is bigger than 4,096 bytes, you use one BALR instruction,
> > and just fill several base registers with BASE, BASE+4,096, BASE+8,192 and so on.
> > After all, if you have any forwards branches, it would be too late for another BALR
> > when you cross the boundary...

> Right, so you burn up 2,3,4 registers for branch base registers, and burn up another 2,3,4
> registers for large arrays, and then you remember you only have 13 usable registers, so
> you are left with 6 registers in which to "do work". This is the problem of base register
> machines and why modern machines have "different arithmetic" for branching [ip+disp]
> as compared to memory referencing [Rbase+disp].

Ah.

Then, it's a _good_ thing that my design uses 16-bit displacements, despite the fact
that it has to make some sacrifices in order to do so.

I haven't used program-relative addressing for branches very much in the design,
on the other hand. Only the 16-bit branch instruction is program counter-relative.

But I _do_ recognize the problem of large arrays. I did _not_ like the idea that if you
have an array bigger than 64K (or 4K on the 360) you need basically one base register
per array. That's why I included "Array Mode" addressing in my design. That's where
base register 0, since it isn't used as a base register, points to a table... containing the
start addresses of arrays. So the index register gives the position in the array... basically,
it's indirect post-indexed addressing, but instead of being general, it's only possible for
the array addresses in this one table... that gets loaded into cache.

> I worked at S.E.L. 1980-1983 and they were adamant that it was not SEL.

I'll have to take another look at some of their old advertisements then. Of course,
since they're not writing my paycheck, I'm not too worried about their feelings...

> Which gets at the heart of my critique:: why offer VLIW features at all ??

That's a good question. After all, Ivan Godard is a nice guy, so why should I
want to annoy him?

Since he has mentioned the Itanium as a promising architecture in some of his
posts, and his intent is to make a lightweight design that competes with OoO
without its overhead... the presence of VLIW features could indeed be construed
as an intent of competing with him - although I am woefully unequipped to actually
manage that.

One thing is that I noted in the VLIW and VLIW-like designs I've seen that they
just have the equivalent of a 'break' bit. They indicate that "here's a chunk of instructions
that can be executed simultaneously... and now here's the next chunk".

That's all very well, but is that enough to tell a dumb CPU what to do?

Suppose there's a dependency. If the machine has to take a cycle between starting
each instruction (one-wide decode unit) and an instruction takes X cycles to execute, then
I can deal with dependencies by coding X-1 instructions between the instructions involved in
the dependency.

If I can't do that (the program may be executed on different implementations) and I want
the program to wait for only the minimum amount of time, but the implementation is dumb
and doesn't have much in the way of interlocks let alone OoO...

then I figured I would need to have a way to say not only 'do this bunch of instructions later' but
instead to indicate exactly which instruction another instruction depends on.

So I came up with the U bit, the D bit, and the offset field as required for indicating dependency
relations. I thought this was worth putting on display as a way to more fully flesh out the VLIW
model.

> > Aside from the affectation of allowing the System/360 to determine how long an
> > instruction has the right to be, its goals may be questionable. The instruction set looks
> > a lot like RISC, can go into a VLIW mode with instruction predication and explicit
> > indication of parallelism, and includes the functions found on a CISC architecture.

> While S/360 has warts, it is massively better than x86.

Amen. But the massive success of x86 shows that the Highlander model applies: "There can be
only one". Because people want to own the machine that will run nearly every piece of available
software.

Which is why, when I started with the original Concertina architecture... I decided that for an
architecture to have any chance of being the replacement for the x86, it couldn't be missing
some feature that a lot of people would desperately want.

Hence, everything but the kitchen sink.

> And LD-Ops work surprisingly well and you can even build pipelines that make the LD
> parts that hit int he cache to appear to operate at register speeds. In effect, you put
> AGEN after DECODE and you put EXECUTE after LD-ALIGN.

This went over my head, so I'll have to look it up.

> > So it hasn't made up its mind what kind of a computer it wants to be. One can have a
> > great big OoO implementation, and one can have a tiny VLIW-centric implementation
> > that only runs efficiently if you use the VLIW mode features correctly. An architecture
> > that can be implemented across a range of systems, of course, is the great idea that
> > made the System/360 famous.

> I contend that what makes S/360 ISA reasonable across a large scale of implementations
> is NOT adding too many features !! and keeping those offered features clean. And I consider
> the VLIW section to be a bridge too far.

Although today's iteration of S/360 does have a lot of legacy cruft, and therefore a lot
of features, I certainly admit the truth of that.

It is indeed odd to try to unify VLIW with CISC, though. After all, CISC means you've got some
stuff in your architecture that has to be microcoded. That won't derive benefits from VLIW
features.

> > But these days, the equivalent of a microprogrammed Model 30 is hardly worth using
> > in a pocket calculator - and in my architecture, programs should be written differently
> > for efficient operation on different sized implementations, which somewhat reduces the
> > benefits of a common instruction set.

> Today, the smallest scale should be no smaller than R3000+FPU, and can be as big as
> 8-wide SuperScalar Out of Order with execution window of ~224 instructions.

For general-purpose computing, yes - there's no benefit to making a CPU lighter than a
$15 smartphone CPU. But they still make 8-bit CPUs for special purposes in embedded
use.

> Have you considered how you can make a machine using your ISA that can decode and
> execute more than 1 bundle but smaller than 2 bundles per cycle ??

Not really. I've assumed that _one_ bundle, which is 8-wide superscalar, is a high-end
implementation, and a low-end one would start no more than one instruction per cycle.
I've sought to keep the architecture of my various implementations open to improvements
in technology, so that it wouldn't be impossible to implement it at *two* bundles per
cycle.

But let's say the underlying economics meant that one had to offer this architecture
on a 12-wide superscalar implementation.

If a one-instruction per cycle implementation is possible, then processing the block
while not immediately decoding or executing all the instructinos in the block is possible.

But in order for the pseudo-immediates to work, one does have to _fetch_ a whole
block at a time.

So one has a block-wide area into which a block is fetched, and from which the header
is decoded.

After those things are done, if the next stage to decode instructions and start executing
them was only four wide, so it would take two cycles before the next block started, this
wouldn't be unworkable - any more than a one-instruction per cycle implementation was
unworkable.

So I can now think of a way to handle your example.

I have to be able to fetch 512 bits per cycle, and buffer the 512 bits, and decode two headers
in one cycle.

Then I can feed 1 1/2 blocks to three four-wide superscalar pipelines.

Four instructions left over?

Fine. Next cycle, only fetch 256 bits and decode one header.

Nothing left over? Next cycle, decode two headers.

John Savard

On Tuesday, June 1, 2021 at 9:33:28 PM UTC-6, Quadibloc wrote:
> On Tuesday, June 1, 2021 at 8:29:28 PM UTC-6, MitchAlsup wrote:

> > And LD-Ops work surprisingly well and you can even build pipelines that make the LD
> > parts that hit int he cache to appear to operate at register speeds. In effect, you put
> > AGEN after DECODE and you put EXECUTE after LD-ALIGN.

> This went over my head, so I'll have to look it up.

Trying to look it up turned up something unrelated, not a specific Hennessy and
Patterson coinage.

Certainly, to the limited extent that I've included memory-reference operate
instructions in the architecture, I intend to split them into load and operate
micro-ops.

Yes, address generation - adding in the base and index values - should be done
as soon as the contents of those registers are available, so that later, when the
pipeline is available for executing the calculation on the instruction's operands,
nothing is kept waiting.

And unaligned operands - they require at least dual-channel memory, so that
an operand crossing a boundary doesn't force a second fetch. Then what you
need is a circuit like a barrel shifter, except it shifts by bytes rather than bits.

Oh, yes, I've looked up the basics of how people design computers to make
them go fast.

Even if I have the habit of referring to Wallace Tree multipliers, because I'm
including the Model 91 and the STRETCH as examples, with their tiny little
trees that aren't big enough to go all Dadda.

John Savard

On 6/1/2021 8:33 PM, Quadibloc wrote:
> On Tuesday, June 1, 2021 at 8:29:28 PM UTC-6, MitchAlsup wrote:
>> On Tuesday, June 1, 2021 at 9:04:00 PM UTC-5, Quadibloc wrote:
>
>>> But I thought if a subroutine is bigger than 4,096 bytes, you use one BALR instruction,
>>> and just fill several base registers with BASE, BASE+4,096, BASE+8,192 and so on.
>>> After all, if you have any forwards branches, it would be too late for another BALR
>>> when you cross the boundary...
>
>> Right, so you burn up 2,3,4 registers for branch base registers, and burn up another 2,3,4
>> registers for large arrays, and then you remember you only have 13 usable registers, so
>> you are left with 6 registers in which to "do work". This is the problem of base register
>> machines and why modern machines have "different arithmetic" for branching [ip+disp]
>> as compared to memory referencing [Rbase+disp].
>
> Ah.
>
> Then, it's a _good_ thing that my design uses 16-bit displacements, despite the fact
> that it has to make some sacrifices in order to do so.
>
> I haven't used program-relative addressing for branches very much in the design,
> on the other hand. Only the 16-bit branch instruction is program counter-relative.
>
> But I _do_ recognize the problem of large arrays. I did _not_ like the idea that if you
> have an array bigger than 64K (or 4K on the 360) you need basically one base register
> per array. That's why I included "Array Mode" addressing in my design. That's where
> base register 0, since it isn't used as a base register, points to a table... containing the
> start addresses of arrays. So the index register gives the position in the array... basically,
> it's indirect post-indexed addressing, but instead of being general, it's only possible for
> the array addresses in this one table... that gets loaded into cache.
>
>> I worked at S.E.L. 1980-1983 and they were adamant that it was not SEL.
>
> I'll have to take another look at some of their old advertisements then. Of course,
> since they're not writing my paycheck, I'm not too worried about their feelings...
>
>> Which gets at the heart of my critique:: why offer VLIW features at all ??
>
> That's a good question. After all, Ivan Godard is a nice guy, so why should I
> want to annoy him?

Flattery will get you everywhere!

On Tuesday, June 1, 2021 at 9:53:26 PM UTC-6, Quadibloc wrote:

> Oh, yes, I've looked up the basics of how people design computers to make
> them go fast.

But there's plenty I don't know.

Thus, I haven't managed to figure out how one would go about designing
a proper register rename unit at the gate level.

Only recently did I learn how a 2-way set associative cache is actually
built.

John Savard

On Tuesday, June 1, 2021 at 8:29:28 PM UTC-6, MitchAlsup wrote:

> Which gets at the heart of my critique:: why offer VLIW features at all ??

> And I consider
> the VLIW section to be a bridge too far.

Upon reflection, I see the "real" reason that I'm offering the feature of
VLIW operation.

It's really quite simple.

In order to offer immediates for instructions, not limited to 8-bit and
16-bit immediates (and offering floating-point immediates only from
a short list, or with A-law encoding, simply did not bear thinking about
from my point of view)...

I either would have had to encode the length of instructions in an
unwieldy way, or use the block scheme that I'm using.

And _if_ I organize the program code into blocks (as an option, since
basic format code with no headers is possible) then not only is it _easy_
to offer VLIW...

but, as well, I kind of feel that if I don't offer VLIW, I don't have a good
enough excuse to be organizing program code into blocks! If I've already
_got_ a 256-bit VLIW, I should be offering the usual amenities with it.
And since blisteringly fast speed is another one of the primary objectives
of my ISA design, it's a natural fit.

John Savard

On Tuesday, June 1, 2021 at 9:33:28 PM UTC-6, Quadibloc wrote:
> On Tuesday, June 1, 2021 at 8:29:28 PM UTC-6, MitchAlsup wrote:

> > I worked at S.E.L. 1980-1983 and they were adamant that it was not SEL.

> I'll have to take another look at some of their old advertisements then. Of course,
> since they're not writing my paycheck, I'm not too worried about their feelings...

I have now done so.

When it comes to the time of the SYSTEMS 32, their brochures and manuals
seem to abbreviate Systems Engineering Laboratories only as SYSTEMS.

But looking at an ad for the SEL 810B from 1967 that ran in Datamation, the
ad copy reads...

Anything the SEL 810A can do,

the new SEL 810B can do twice as fast.

Over 50 SEL 810A, 16-bit computers have been supplied for data acquisition
and control. Now meet the SEL 810B, with twice the speed of the A.

....and so on and so forth. SEL, not S.E.L. anywhere.

John Savard

On 2021-06-01, Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>
>> Finally, I take sample code from Brian's compiler and see if the cooked
>> data is representative of actual produced instruction. I have "read' the
>> ASM of his LLVM front end, Livermore Loops, and a few other choice
>> applications. I wish I had access of SPEC (of any era) so I could "read"
>> that, too.
>
> I have done a bit of disassembly on POWER and done some very
> rudimentary statistics, with a view towards what a kind of
> compressed instruction set should have.
>
> Of course, this does not help for constructs which POWER does
> not support.
>
> Here is an example output from /usr/bin/git :
>
> destructive three register op: 4327
> non-destructive three register op: 1223
> destructive register constant op: 34891
> two register op: 4864
> non-destructive register constant op: 29326
> load/store with constant offset: 93058
> fp load/store with constant offset: 26
> load/store base+index reg: 4038
> load immediate: 22058
> load immediate and shift: 2827
> move register: 31607
> move special: 8764
> compare instructions: 22160
> branch instructions: 65712
> of which bctr: 240
> of which blr: 3302
> of which bctrl: 217
> floating point operations: 61
> byte reversal: 82
> condition register set: 13
> vector scalar registers: 588
> altivec: 38
> load/store base+index fp: 0
> barrier: 0
> supervisor call: 0
> abort trap: 0
> default prefetch: 0
> nop: 23345
> service processor attention: 2
> load / store offset statistics:
> offset = 0: 7787
> 1 <= abs(offset) < 15: 2407, 616 disible by 4
> 16 <= abs(offset) < 128: 61950, 61596 disible by 4
> 128 <= abs(offset) < 2048: 13746, 13663 disible by 4
> 2048 <= abs(offset) 7168, 7046 disible by 4
> Branch statistics:
> offset < 127: 5035
> 128 <= offset < 2048: 9760
> 2048 <= offset < 4096: 1540
> 4096 <= offset < 8192: 1211
> 8192 <= offset < 32768: 1645
> 32768 <= offset < 65536: 673
> 65536 <= offset <131072: 1389
> 132027<= offset <262144: 2425
> 262144<= offset 16191
>
> By comparison, here is a scientific code, aermod.f90 from
> the Polyhedron benchmark suite:
>
> destructive three register op: 7866
> non-destructive three register op: 1523
> destructive register constant op: 19791
> two register op: 2854
> non-destructive register constant op: 24625
> load/store with constant offset: 56247
> fp load/store with constant offset: 10309
> load/store base+index reg: 2101
> load immediate: 17422
> load immediate and shift: 2026
> move register: 5994
> move special: 2109
> compare instructions: 7099
> branch instructions: 23590
> of which bctr: 50
> of which blr: 805
> of which bctrl: 8
> floating point operations: 8255
> byte reversal: 62
> condition register set: 961
> vector scalar registers: 2523
> altivec: 93
> load/store base+index fp: 1720
> barrier: 0
> supervisor call: 0
> abort trap: 0
> default prefetch: 0
> nop: 13563
> service processor attention: 1
> load / store offset statistics:
> offset = 0: 630
> 1 <= abs(offset) < 15: 382, 260 disible by 4
> 16 <= abs(offset) < 128: 21435, 21424 disible by 4
> 128 <= abs(offset) < 2048: 12760, 12757 disible by 4
> 2048 <= abs(offset) 21040, 20922 disible by 4
> Branch statistics:
> offset < 127: 3334
> 128 <= offset < 2048: 7217
> 2048 <= offset < 4096: 1185
> 4096 <= offset < 8192: 906
> 8192 <= offset < 32768: 901
> 32768 <= offset < 65536: 620
> 65536 <= offset <131072: 569
> 132027<= offset <262144: 1266
> 262144<= offset 6111
> Instructions: 213306
>

Thanks! Saving those numbers for future use :-)

I did a similar quick disassembly + grep for MRISC32 on the
Doom and Quake binaries (but it lacks operand configurations
and branch ranges etc):

https://github.com/mrisc32/mrisc32/issues/103#issuecomment-768143215

The scope for that investigation was code size.

A different axis is the dynamic instruction count (i.e. instruction
execution frequencies) which I think is more relevant for
performance analysis/tuning of an ISA.

> By comparison, you see theat there are far more floating point
> operations (obviously).
>
> Also, load and store with a constant offset seems to be a
> very frequent operation no matter what.
>
> Seeing which of the operations could have been fused into
> a load or store from register + register + offset would
> require a much more elaborate analysis than my simplistic
> Perl script.
>

On 6/2/2021 2:49 AM, Quadibloc wrote:
> On Tuesday, June 1, 2021 at 8:29:28 PM UTC-6, MitchAlsup wrote:
>
>> Which gets at the heart of my critique:: why offer VLIW features at all ??
>
>> And I consider
>> the VLIW section to be a bridge too far.
>
> Upon reflection, I see the "real" reason that I'm offering the feature of
> VLIW operation.
>
> It's really quite simple.
>
> In order to offer immediates for instructions, not limited to 8-bit and
> 16-bit immediates (and offering floating-point immediates only from
> a short list, or with A-law encoding, simply did not bear thinking about
> from my point of view)...
>
> I either would have had to encode the length of instructions in an
> unwieldy way, or use the block scheme that I'm using.
>
> And _if_ I organize the program code into blocks (as an option, since
> basic format code with no headers is possible) then not only is it _easy_
> to offer VLIW...
>
> but, as well, I kind of feel that if I don't offer VLIW, I don't have a good
> enough excuse to be organizing program code into blocks! If I've already
> _got_ a 256-bit VLIW, I should be offering the usual amenities with it.
> And since blisteringly fast speed is another one of the primary objectives
> of my ISA design, it's a natural fit.

This last part seems to be circular logic. If I do blocks, then I
should do VLIW (because it is easy), and if I don't do VLIW, I shouldn't
do blocks. But your argument for doing both seems flawed. As I
understand it, it it to offer longer immediates. But Mitch has
demonstrated a way to have fixed length "instructions" (32 bits), with
longer immediates. Why is your solution better than his?

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

Marcus <m.delete@this.bitsnbites.eu> writes:
>A different axis is the dynamic instruction count (i.e. instruction
>execution frequencies) which I think is more relevant for
>performance analysis/tuning of an ISA.

One would think so, but the problem is that in a corpus of large
programs the dynamically executed instructions are mostly confined to
a few hot spots, and the rest of the large programs them plays hardly
any role. And as a consequence, the most frequent dynamically
executed instruction sequences tend to be not very representative of
what happens in other programs.

That was certainly our experience in our work on virtual machine
superinstructions (a sequence of virtual instructions is combined into
one virtual superinstruction): When selecting superinstructions based
on a set of benchmarks, and then measuring the performance of a
benchmark that is not in the set, we saw better results when selecting
the statically most frequently occuring sequences than when selecting
the dynamically most frequently occuring sequences. E.g., read
Chapter 3 of

@MastersThesis{eller05,
author = {Helmut Eller},
title = {Optimizing Interpreters with Superinstructions},
school = {TU Wien},
year = {2005},
type = {Diplomarbeit},
url = {http://www.complang.tuwien.ac.at/Diplomarbeiten/eller05.ps.gz},
abstract = {Superinstructions can be used to make virtual
machine (VM) interpreters faster. A superinstruction
is a combination of simpler VM instructions which
can be executed faster than the corresponding
sequence of simpler VM instructions, because the
interpretative overhead, like instruction dispatch
and argument fetching, is reduced. This work
discusses the following three topics related to
superinstructions. First, I present some heuristics
to choose superinstructions. I evaluated the
heuristics for Forth and Java programs. If the
number of allowed superinstructions was very large,
$> 1000$, then the heuristic which chooses all
possible subsequences up to length 4 achieved the
best results. If the number of allowed
superinstructions was more limited, then a heuristic
which favors short sequences and sequences which
occur in many different programs and many different
basic blocks performed better than the
others. Second, I compare a simple greedy algorithm
and an optimal algorithm to cover a program with
superinstructions. I found that the greedy algorithm
achieves almost optimal results. Finally, I compare
superinstructions with non-sequential patterns. In
my experiments, superinstructions performed slightly
better than non-sequential patterns.}
}

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

On Wednesday, June 2, 2021 at 9:53:58 AM UTC-6, Stephen Fuld wrote:
> But Mitch has
> demonstrated a way to have fixed length "instructions" (32 bits), with
> longer immediates. Why is your solution better than his?

I don't know for sure what his solution is, so I can't really answer that;
and, of course, Mitch has far more knowledge and experience in CPU
design than I do.

However, IIRC, his solution actually did require _some_ sequential
decoding of instructions, whereeas my scheme, whatever other flaws
it may have, provides for everything being decoded in parallel.

John Savard

On Tuesday, June 1, 2021 at 10:33:28 PM UTC-5, Quadibloc wrote:
> On Tuesday, June 1, 2021 at 8:29:28 PM UTC-6, MitchAlsup wrote:
> > On Tuesday, June 1, 2021 at 9:04:00 PM UTC-5, Quadibloc wrote:
>
> > > But I thought if a subroutine is bigger than 4,096 bytes, you use one BALR instruction,
> > > and just fill several base registers with BASE, BASE+4,096, BASE+8,192 and so on.
> > > After all, if you have any forwards branches, it would be too late for another BALR
> > > when you cross the boundary...
>
> > Right, so you burn up 2,3,4 registers for branch base registers, and burn up another 2,3,4
> > registers for large arrays, and then you remember you only have 13 usable registers, so
> > you are left with 6 registers in which to "do work". This is the problem of base register
> > machines and why modern machines have "different arithmetic" for branching [ip+disp]
> > as compared to memory referencing [Rbase+disp].
> Ah.
>
> Then, it's a _good_ thing that my design uses 16-bit displacements, despite the fact
> that it has to make some sacrifices in order to do so.
<
Cuts down on the register waste, so do 32-bit and 64-bit displacements.
>
> I haven't used program-relative addressing for branches very much in the design,
> on the other hand. Only the 16-bit branch instruction is program counter-relative.
>
> But I _do_ recognize the problem of large arrays. I did _not_ like the idea that if you
> have an array bigger than 64K (or 4K on the 360) you need basically one base register
> per array. That's why I included "Array Mode" addressing in my design. That's where
> base register 0, since it isn't used as a base register, points to a table... containing the
> start addresses of arrays. So the index register gives the position in the array... basically,
> it's indirect post-indexed addressing, but instead of being general, it's only possible for
> the array addresses in this one table... that gets loaded into cache.
> > I worked at S.E.L. 1980-1983 and they were adamant that it was not SEL.
> I'll have to take another look at some of their old advertisements then. Of course,
> since they're not writing my paycheck, I'm not too worried about their feelings...
> > Which gets at the heart of my critique:: why offer VLIW features at all ??
> That's a good question. After all, Ivan Godard is a nice guy, so why should I
> want to annoy him?
>
> Since he has mentioned the Itanium as a promising architecture in some of his
<
When it began, Itanium had promise.
When the first chips taped out, it no longer did.
<
> posts, and his intent is to make a lightweight design that competes with OoO
> without its overhead... the presence of VLIW features could indeed be construed
> as an intent of competing with him - although I am woefully unequipped to actually
> manage that.
>
> One thing is that I noted in the VLIW and VLIW-like designs I've seen that they
> just have the equivalent of a 'break' bit. They indicate that "here's a chunk of instructions
> that can be executed simultaneously... and now here's the next chunk".
<
The break bit is equivalent to "the rest of the bundle is NoOps."
>
> That's all very well, but is that enough to tell a dumb CPU what to do?
<
I, personally, don't think building dumb CPUs is a worthy endeavor.
>
> Suppose there's a dependency. If the machine has to take a cycle between starting
> each instruction (one-wide decode unit) and an instruction takes X cycles to execute, then
> I can deal with dependencies by coding X-1 instructions between the instructions involved in
> the dependency.
<
And this is where VLIW breaks down. What is X is variable or X changes between implementations ?
<
Mill solves this problem by distributing applications in re-compiled intermediate format.
And Mill has a specializer (code generator) for each implementation.
Mill does not have a fixed ISA, but one tuned to each implementation.
<
So, if you want VLIW, you don't want a fixed ISA !!
>
> If I can't do that (the program may be executed on different implementations) and I want
> the program to wait for only the minimum amount of time, but the implementation is dumb
> and doesn't have much in the way of interlocks let alone OoO...
>
> then I figured I would need to have a way to say not only 'do this bunch of instructions later' but
> instead to indicate exactly which instruction another instruction depends on.
<
Operand register generally suffices.
>
> So I came up with the U bit, the D bit, and the offset field as required for indicating dependency
> relations. I thought this was worth putting on display as a way to more fully flesh out the VLIW
> model.
> > > Aside from the affectation of allowing the System/360 to determine how long an
> > > instruction has the right to be, its goals may be questionable. The instruction set looks
> > > a lot like RISC, can go into a VLIW mode with instruction predication and explicit
> > > indication of parallelism, and includes the functions found on a CISC architecture.
>
> > While S/360 has warts, it is massively better than x86.
> Amen. But the massive success of x86 shows that the Highlander model applies: "There can be
> only one". Because people want to own the machine that will run nearly every piece of available
> software.
>
> Which is why, when I started with the original Concertina architecture... I decided that for an
> architecture to have any chance of being the replacement for the x86, it couldn't be missing
> some feature that a lot of people would desperately want.
<
99% of PC users don't give a crap about the architecture of the machine, only the developers do !!
>
> Hence, everything but the kitchen sink.
<
Taking the light weight nature of VLIW and crushing it with added baggage.
<
> > And LD-Ops work surprisingly well and you can even build pipelines that make the LD
> > parts that hit int he cache to appear to operate at register speeds. In effect, you put
> > AGEN after DECODE and you put EXECUTE after LD-ALIGN.
<
> This went over my head, so I'll have to look it up.
<
FETCH-DECODE-AGEN-CACHE-LDALIGN-EXEC-WRITE
<
> > > So it hasn't made up its mind what kind of a computer it wants to be. One can have a
> > > great big OoO implementation, and one can have a tiny VLIW-centric implementation
> > > that only runs efficiently if you use the VLIW mode features correctly. An architecture
> > > that can be implemented across a range of systems, of course, is the great idea that
> > > made the System/360 famous.
>
> > I contend that what makes S/360 ISA reasonable across a large scale of implementations
> > is NOT adding too many features !! and keeping those offered features clean. And I consider
> > the VLIW section to be a bridge too far.
<
> Although today's iteration of S/360 does have a lot of legacy cruft, and therefore a lot
> of features, I certainly admit the truth of that.
<
Today's mainframes from IBM are not S/360 (or even S/370, 3080, 3090) they are another
super extended 64-bit, but sometimes 32-bit ISA will 3 kinds of floating point (HEX, binary, decimal)
and everything including the kitchen sink.
>
> It is indeed odd to try to unify VLIW with CISC, though. After all, CISC means you've got some
> stuff in your architecture that has to be microcoded. That won't derive benefits from VLIW
> features.
<
Disagree on 2 counts: CISC does not need microcode and some RISC designs should consider
being mircocoded. I consider microcode a programatic way to build sequencers, nothing more
or less.
<
> > > But these days, the equivalent of a microprogrammed Model 30 is hardly worth using
> > > in a pocket calculator - and in my architecture, programs should be written differently
> > > for efficient operation on different sized implementations, which somewhat reduces the
> > > benefits of a common instruction set.
>
> > Today, the smallest scale should be no smaller than R3000+FPU, and can be as big as
> > 8-wide SuperScalar Out of Order with execution window of ~224 instructions.
<
> For general-purpose computing, yes - there's no benefit to making a CPU lighter than a
> $15 smartphone CPU. But they still make 8-bit CPUs for special purposes in embedded
> use.
> > Have you considered how you can make a machine using your ISA that can decode and
> > execute more than 1 bundle but smaller than 2 bundles per cycle ??
<
> Not really. I've assumed that _one_ bundle, which is 8-wide superscalar, is a high-end
> implementation, and a low-end one would start no more than one instruction per cycle.
> I've sought to keep the architecture of my various implementations open to improvements
> in technology, so that it wouldn't be impossible to implement it at *two* bundles per
> cycle.
>
> But let's say the underlying economics meant that one had to offer this architecture
> on a 12-wide superscalar implementation.
>
> If a one-instruction per cycle implementation is possible, then processing the block
> while not immediately decoding or executing all the instructinos in the block is possible.
>
> But in order for the pseudo-immediates to work, one does have to _fetch_ a whole
> block at a time.
>
> So one has a block-wide area into which a block is fetched, and from which the header
> is decoded.
>
> After those things are done, if the next stage to decode instructions and start executing
> them was only four wide, so it would take two cycles before the next block started, this
> wouldn't be unworkable - any more than a one-instruction per cycle implementation was
> unworkable.
>
> So I can now think of a way to handle your example.
>
> I have to be able to fetch 512 bits per cycle, and buffer the 512 bits, and decode two headers
> in one cycle.
>
> Then I can feed 1 1/2 blocks to three four-wide superscalar pipelines.
>
> Four instructions left over?
>
> Fine. Next cycle, only fetch 256 bits and decode one header.
>
> Nothing left over? Next cycle, decode two headers.
>
> John Savard

On Wednesday, June 2, 2021 at 1:10:12 PM UTC-5, Quadibloc wrote:
> On Wednesday, June 2, 2021 at 9:53:58 AM UTC-6, Stephen Fuld wrote:
> > But Mitch has
> > demonstrated a way to have fixed length "instructions" (32 bits), with
> > longer immediates. Why is your solution better than his?
> I don't know for sure what his solution is, so I can't really answer that;
> and, of course, Mitch has far more knowledge and experience in CPU
> design than I do.
>
> However, IIRC, his solution actually did require _some_ sequential
> decoding of instructions, whereeas my scheme, whatever other flaws
> it may have, provides for everything being decoded in parallel.
>
> John Savard

On Wednesday, June 2, 2021 at 1:10:12 PM UTC-5, Quadibloc wrote:
> On Wednesday, June 2, 2021 at 9:53:58 AM UTC-6, Stephen Fuld wrote:
> > But Mitch has
> > demonstrated a way to have fixed length "instructions" (32 bits), with
> > longer immediates. Why is your solution better than his?
> I don't know for sure what his solution is, so I can't really answer that;
> and, of course, Mitch has far more knowledge and experience in CPU
> design than I do.
>
> However, IIRC, his solution actually did require _some_ sequential
> decoding of instructions, whereeas my scheme, whatever other flaws
> it may have, provides for everything being decoded in parallel.
<
In 30 total gates, and in 4-gates of delay, one can decode My 66000
instructions to determine their length, and the offsets in the instruction
stream of any constants. IBM 360 does this in 2-gates of delay. Both
share the advantage that the bits decoded are all fixed over all instruction
formats. So, My 66000 is only 2-gates behind at this point.
<
From here we setup a tree of find next instruction logic (2-gates) and we
parse (determine starting word and all constant words) 2 then 4 then 8
then 16 instructions at 2-gates of delay each level. So parsing 16 instructions
per cycle is a 12-gate delay problem. Easy Peasy in a 16-gate cycle. The
original IBM 360 would be 2-gates shorter, the current monstrosity would
be longer.
<
So, at these issue widths, the problem is more ICache access width, and
the fact that every 9.2 instructions one "takes" a branch (10.3 words).
So the machines with "simple" front ends are FETCH limited not decode
or execute limited.
>
> John Savard

MitchAlsup wrote:
> On Tuesday, June 1, 2021 at 10:33:28 PM UTC-5, Quadibloc wrote:
>> Since he has mentioned the Itanium as a promising architecture in some of his
> <
> When it began, Itanium had promise.
> When the first chips taped out, it no longer did.

This!

When the first Itanium came out, it was 5 years late, and still only a
partial implementation. In the CPU business where all the competitors,
inluding AMD64, still enjoyed full Moore's law scaling, this was a
capital offense.

Terje

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

On Wednesday, June 2, 2021 at 12:27:23 PM UTC-6, MitchAlsup wrote:
> On Tuesday, June 1, 2021 at 10:33:28 PM UTC-5, Quadibloc wrote:

> > Suppose there's a dependency. If the machine has to take a cycle between starting
> > each instruction (one-wide decode unit) and an instruction takes X cycles to execute, then
> > I can deal with dependencies by coding X-1 instructions between the instructions involved in
> > the dependency.

> And this is where VLIW breaks down. What is X is variable or X changes between implementations ?

Ah, but I guess I didn't make myself clear here.

That's how I could deal with dependencies on a RISC CPU, which doesn't have the extra
features that VLIW offers.

If I have OoO, obviously, if X changes between implementations, it's not an issue.

If I have VLIW, I can now explicitly indicate 'this instruction depends on that previous
instruction', so the processor knows to wait only for the minimum time necessary (or, at
worst, the worst-case time required by the previous instruction).

John Savard

On 6/2/2021 11:27 AM, MitchAlsup wrote:
> On Tuesday, June 1, 2021 at 10:33:28 PM UTC-5, Quadibloc wrote:
>> On Tuesday, June 1, 2021 at 8:29:28 PM UTC-6, MitchAlsup wrote:
>>> On Tuesday, June 1, 2021 at 9:04:00 PM UTC-5, Quadibloc wrote:
>>
>>>> But I thought if a subroutine is bigger than 4,096 bytes, you use one BALR instruction,
>>>> and just fill several base registers with BASE, BASE+4,096, BASE+8,192 and so on.
>>>> After all, if you have any forwards branches, it would be too late for another BALR
>>>> when you cross the boundary...
>>
>>> Right, so you burn up 2,3,4 registers for branch base registers, and burn up another 2,3,4
>>> registers for large arrays, and then you remember you only have 13 usable registers, so
>>> you are left with 6 registers in which to "do work". This is the problem of base register
>>> machines and why modern machines have "different arithmetic" for branching [ip+disp]
>>> as compared to memory referencing [Rbase+disp].
>> Ah.
>>
>> Then, it's a _good_ thing that my design uses 16-bit displacements, despite the fact
>> that it has to make some sacrifices in order to do so.
> <
> Cuts down on the register waste, so do 32-bit and 64-bit displacements.
>>
>> I haven't used program-relative addressing for branches very much in the design,
>> on the other hand. Only the 16-bit branch instruction is program counter-relative.
>>
>> But I _do_ recognize the problem of large arrays. I did _not_ like the idea that if you
>> have an array bigger than 64K (or 4K on the 360) you need basically one base register
>> per array. That's why I included "Array Mode" addressing in my design. That's where
>> base register 0, since it isn't used as a base register, points to a table... containing the
>> start addresses of arrays. So the index register gives the position in the array... basically,
>> it's indirect post-indexed addressing, but instead of being general, it's only possible for
>> the array addresses in this one table... that gets loaded into cache.
>>> I worked at S.E.L. 1980-1983 and they were adamant that it was not SEL.
>> I'll have to take another look at some of their old advertisements then. Of course,
>> since they're not writing my paycheck, I'm not too worried about their feelings...
>>> Which gets at the heart of my critique:: why offer VLIW features at all ??
>> That's a good question. After all, Ivan Godard is a nice guy, so why should I
>> want to annoy him?
>>
>> Since he has mentioned the Itanium as a promising architecture in some of his
> <
> When it began, Itanium had promise.
> When the first chips taped out, it no longer did.
> <
>> posts, and his intent is to make a lightweight design that competes with OoO
>> without its overhead... the presence of VLIW features could indeed be construed
>> as an intent of competing with him - although I am woefully unequipped to actually
>> manage that.
>>
>> One thing is that I noted in the VLIW and VLIW-like designs I've seen that they
>> just have the equivalent of a 'break' bit. They indicate that "here's a chunk of instructions
>> that can be executed simultaneously... and now here's the next chunk".
> <
> The break bit is equivalent to "the rest of the bundle is NoOps."
>>
>> That's all very well, but is that enough to tell a dumb CPU what to do?
> <
> I, personally, don't think building dumb CPUs is a worthy endeavor.
>>
>> Suppose there's a dependency. If the machine has to take a cycle between starting
>> each instruction (one-wide decode unit) and an instruction takes X cycles to execute, then
>> I can deal with dependencies by coding X-1 instructions between the instructions involved in
>> the dependency.
> <
> And this is where VLIW breaks down. What is X is variable or X changes between implementations ?
> <
> Mill solves this problem by distributing applications in re-compiled intermediate format.
> And Mill has a specializer (code generator) for each implementation.
> Mill does not have a fixed ISA, but one tuned to each implementation.
> <
> So, if you want VLIW, you don't want a fixed ISA !!

re-compiled -> pre-compiled?

On Wednesday, June 2, 2021 at 12:27:23 PM UTC-6, MitchAlsup wrote:

> Taking the light weight nature of VLIW and crushing it with added baggage.

Yes, that's a fair criticism. But implementations can omit features. Including the option of
VLIW. (Preferred is to accept VLIW programs, but basically ignore all the hinting.)

> Today's mainframes from IBM are not S/360 (or even S/370, 3080, 3090) they are another
> super extended 64-bit, but sometimes 32-bit ISA will 3 kinds of floating point (HEX, binary, decimal)
> and everything including the kitchen sink.

Although they still have 00 -> 16 bits, 11-> 48 bits, and 01 and 10 -> 32 bits.

And the things they've added were all things that met the needs of their customers; hex and binary
floating point give compatibility with old software on the one hand, and the better numerical
properties of IEEE-754 on the other.

John Savard

On Wednesday, June 2, 2021 at 12:27:23 PM UTC-6, MitchAlsup wrote:
> On Tuesday, June 1, 2021 at 10:33:28 PM UTC-5, Quadibloc wrote:

> > It is indeed odd to try to unify VLIW with CISC, though. After all, CISC means you've got some
> > stuff in your architecture that has to be microcoded. That won't derive benefits from VLIW
> > features.

> Disagree on 2 counts: CISC does not need microcode and some RISC designs should consider
> being mircocoded. I consider microcode a programatic way to build sequencers, nothing more
> or less.

Oh, of course. I should have been more careful.

It's just that, in general, CISC is more likely to have instructions that cry out for some kind of
microcoding; i.e. stuff like EDMK from System/360.

John Savard

MitchAlsup <MitchAlsup@aol.com> schrieb:

> In 30 total gates, and in 4-gates of delay, one can decode My 66000
> instructions to determine their length, and the offsets in the instruction
> stream of any constants.

How many gate delays does a modern architecture usually have per cycle?
(I know different gates have different delays, but a ballpark figure
would be very interesting).

>IBM 360 does this in 2-gates of delay. Both
> share the advantage that the bits decoded are all fixed over all instruction
> formats. So, My 66000 is only 2-gates behind at this point.
><
> From here we setup a tree of find next instruction logic (2-gates) and we
> parse (determine starting word and all constant words) 2 then 4 then 8
> then 16 instructions at 2-gates of delay each level. So parsing 16 instructions
> per cycle is a 12-gate delay problem. Easy Peasy in a 16-gate cycle. The
> original IBM 360 would be 2-gates shorter, the current monstrosity would
> be longer.

Is 16 gates per cycle particularly short?

On 2021-06-02 Anton Ertl wrote:
> Marcus <m.delete@this.bitsnbites.eu> writes:
>> A different axis is the dynamic instruction count (i.e. instruction
>> execution frequencies) which I think is more relevant for
>> performance analysis/tuning of an ISA.
>
> One would think so, but the problem is that in a corpus of large
> programs the dynamically executed instructions are mostly confined to
> a few hot spots, and the rest of the large programs them plays hardly
> any role. And as a consequence, the most frequent dynamically
> executed instruction sequences tend to be not very representative of
> what happens in other programs.

Interesting observation. I suspected that something similar would be the
case, since looping/hot code must give a very strong bias.

I have planned to add instruction frequency profiling to my simulator (I
already have symbol-based function profiling which has proven very
useful), but I'll keep in mind the difficulties that you pointed out.

I wonder if you could improve the situation if you used something like
different scales (logarithmic?) and some sort of filtering or
thresholding (e.g. count each memory location at most N times) to
reduce the bias from loops? Or possibly categorize counts into different
bins (e.g. "cold", "medium", "hot").

>
> That was certainly our experience in our work on virtual machine
> superinstructions (a sequence of virtual instructions is combined into
> one virtual superinstruction): When selecting superinstructions based
> on a set of benchmarks, and then measuring the performance of a
> benchmark that is not in the set, we saw better results when selecting
> the statically most frequently occuring sequences than when selecting
> the dynamically most frequently occuring sequences. E.g., read
> Chapter 3 of
>
> @MastersThesis{eller05,
> author = {Helmut Eller},
> title = {Optimizing Interpreters with Superinstructions},
> school = {TU Wien},
> year = {2005},
> type = {Diplomarbeit},
> url = {http://www.complang.tuwien.ac.at/Diplomarbeiten/eller05.ps.gz},
> abstract = {Superinstructions can be used to make virtual
> machine (VM) interpreters faster. A superinstruction
> is a combination of simpler VM instructions which
> can be executed faster than the corresponding
> sequence of simpler VM instructions, because the
> interpretative overhead, like instruction dispatch
> and argument fetching, is reduced. This work
> discusses the following three topics related to
> superinstructions. First, I present some heuristics
> to choose superinstructions. I evaluated the
> heuristics for Forth and Java programs. If the
> number of allowed superinstructions was very large,
> $> 1000$, then the heuristic which chooses all
> possible subsequences up to length 4 achieved the
> best results. If the number of allowed
> superinstructions was more limited, then a heuristic
> which favors short sequences and sequences which
> occur in many different programs and many different
> basic blocks performed better than the
> others. Second, I compare a simple greedy algorithm
> and an optimal algorithm to cover a program with
> superinstructions. I found that the greedy algorithm
> achieves almost optimal results. Finally, I compare
> superinstructions with non-sequential patterns. In
> my experiments, superinstructions performed slightly
> better than non-sequential patterns.}
> }
>
> - anton
>

Marcus <m.delete@this.bitsnbites.eu> writes:
>I wonder if you could improve the situation if you used something like
>different scales (logarithmic?) and some sort of filtering or
>thresholding (e.g. count each memory location at most N times) to
>reduce the bias from loops? Or possibly categorize counts into different
>bins (e.g. "cold", "medium", "hot").

That's plausible, but I have no empirical results on such schemes.
One would think that this is a common idea and that there would be a
lot of empirical data on it, but I am not aware of that (but then, I
have not read as many papers in recent years as I used to).

Thinking about how such an absence (if it is one) could be explained,
I thought about application areas:

* Superinstructions/superoperators/supercombinators in interpreters.
Here we can combine many simple instructions/operators/combinators,
and selecting many unrepresentative sequences can have a significant
negative effect.

* Instruction-set design for hardware architectures: Since the RISC
revolution one tends to avoid big instructions, so the problem above
does not occur in that severity. For, e.g., selecting immediate-field
widths, there are not so many variations, so the hot code in the
benchmarks is probably not that unrepresentative of other hot code,
and may be more representative than, say, initialization code.

Anything else?

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

On Thursday, June 3, 2021 at 2:08:55 AM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > In 30 total gates, and in 4-gates of delay, one can decode My 66000
> > instructions to determine their length, and the offsets in the instruction
> > stream of any constants.
> How many gate delays does a modern architecture usually have per cycle?
> (I know different gates have different delays, but a ballpark figure
> would be very interesting).
<
Really fast machines 12-gates
more typical machines 16-gates
<
> >IBM 360 does this in 2-gates of delay. Both
> > share the advantage that the bits decoded are all fixed over all instruction
> > formats. So, My 66000 is only 2-gates behind at this point.
> ><
> > From here we setup a tree of find next instruction logic (2-gates) and we
> > parse (determine starting word and all constant words) 2 then 4 then 8
> > then 16 instructions at 2-gates of delay each level. So parsing 16 instructions
> > per cycle is a 12-gate delay problem. Easy Peasy in a 16-gate cycle. The
> > original IBM 360 would be 2-gates shorter, the current monstrosity would
> > be longer.
<
> Is 16 gates per cycle particularly short?
<
It is enough to perform an add, drive the result bus and make setup timing
as a forwarded result->operand. 64-bit add = 11-gates. Drive result bus 3-
gates, consume as operand 2-gates.
<
It used to be enough to perform a direct mapped cache hit and load-align
in 2 cycles, it is no longer, the minimum number is 3 cycles. Many of the
really fast machines have gone to 4 cycles to use set associative caches.
<
I prefer a 20-gate per cycle design point. This is slow enough to reuse
the bit lines in the register file reads on 1/2 cycle, writes on the other
1/2 cycle, and slow enough to "hit" cache SRAMs twice per cycle
(solving many porting problems.)
<
With a 20 gate per cycle design point, one can build a 6-wide reservation
station machine with back to back integer, 3 cycle LDs, 3 LDs per cycle,
4 cycle FMAC, 17 cycle FDIV; and 6-ported register files into a 6-7 stage
pipeline.
<
At 16 cycles this necessarily becomes 9-10 stages.
<
At 12 gates this necessarily becomes 12-15 stages.