On Tuesday, April 4, 2023 at 5:36:21 PM UTC-6, Quadibloc wrote:

> I've revisited this issue, and this time, I've discovered that I have enough opcode space
> that I only need to shave *one* bit, not *two*, off of the basic load and store instructions
> to allow the 32-bit instructions to fit in the opcode space left after pairs of 16-bit
> instructions are also allowed.
>
> With one bit, instead of two, removed, I _can_ make a compromise that is acceptable -
> it's all right to have only three base registers for 16-bit displacements, but having three
> index registers instead of seven is a limitation that would impact peformance.

While this was definitely an improvement, I still wanted to do better. Could I shave one
bit off of the memory-reference instructions in a way that would have even _less_ of
an impact?

The first thing I tried was to exclude both registers 0 and 1 as index registers, so that
un-indexed instructions could use all seven possible base registers. However, having
base registers that could only be used for non-indexed access seemed to be of limited
usefulness.

Another old idea I considered was to shorten the destination register field, so that only
some of the registers could communicate with memory. The Control Data 6600 did
that, IIRC.

Finally, I decided to combine the two ideas.

Now, un-indexed memory-reference instructions are without restrictions.

Indexed memory-reference instructions exclude registers 0 and 4 as indexed
registers. (This is because the dR field is in front of the rX field in the instruction,
while the rB field follows it, so lengthening the index register field by one bit when
the destination register field is shortened by one bit puts the additional bit in the
front.)

And while all 32 registers in a register bank can load and store from memory,
only 16 of them can be involved in *indexed* loads and stores from memory. Those
16 are the first four registers of each of the four groups of eight registers into which
the banks of 32 registers are divided (as these four eight-register parts figure prominently in
how 16-bit instructions work, as well as in the allocation of registers for use as base and
index registers).

While it is a bit complicated, it meets my goal of shaving a bit off the instruction format
while having a minimal impact on the power of instructions.

John Savard

On Tuesday, October 24, 2023 at 3:00:35 AM UTC-6, Quadibloc wrote:

> Finally, I decided to combine the two ideas.
>
> Now, un-indexed memory-reference instructions are without restrictions.
>
> Indexed memory-reference instructions exclude registers 0 and 4 as indexed
> registers. (This is because the dR field is in front of the rX field in the instruction,
> while the rB field follows it, so lengthening the index register field by one bit when
> the destination register field is shortened by one bit puts the additional bit in the
> front.)
>
> And while all 32 registers in a register bank can load and store from memory,
> only 16 of them can be involved in *indexed* loads and stores from memory.. Those
> 16 are the first four registers of each of the four groups of eight registers into which
> the banks of 32 registers are divided (as these four eight-register parts figure prominently in
> how 16-bit instructions work, as well as in the allocation of registers for use as base and
> index registers).

This seemed to indeed attain the goal of having a restriction that would not impose an
onerous burden. However, I remembered that there was another possible restriction
that... was almost no restriction at all, at least from my viewpoint.

So I decided to try the following: let's add the other light restriction, the one to four base
registers instead of eight, back in - to save another bit. Will I free up enough opcode space
to allow a full set of aligned load-store instructions?

At first, I thought that, no, not enough space was freed up. But then I saw there was a possibility;
the two forms of load-store instructions _did_ fit in the opcode space of 32-bit instructions starting
with 1.

The only problem was, I didn't have room for conditional jump, subroutine jump, and load/store
multiple register any longer.

But there was free opcode space elsewhere: I had a lot of extra opcode space for operate instructions.

The trouble was, though, that those instructions were fitten in with the 16-bit instructions, so they
didn't have 16 contiguous bits at the end, making this opcode space unsuitable for memory-reference
instructions.

There was a way to fix this, I had tried it before. Just change

(0)
(15-bit instruction body)
(0)
(15 bit instruction body)

to

(00)
(15-bit instruction body)
(15-bit instruction body)

as the format of a pair of 16-bit instructions in a 32-bit word.

Oh, but I didn't want to do that. Everything else in the instruction set respected the
alignment of bits in relation to byte, halfword, and word boundaries.

I came up with an alternative that satisfied all the desiderata. Of course, it was
pure evil, but that hadn't stopped me before...

(0)
(First 7 bits of first instruction)
(0)
(First 7 bits of second instruction)
(Remaining 8 bits of first instruction)
(Remaining 8 bits of second instruction)

was the new format of a pair of 16-bit instructions in a 32-bit word. Only
in the default case - whenever a header is present, indicating a pair of
16-bit instructions with some special feature in in a 32-bit word, then they're
conventionally in the two contiguous 16-bit halves of that word.

Think of the four bytes of a 32-bit word as being in a square...

1 2
3 4

So I'm just putting the two 16-bit instructions in by columns instead of rows!

I mean, it's helpful that I'm very familiar with the history of computing, including
all the bizarre kludges that have been tried in various computer architectures
from time to time... so I know that this sort of thing, or worse, has been done
before...

John Savard

On Wednesday, October 25, 2023 at 5:05:38 AM UTC-6, Quadibloc wrote:
> On Tuesday, October 24, 2023 at 3:00:35 AM UTC-6, Quadibloc wrote:
>
> > Finally, I decided to combine the two ideas.
> >
> > Now, un-indexed memory-reference instructions are without restrictions.
> >
> > Indexed memory-reference instructions exclude registers 0 and 4 as indexed
> > registers. (This is because the dR field is in front of the rX field in the instruction,
> > while the rB field follows it, so lengthening the index register field by one bit when
> > the destination register field is shortened by one bit puts the additional bit in the
> > front.)
> >
> > And while all 32 registers in a register bank can load and store from memory,
> > only 16 of them can be involved in *indexed* loads and stores from memory. Those
> > 16 are the first four registers of each of the four groups of eight registers into which
> > the banks of 32 registers are divided (as these four eight-register parts figure prominently in
> > how 16-bit instructions work, as well as in the allocation of registers for use as base and
> > index registers).
> This seemed to indeed attain the goal of having a restriction that would not impose an
> onerous burden. However, I remembered that there was another possible restriction
> that... was almost no restriction at all, at least from my viewpoint.
>
> So I decided to try the following: let's add the other light restriction, the one to four base
> registers instead of eight, back in - to save another bit. Will I free up enough opcode space
> to allow a full set of aligned load-store instructions?
>
> At first, I thought that, no, not enough space was freed up. But then I saw there was a possibility;
> the two forms of load-store instructions _did_ fit in the opcode space of 32-bit instructions starting
> with 1.
>
> The only problem was, I didn't have room for conditional jump, subroutine jump, and load/store
> multiple register any longer.
>
> But there was free opcode space elsewhere: I had a lot of extra opcode space for operate instructions.
>
> The trouble was, though, that those instructions were fitten in with the 16-bit instructions, so they
> didn't have 16 contiguous bits at the end, making this opcode space unsuitable for memory-reference
> instructions.
>
> There was a way to fix this, I had tried it before. Just change
>
> (0)
> (15-bit instruction body)
> (0)
> (15 bit instruction body)
>
> to
>
> (00)
> (15-bit instruction body)
> (15-bit instruction body)
>
> as the format of a pair of 16-bit instructions in a 32-bit word.
>
> Oh, but I didn't want to do that. Everything else in the instruction set respected the
> alignment of bits in relation to byte, halfword, and word boundaries.
>
> I came up with an alternative that satisfied all the desiderata. Of course, it was
> pure evil, but that hadn't stopped me before...
>
> (0)
> (First 7 bits of first instruction)
> (0)
> (First 7 bits of second instruction)
> (Remaining 8 bits of first instruction)
> (Remaining 8 bits of second instruction)
>
> was the new format of a pair of 16-bit instructions in a 32-bit word. Only
> in the default case - whenever a header is present, indicating a pair of
> 16-bit instructions with some special feature in in a 32-bit word, then they're
> conventionally in the two contiguous 16-bit halves of that word.
>
> Think of the four bytes of a 32-bit word as being in a square...
>
> 1 2
> 3 4
>
> So I'm just putting the two 16-bit instructions in by columns instead of rows!
>
> I mean, it's helpful that I'm very familiar with the history of computing, including
> all the bizarre kludges that have been tried in various computer architectures
> from time to time... so I know that this sort of thing, or worse, has been done
> before...

I did have to give up one small feature. I had to take most - but not all - of the
opcode space away from a special header format I had inclulded to allow near-zero
overhead for immediates.

This was a type of block header that consisted of a three-bit decode field, a register-to-register
operate instruction, and a position field - so that one couid reserve space for short
pointer-referenced pseudo-immediate values, but without the overhead of wasting a whole
32 bits on the header that did this. Instead, one of the instructions that used pseudo-immediates
could include just three bits of overhead... plus an extra three bits for the position field, since
to function as a header, it had to be at the start of the block, while it may be desired to execute
at some other position in the sequence.

Taking away 7/8ths of its opcode space, though, didn't mean that I had to drop the feature. The
allocation for the opcode field was... generous. I just had to drop _one_ feature from it, as now
the opcode field would be too small if the optional field to indicate an alternate condition code set
(shades of the PowerPC) were included.

So I have squeezed the instruction set until it screamed to fit it into the opcode space!

John Savard

While this is not what prompted me to turn my attention to Concertina II again,
it could be considered (well, if one was crazy, at least) that the need for Concertina
II is greater now than ever...

partly because Qualcomm is going to add addressing modes to RISC-V to make it
more competitive to ARM as something useful for smartphones - Concertina II
has addressing modes from CISC, so it lacks nothing there -

but mainly because the U.S. government is reportedly considering banning RISC-V
to prevent Red China from benefiting from U.S. work in that area. So Concertina II
will be an open-source RISC-like ISA still available.

John Savard

I came late to this party, but I wanted to comment on a couple of things I saw:

1) An out of order (very) CISC stack machine was built and sold (using MECL III logic) 30 years ago.
It was called the Unisys A19. It could fuse up to 6 operations into a single "operation" and have
up to 6 of them working in parallel. Unfortunately, the memory interface couldn't keep up with
the CPU execution rate. (And you could configure it with up to 6 CPUs).

2) Unisys also built the "micro-A" series, which was a SCAMP (single chip A-series mainframe processor)
on an expansion card in a 386 system. Unisys sold a bunch of them, they were very popular.
I suspect the PC/370 (and AT/370) were crippled by internal in fighting at IBM.

3) If I ever had the spare (hah!) time to work on my own ISA, I think I would start with a "fat" encoding
of all the instructions (i.e. fixed length, easy to write an emulator for, etc.).
Write the compiler, analyze the output, add/subtract instructions as required, and repeat.
When the ISA feature set had stabilized, THEN I would worry about the actual encoding.
(Yes, I have worked on emulators and compilers. Haven't built any production CPUs, tho...
I know this is not trivial, which is where the spare time comes in :) )

- Tim

On 10/26/2023 8:24 AM, Timothy McCaffrey wrote:
> I came late to this party, but I wanted to comment on a couple of things I saw:
>
> 1) An out of order (very) CISC stack machine was built and sold (using MECL III logic) 30 years ago.
> It was called the Unisys A19. It could fuse up to 6 operations into a single "operation" and have
> up to 6 of them working in parallel. Unfortunately, the memory interface couldn't keep up with
> the CPU execution rate. (And you could configure it with up to 6 CPUs).

I vaguely remember the A19, but I can't find any information on it
online. No mention in the Wikipedia article on Burroughs large scale
systems, nothing at bitsavers, etc. Do you know of any links for more
information?

> 2) Unisys also built the "micro-A" series, which was a SCAMP (single chip A-series mainframe processor)
> on an expansion card in a 386 system. Unisys sold a bunch of them, they were very popular.
> I suspect the PC/370 (and AT/370) were crippled by internal in fighting at IBM.
>
> 3) If I ever had the spare (hah!) time to work on my own ISA, I think I would start with a "fat" encoding
> of all the instructions (i.e. fixed length, easy to write an emulator for, etc.).

But doesn't even that effectively "specify" some things about your ISA?
Specifically, does it include two register specifiers or three? Is it a
stack ISA (I put this in to warm your heart!), does fixed length rule
out handling immediates like Mitch's My66000 does?

> Write the compiler, analyze the output,

While this is very useful, it is very dependent on what program set you
choose to compile. For example, do you expect "commercial" workloads to
be important? Does the importance of scientific workloads justify
instructions for transcendental functions? What about 128 bit floating
point? It also doesn't directly help with things like address range, etc.

> add/subtract instructions as required, and repeat.
> When the ISA feature set had stabilized, THEN I would worry about the actual encoding.

Agreed. You have to make some other basic decisions first.

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

On Thursday, October 26, 2023 at 10:24:53 AM UTC-5, Timothy McCaffrey wrote:
> I came late to this party, but I wanted to comment on a couple of things I saw:
>
> 1) An out of order (very) CISC stack machine was built and sold (using MECL III logic) 30 years ago.
> It was called the Unisys A19. It could fuse up to 6 operations into a single "operation" and have
> up to 6 of them working in parallel. Unfortunately, the memory interface couldn't keep up with
> the CPU execution rate. (And you could configure it with up to 6 CPUs).
>
> 2) Unisys also built the "micro-A" series, which was a SCAMP (single chip A-series mainframe processor)
> on an expansion card in a 386 system. Unisys sold a bunch of them, they were very popular.
> I suspect the PC/370 (and AT/370) were crippled by internal in fighting at IBM.
>
> 3) If I ever had the spare (hah!) time to work on my own ISA, I think I would start with a "fat" encoding
> of all the instructions (i.e. fixed length, easy to write an emulator for, etc.).
<
That is the intent of My 66000 encoding--the ability to express succinctly what the compiler
wants to produce, and a way of encoding this succinctly. However, I started at classical
RISC and then expanded with constants so the first clause above was maifest..
<
> Write the compiler, analyze the output, add/subtract instructions as required, and repeat.
<
There is NO SUBSTITUTE for reading the code of your architecture out of your compiler.
How else do you find those warts that is hard to perform in HW AND simultaneously
hard to use in the compiler.
<
> When the ISA feature set had stabilized, THEN I would worry about the actual encoding.
<
Because I started with RISC and took on the notion that I would have RISC instruction
set but waste no instruction in pasting of constants, this forced me to find a suitable
encoding (or instruction modifiers) first and then build-out the rest of ISA.
<
> (Yes, I have worked on emulators and compilers. Haven't built any production CPUs, tho...
> I know this is not trivial, which is where the spare time comes in :) )
>
> - Tim

On 10/26/2023 12:14 PM, MitchAlsup wrote:
> On Thursday, October 26, 2023 at 10:24:53 AM UTC-5, Timothy McCaffrey wrote:
>> I came late to this party, but I wanted to comment on a couple of things I saw:
>>
>> 1) An out of order (very) CISC stack machine was built and sold (using MECL III logic) 30 years ago.
>> It was called the Unisys A19. It could fuse up to 6 operations into a single "operation" and have
>> up to 6 of them working in parallel. Unfortunately, the memory interface couldn't keep up with
>> the CPU execution rate. (And you could configure it with up to 6 CPUs).
>>
>> 2) Unisys also built the "micro-A" series, which was a SCAMP (single chip A-series mainframe processor)
>> on an expansion card in a 386 system. Unisys sold a bunch of them, they were very popular.
>> I suspect the PC/370 (and AT/370) were crippled by internal in fighting at IBM.
>>
>> 3) If I ever had the spare (hah!) time to work on my own ISA, I think I would start with a "fat" encoding
>> of all the instructions (i.e. fixed length, easy to write an emulator for, etc.).
> <
> That is the intent of My 66000 encoding--the ability to express succinctly what the compiler
> wants to produce, and a way of encoding this succinctly. However, I started at classical
> RISC and then expanded with constants so the first clause above was maifest.
> <
>> Write the compiler, analyze the output, add/subtract instructions as required, and repeat.
> <
> There is NO SUBSTITUTE for reading the code of your architecture out of your compiler.
> How else do you find those warts that is hard to perform in HW AND simultaneously
> hard to use in the compiler.

And find common sequences of generated instructions that could benefit
from a way of reworking the existing instructions, or adding a new one,
that would provide performance benefit.

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

On Thursday, October 26, 2023 at 12:05:49 PM UTC-6, Stephen Fuld wrote:

> I vaguely remember the A19, but I can't find any information on it
> online.

I had only heard of it today. I was able to find out online that it was announced
in March 1991, and that Unisys actually did sell some of them. Although there
was no detailed technical information, I did learn it was part of their mainframe
series, compatible with the others, and it was air-cooled.

John Savard

On 10/26/2023 10:24 AM, Timothy McCaffrey wrote:
> I came late to this party, but I wanted to comment on a couple of things I saw:
>
> 1) An out of order (very) CISC stack machine was built and sold (using MECL III logic) 30 years ago.
> It was called the Unisys A19. It could fuse up to 6 operations into a single "operation" and have
> up to 6 of them working in parallel. Unfortunately, the memory interface couldn't keep up with
> the CPU execution rate. (And you could configure it with up to 6 CPUs).
>

FWIW: In my own "try to make my stuff run at 75MHz" sub-project, there
are a few big areas currently eating cycles:
DRAM access;
Interlocks (register RAW stalls);
L1 cache misses;
Branches.

After stat'ing for it, it seems that the branch predictor is also
"fairly important" for performance. But, the main sacrifice made to get
up to these speeds (increasing the latency of most of the 1-cycle
instructions to 2 cycle), has not come for free.

I did add stats for the QMUL unit (64-bit multiply, integer divide), not
much issue here. It appears thus far like FPU isn't too significant of a
limitation (I thought it was, but this was more because I had gotten the
stats display signals wrong; and my "Misc" stat was actually reporting
"L1 Misses without DRAM or MMIO access", which was not the intention).

As-is, it seems it is mostly interlock penalties and RAM access fighting
for the top spot, with branches typically in third place (if the branch
predictor is working/enabled).

It appears thus far Quake isn't really all that much faster than before.
Though, Doom and similar sees a more significant speedup, as does Dhrystone.

Doom: around 25-34 fps typical (vs ~ 16-25 at 50MHz);
Dhrystone: Around 130k.

Though, the 50MHz configuration would still be a win in terms of
FP-SIMD, as getting my 4x Binary32 SIMD unit to pass timing at 75MHz is
still a bit of a stretch.

> 2) Unisys also built the "micro-A" series, which was a SCAMP (single chip A-series mainframe processor)
> on an expansion card in a 386 system. Unisys sold a bunch of them, they were very popular.
> I suspect the PC/370 (and AT/370) were crippled by internal in fighting at IBM.
>
> 3) If I ever had the spare (hah!) time to work on my own ISA, I think I would start with a "fat" encoding
> of all the instructions (i.e. fixed length, easy to write an emulator for, etc.).
> Write the compiler, analyze the output, add/subtract instructions as required, and repeat.
> When the ISA feature set had stabilized, THEN I would worry about the actual encoding.
> (Yes, I have worked on emulators and compilers. Haven't built any production CPUs, tho...
> I know this is not trivial, which is where the spare time comes in :) )
>

For me, all of this is a bit of a hobby project.

Would be nice if it could be "actually useful" though.
It seemed like there was a bit more interest at some point (in terms of
GitHub clones, etc), but it seems like this has mostly died down now.

In my case, some amount of the ISA design was driven in part by my
compiler effort, and by testing stuff in my emulator (with some modeling
to predict its effectiveness). Some amount of the Verilog coding was
more to verify if features were affordable, realistic, and could pass
timing.

Though, was mostly working at 50MHz for most of this, and some things
which work OK at 50MHz seem to be more of a problem at 75MHz (like, the
96-bit virtual address-support, fast FP-SIMD, or 128-bit ALU ops).

Generally more reasonable if one sticks with 48-bit addressing and
64-bit ALU in this case (and, I am back to using 33 bit displacements as
well, ...).

Some amount of cruft has built up, and some early design decisions were
not so useful in retrospect (for example, there are some redundant 2R
encodings for instructions that can otherwise be done using 3R
instructions).

Like, say, one doesn't need a 2R encoding for:
ADD Rs, Rn
When one can just as easily use:
ADD Rn, Rs, Rn
But, then one needs to go through the cost/benefit analysis of removing
these (need to make sure the compiler can't emit them, and they are not
in use, before I can remove them; and even if I did, they wont really
save any logic, for sake of all the other 2R instructions which do, in
fact, also need to make use of the same logic).

However, in my most recent effort, did prune the JT/JF instructions, as
they were basically unused, had non-zero cost, and the same
functionality can be encoded as "JMP?T Reg" instead (similar to how the
BT/BF Disp20 encodings were dropped in favor of encoding them as
"BRA?{T/F} Disp20" instead, just sticking with the original mnemonics).

At least as far as timing goes, it seems like my encoding may already be
a bit on the complicated side.

Mostly, it seems the handling and MUX'ing of the register fields within
bundles is an issue (partly as a drawback of the lane-ordering scheme),
as well as the handling of the high order bits.

So, say, basic 32-bit op (as bits, per 16-bit word):
111p-ZwZZ-nnnn-mmmm ZZZZ-qnmo-oooo-ZZZZ //3R
111p-ZwZZ-nnnn-mmmm ZZZZ-qnmi-iiii-iiii //3RI, Imm9
111p-ZwZZ-nnnn-ZZZZ ZZZZ-qnii-iiii-iiii //2RI, Imm10
111p-ZwZZ-ZZZn-nnnn iiii-iiii-iiii-iiii //2RI, Imm16
111p-ZwZZ-iiii-iiii ZZZZ-iiii-iiii-iiii //Disp20

But, here, one can see there are effectively 5 bits for registers.
In expanding the ISA to 64-bit registers, 3 different encoding schemes
emerged:
1111-1111-Wnmi-0000 0000-kkkk-jjjj-jjjj -
111p-ZwZZ-nnnn-mmmm ZZZZ-qnmo-oooo-ZZZZ //3R, Op64

0111-wnmo-nnnn-mmmm ZZZZ-qnmo-oooo-ZZZZ //3R (XGPR)
1001-wnmZ-nnnn-mmmm ZZZZ-qnmi-iiii-iiii //3RI, Imm9 (XGPR)

And, XG2:
NMOp-ZwZZ-nnnn-mmmm ZZZZ-qnmo-oooo-ZZZZ //3R
NMIp-ZwZZ-nnnn-mmmm ZZZZ-qnmi-iiii-iiii //3RI, Imm10
NMIp-ZwZZ-nnnn-ZZZZ ZZZZ-qnii-iiii-iiii //2RI, Imm11
NZZp-ZwZZ-ZZZn-nnnn iiii-iiii-iiii-iiii //2RI, Imm16
ZZZp-ZwZZ-iiii-iiii ZZZZ-iiii-iiii-iiii //Disp20
Or, Possible:
IIIp-ZwZZ-iiii-iiii ZZZZ-iiii-iiii-iiii //Disp23

But, this seems to add a few extra LUT levels to the paths for unpacking
the registers, which is not ideal (along with all the logic to MUX
everything around to put the correct register fields into the correct
ports for the register file, depending on the instruction being performed).

Some latency could be avoided by going over exclusively to XG2, and
dropping some edge case features (such as the original SWAP/SWCP family
of instructions which implement hard-wired SIMD shuffles before I later
added generic shuffle ops, etc).

However, this would break binary compatibility with my existing code,
and would negatively effect code-density (the original form of my ISA
does generally get better code density than my XG2 variant, due mostly
to it still including 16-bit ops).

Though, most of the "savings" would be due to trimming down on stuff
that is not ideal for FPGA timing so probably, trimming things back to
being closer to a scalar RISC design (or, maybe, more seriously consider
the 2-wide profile with a 4R2W register file).

It seems, RISC-V may have a partial advantage here:
Register field bits don't change around so much (excluding RVC, which is
a mess);
A given immediate bit is usually in the same position in every instruction.

Though, instead, pretty much the whole rest of the encoding moves around
the register fields; and the immediate fields tend to be significantly
dog-chewed (very painfully obvious in the branch instructions).

It also implicitly assumes a particular way to route the ports to each
function unit, which causes the former advantage to be lost if the FU's
don't all operate in the same way as assumed by the ISA design, ...

But, if one allows the register port assignments to "float around" to
some extent (as it is in my case), then this advantage is lost (it is
also lost as soon as the ISA supports any sort of "compressed" 16-bit
instructions).

Also, ironically, despite RISC-V having larger displacements, its use of
signed unscaled displacements on average means slightly less usable
displacement range than in BJX2.

Say, for example, a scaled Disp9u, for QWORD, can address 0..4088 bytes,
which is more than 2040 (and negative LD/ST displacements are uncommon
enough to be mostly ignored; though, I ended up expanding these
displacements effectively to 10-bit signed in XG2, since negative
displacements did slightly win out over stack-frames and structures
larger than 4K).

But, then I guess, one can debate the cost and latency of having the
logic to scale the index or displacement.

However, the existing Imm{9/10}{u/n} fields had instead increased by 1
bit, as for most other ops, Imm9u->Imm10u seemed to be better than
Imm9u->Imm10s (though, most ops that had a need for one-extended
encodings, already had explicitly one-extended instruction forms; and
those which lack them typically don't need them).

I guess, it could be possible to debate whether it would make sense to
use the extra register bits to stretch the Disp20 in XG2 mode to 23 bits
(using more inverted-XOR trickery), increasing the branch reach from +/-
1MB to 8MB (either this, or using it to support an auxiliary link
register, like in RISC-V; possibly with a 4MB limit).

On Thursday, October 26, 2023 at 3:01:55 PM UTC-5, Stephen Fuld wrote:
> On 10/26/2023 12:14 PM, MitchAlsup wrote:
> > On Thursday, October 26, 2023 at 10:24:53 AM UTC-5, Timothy McCaffrey wrote:
> >> I came late to this party, but I wanted to comment on a couple of things I saw:
> >>
> >> 1) An out of order (very) CISC stack machine was built and sold (using MECL III logic) 30 years ago.
> >> It was called the Unisys A19. It could fuse up to 6 operations into a single "operation" and have
> >> up to 6 of them working in parallel. Unfortunately, the memory interface couldn't keep up with
> >> the CPU execution rate. (And you could configure it with up to 6 CPUs)..
> >>
> >> 2) Unisys also built the "micro-A" series, which was a SCAMP (single chip A-series mainframe processor)
> >> on an expansion card in a 386 system. Unisys sold a bunch of them, they were very popular.
> >> I suspect the PC/370 (and AT/370) were crippled by internal in fighting at IBM.
> >>
> >> 3) If I ever had the spare (hah!) time to work on my own ISA, I think I would start with a "fat" encoding
> >> of all the instructions (i.e. fixed length, easy to write an emulator for, etc.).
> > <
> > That is the intent of My 66000 encoding--the ability to express succinctly what the compiler
> > wants to produce, and a way of encoding this succinctly. However, I started at classical
> > RISC and then expanded with constants so the first clause above was maifest.
> > <
> >> Write the compiler, analyze the output, add/subtract instructions as required, and repeat.
> > <
> > There is NO SUBSTITUTE for reading the code of your architecture out of your compiler.
> > How else do you find those warts that is hard to perform in HW AND simultaneously
> > hard to use in the compiler.
<
> And find common sequences of generated instructions that could benefit
> from a way of reworking the existing instructions, or adding a new one,
> that would provide performance benefit.
<
Yes, this is how ENTER, EXIT got spawned out of STM and LDM;
and how JTT (jump through table) was invented;
And how message passing works.
<
But not exactly how VEC-LOOP or CALL-indirect was invented/
instantiated in ISA. These had to go back to fundamentals below
the instructions in ISA--and to a certain extent violate vonNeumann-
ship.
<
But beyond ISA, a modern architecture should have a minimal surface
on which attacks vectors such as Sprecté, Meltdown, RoP, buffer overflow,
.... are played. Certain architectural rules prevent these attack vectors
and many more.
<
A modern architecture should have a minimal surface on which context
switching is manifest, and than much of the interrupt/exception/supervisior
control transfers transpire only takes 1-effective instruction. The register
file(s) should be dragged along with the operating context {PSD, CR3,...}
as if they were associated at the hip.
<
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On 10/26/2023 3:01 PM, Stephen Fuld wrote:
> On 10/26/2023 12:14 PM, MitchAlsup wrote:
>> On Thursday, October 26, 2023 at 10:24:53 AM UTC-5, Timothy McCaffrey
>> wrote:
>>> I came late to this party, but I wanted to comment on a couple of
>>> things I saw:
>>>
>>> 1) An out of order (very) CISC stack machine was built and sold
>>> (using MECL III logic) 30 years ago.
>>> It was called the Unisys A19. It could fuse up to 6 operations into a
>>> single "operation" and have
>>> up to 6 of them working in parallel. Unfortunately, the memory
>>> interface couldn't keep up with
>>> the CPU execution rate. (And you could configure it with up to 6 CPUs).
>>>
>>> 2) Unisys also built the "micro-A" series, which was a SCAMP (single
>>> chip A-series mainframe processor)
>>> on an expansion card in a 386 system. Unisys sold a bunch of them,
>>> they were very popular.
>>> I suspect the PC/370 (and AT/370) were crippled by internal in
>>> fighting at IBM.
>>>
>>> 3) If I ever had the spare (hah!) time to work on my own ISA, I think
>>> I would start with a "fat" encoding
>>> of all the instructions (i.e. fixed length, easy to write an emulator
>>> for, etc.).
>> <
>> That is the intent of My 66000 encoding--the ability to express
>> succinctly what the compiler
>> wants to produce, and a way of encoding this succinctly. However, I
>> started at classical
>> RISC and then expanded with constants so the first clause above was
>> maifest.
>> <
>>> Write the compiler, analyze the output, add/subtract instructions as
>>> required, and repeat.
>> <
>> There is NO SUBSTITUTE for reading the code of your architecture out
>> of your compiler.
>> How else do you find those warts that is hard to perform in HW AND
>> simultaneously
>> hard to use in the compiler.
>
> And find common sequences of generated instructions that could benefit
> from a way of reworking the existing instructions, or adding a new one,
> that would provide performance benefit.
>

This was also a practice in my case, but sometimes this is limited not
so much by limitations in the available instructions, so much as playing
"whack-a-mole" within the compiler (like, the seemingly sometimes futile
effort to eliminate pointless register-register MOV instructions and
similar).

Like, a human writing ASM has this amazing ability to realize that a
value going into one register, and then immediately being moved into
another register (with the original register not being touched again)
can be replaced by just targeting the final register. Or, that a value
being cast to a type which doesn't actually require any format
conversion, can be skipped and the original register used directly.

But, asking this from my compiler, seems to be asking too much sometimes
(and, hard to avoid casts in some cases, without indirectly creating
other cases where the cast did actually matter and which results in
bugs, ...).

Well, along with cases where the compiler still produces stale
instruction sequences, but where I had yet to find and weed out the source.

For example, I have:
SHAR Rm, Ro, Rn
Yet, still sometimes see:
NEG Ro, Rtmp
SHAD Rm, Rtmp, Rn
Despite this now being pointless and unnecessary (and despite my
attempts to weed a lot of these cases out of the compiler).

But, as code gets more big and hairy, it becomes more difficult to weed
out these sorts of cases (and one needs to be increasingly more
conservative to avoid fixing something in one case, breaking something
somewhere else).

Along with various other hair as remnants of earlier forms of the ISA
where things didn't work as nicely.

But, a full rewrite of my codegen backend (to bring everything more in
line with the ISA as it exists now) would not be a small effort (and
would likely involve its own mountain of debugging).

Doesn't help that my original approach to the design of the compiler
backend sort of made sense with SH-4, but no longer makes sense. Not
necessarily helped by an early original assumption that I would not
have, and thus had no need to bother with, an assembler or linker (but,
now these are just sort of awkwardly glued onto the side of trying to
generate code from the 3AC; but, would have been better if they were
their own stages).

Actually, a proper "ASM" stage would have more opened the possibility of
using a peephole optimizer on the intermediate instructions, which could
have potentially pruned away some more of the pointless MOV's and similar...

But, alas...

On Thursday, October 26, 2023 at 5:45:55 PM UTC-4, BGB wrote:
> On 10/26/2023 3:01 PM, Stephen Fuld wrote:
> > On 10/26/2023 12:14 PM, MitchAlsup wrote:
> >> On Thursday, October 26, 2023 at 10:24:53 AM UTC-5, Timothy McCaffrey
> >> wrote:
> >>> I came late to this party, but I wanted to comment on a couple of
> >>> things I saw:
> >>>
> >>> 1) An out of order (very) CISC stack machine was built and sold
> >>> (using MECL III logic) 30 years ago.
> >>> It was called the Unisys A19. It could fuse up to 6 operations into a
> >>> single "operation" and have
> >>> up to 6 of them working in parallel. Unfortunately, the memory
> >>> interface couldn't keep up with
> >>> the CPU execution rate. (And you could configure it with up to 6 CPUs).
> >>>
> >>> 2) Unisys also built the "micro-A" series, which was a SCAMP (single
> >>> chip A-series mainframe processor)
> >>> on an expansion card in a 386 system. Unisys sold a bunch of them,
> >>> they were very popular.
> >>> I suspect the PC/370 (and AT/370) were crippled by internal in
> >>> fighting at IBM.
> >>>
> >>> 3) If I ever had the spare (hah!) time to work on my own ISA, I think
> >>> I would start with a "fat" encoding
> >>> of all the instructions (i.e. fixed length, easy to write an emulator
> >>> for, etc.).
> >> <
> >> That is the intent of My 66000 encoding--the ability to express
> >> succinctly what the compiler
> >> wants to produce, and a way of encoding this succinctly. However, I
> >> started at classical
> >> RISC and then expanded with constants so the first clause above was
> >> maifest.
> >> <
> >>> Write the compiler, analyze the output, add/subtract instructions as
> >>> required, and repeat.
> >> <
> >> There is NO SUBSTITUTE for reading the code of your architecture out
> >> of your compiler.
> >> How else do you find those warts that is hard to perform in HW AND
> >> simultaneously
> >> hard to use in the compiler.
> >
> > And find common sequences of generated instructions that could benefit
> > from a way of reworking the existing instructions, or adding a new one,
> > that would provide performance benefit.
> >
> This was also a practice in my case, but sometimes this is limited not
> so much by limitations in the available instructions, so much as playing
> "whack-a-mole" within the compiler (like, the seemingly sometimes futile
> effort to eliminate pointless register-register MOV instructions and
> similar).
>
> Like, a human writing ASM has this amazing ability to realize that a
> value going into one register, and then immediately being moved into
> another register (with the original register not being touched again)
> can be replaced by just targeting the final register. Or, that a value
> being cast to a type which doesn't actually require any format
> conversion, can be skipped and the original register used directly.
>
> But, asking this from my compiler, seems to be asking too much sometimes
> (and, hard to avoid casts in some cases, without indirectly creating
> other cases where the cast did actually matter and which results in
> bugs, ...).
>
>
> Well, along with cases where the compiler still produces stale
> instruction sequences, but where I had yet to find and weed out the source.
>
> For example, I have:
> SHAR Rm, Ro, Rn
> Yet, still sometimes see:
> NEG Ro, Rtmp
> SHAD Rm, Rtmp, Rn
> Despite this now being pointless and unnecessary (and despite my
> attempts to weed a lot of these cases out of the compiler).
>
> But, as code gets more big and hairy, it becomes more difficult to weed
> out these sorts of cases (and one needs to be increasingly more
> conservative to avoid fixing something in one case, breaking something
> somewhere else).
>
>
> Along with various other hair as remnants of earlier forms of the ISA
> where things didn't work as nicely.
>
> But, a full rewrite of my codegen backend (to bring everything more in
> line with the ISA as it exists now) would not be a small effort (and
> would likely involve its own mountain of debugging).
>
> Doesn't help that my original approach to the design of the compiler
> backend sort of made sense with SH-4, but no longer makes sense. Not
> necessarily helped by an early original assumption that I would not
> have, and thus had no need to bother with, an assembler or linker (but,
> now these are just sort of awkwardly glued onto the side of trying to
> generate code from the 3AC; but, would have been better if they were
> their own stages).
>
> Actually, a proper "ASM" stage would have more opened the possibility of
> using a peephole optimizer on the intermediate instructions, which could
> have potentially pruned away some more of the pointless MOV's and similar....
>
>
> But, alas...

I think things must be developed in concert. The ISA, compiler, and the code for
hardware all developed at the same time. Much of these components do not
depend on other components so a lot can be done in parallel. There still needs
to be feedback between the components. I believe in taking an eclectic mix of
instructions from other architectures.

The most recent change to my Thor ISA was to make conditional branch
displacements in terms of instructions rather than bytes. This means
multiplying the displacement constant by five. It amounts to a three-input
adder for the displacement rather than two-input. I then also used some of
the displacement range (top nibble 7 or 8) to indicate branch-to-register and
micro-code address branches. Previously Thor had separate instructions for
these, so the number of instructions has been reduced, and opcodes freed
up, while supporting a greater number of branches. The conditional branch
range is a somewhat strange plus or minus 280kB. Roughly equal to 19 bits.

I have made this change after much of the ISA is fixed, and large parts of the
assembler written. I changed it because I realized that micro-code branches
did not support a full set of branches. I hit the “How am I going to approach
this?” question while coding micro-code.

On Thursday, October 26, 2023 at 4:45:55 PM UTC-5, BGB wrote:
> On 10/26/2023 3:01 PM, Stephen Fuld wrote:
> > On 10/26/2023 12:14 PM, MitchAlsup wrote:
> >> On Thursday, October 26, 2023 at 10:24:53 AM UTC-5, Timothy McCaffrey
> >> wrote:
> >>> I came late to this party, but I wanted to comment on a couple of
> >>> things I saw:
> >>>
> >>> 1) An out of order (very) CISC stack machine was built and sold
> >>> (using MECL III logic) 30 years ago.
> >>> It was called the Unisys A19. It could fuse up to 6 operations into a
> >>> single "operation" and have
> >>> up to 6 of them working in parallel. Unfortunately, the memory
> >>> interface couldn't keep up with
> >>> the CPU execution rate. (And you could configure it with up to 6 CPUs).
> >>>
> >>> 2) Unisys also built the "micro-A" series, which was a SCAMP (single
> >>> chip A-series mainframe processor)
> >>> on an expansion card in a 386 system. Unisys sold a bunch of them,
> >>> they were very popular.
> >>> I suspect the PC/370 (and AT/370) were crippled by internal in
> >>> fighting at IBM.
> >>>
> >>> 3) If I ever had the spare (hah!) time to work on my own ISA, I think
> >>> I would start with a "fat" encoding
> >>> of all the instructions (i.e. fixed length, easy to write an emulator
> >>> for, etc.).
> >> <
> >> That is the intent of My 66000 encoding--the ability to express
> >> succinctly what the compiler
> >> wants to produce, and a way of encoding this succinctly. However, I
> >> started at classical
> >> RISC and then expanded with constants so the first clause above was
> >> maifest.
> >> <
> >>> Write the compiler, analyze the output, add/subtract instructions as
> >>> required, and repeat.
> >> <
> >> There is NO SUBSTITUTE for reading the code of your architecture out
> >> of your compiler.
> >> How else do you find those warts that is hard to perform in HW AND
> >> simultaneously
> >> hard to use in the compiler.
> >
> > And find common sequences of generated instructions that could benefit
> > from a way of reworking the existing instructions, or adding a new one,
> > that would provide performance benefit.
> >
> This was also a practice in my case, but sometimes this is limited not
> so much by limitations in the available instructions, so much as playing
> "whack-a-mole" within the compiler (like, the seemingly sometimes futile
> effort to eliminate pointless register-register MOV instructions and
> similar).
>
> Like, a human writing ASM has this amazing ability to realize that a
> value going into one register, and then immediately being moved into
> another register (with the original register not being touched again)
> can be replaced by just targeting the final register. Or, that a value
> being cast to a type which doesn't actually require any format
> conversion, can be skipped and the original register used directly.
>
> But, asking this from my compiler, seems to be asking too much sometimes
> (and, hard to avoid casts in some cases, without indirectly creating
> other cases where the cast did actually matter and which results in
> bugs, ...).
>
Perhaps it is time for less work on the FPGA and more on the compiler.
>
> Well, along with cases where the compiler still produces stale
> instruction sequences, but where I had yet to find and weed out the source.
>
> For example, I have:
> SHAR Rm, Ro, Rn
> Yet, still sometimes see:
> NEG Ro, Rtmp
> SHAD Rm, Rtmp, Rn
> Despite this now being pointless and unnecessary (and despite my
> attempts to weed a lot of these cases out of the compiler).
<
----------------------------------------------------------------------------------------------------------------------------------
>
> But, as code gets more big and hairy, it becomes more difficult to weed
> out these sorts of cases (and one needs to be increasingly more
> conservative to avoid fixing something in one case, breaking something
> somewhere else).
>
It is more like a Jr. High School student trying to understand the nuances of
Shakespeare (more difficult to weed out) compared to more straightforward
plots like Agatha Christie.
>
> Along with various other hair as remnants of earlier forms of the ISA
> where things didn't work as nicely.
<
Such as spelling LD as MOV and ST as MOV also.
>
> But, a full rewrite of my codegen backend (to bring everything more in
> line with the ISA as it exists now) would not be a small effort (and
> would likely involve its own mountain of debugging).
<
But it will illuminate what is not quite there yet with your design.
>
> Doesn't help that my original approach to the design of the compiler
> backend sort of made sense with SH-4, but no longer makes sense. Not
> necessarily helped by an early original assumption that I would not
> have, and thus had no need to bother with, an assembler or linker (but,
> now these are just sort of awkwardly glued onto the side of trying to
> generate code from the 3AC; but, would have been better if they were
> their own stages).
>
> Actually, a proper "ASM" stage would have more opened the possibility of
> using a peephole optimizer on the intermediate instructions, which could
> have potentially pruned away some more of the pointless MOV's and similar....
>
Captain Obvious strikes again...........
>
> But, alas...

On Thursday, October 26, 2023 at 5:46:10 PM UTC-5, robf...@gmail.com wrote:
>
> I think things must be developed in concert. The ISA, compiler, and the code for
> hardware all developed at the same time. Much of these components do not
> depend on other components so a lot can be done in parallel. There still needs
> to be feedback between the components. I believe in taking an eclectic mix of
> instructions from other architectures.
<
First of all:: well stated.
<
Second of all:: we all understand that there 50-ish instruction basis. (11 LD+ST,
7-ish Integer, 7-ish Logical, 5-ish Shift, 10-ish FP, and 6-ish flow control)
<
Most of the rest is how one routes results back into operands and how
one expresses that in ISA.
>
> The most recent change to my Thor ISA was to make conditional branch
> displacements in terms of instructions rather than bytes. This means
> multiplying the displacement constant by five. It amounts to a three-input
> adder for the displacement rather than two-input.
<
It is unreasonable to expect that this (all by itself) will cost you any delay
in any microarchitecture. So, consider it free. It is certainly not more than
1 gate of delay.
<
> I then also used some of
> the displacement range (top nibble 7 or 8) to indicate branch-to-register and
> micro-code address branches. Previously Thor had separate instructions for
> these, so the number of instructions has been reduced, and opcodes freed
> up, while supporting a greater number of branches. The conditional branch
> range is a somewhat strange plus or minus 280kB. Roughly equal to 19 bits..
<
I hid {message-instructions, SVC, SVR, and ATOMIC queries} in BC, too. Real-
estate in ISA is precious; Use it wisely.
>
> I have made this change after much of the ISA is fixed, and large parts of the
> assembler written. I changed it because I realized that micro-code branches
> did not support a full set of branches. I hit the “How am I going to approach
> this?” question while coding micro-code.
<
Can I ask what in ISA or Thor is pushing you towards µCode ??
<
For myself, I have FP sequencers that are in charge of SQRT, FDIV, SIN, COS, TAN,
LN, EXP, POW. I also have memory sequencers to do LDM, STM, MM, ENTER, and
EXIT. I also have HW table walkers for TLBs..........
None of that is even remotely associated with microcode (as Wilkes defined it).
<
So, what is pushing you to interrupt the FETCH-DECODE path with microcode ??

On 10/26/2023 9:27 PM, MitchAlsup wrote:
> On Thursday, October 26, 2023 at 4:45:55 PM UTC-5, BGB wrote:
>> On 10/26/2023 3:01 PM, Stephen Fuld wrote:
>>> On 10/26/2023 12:14 PM, MitchAlsup wrote:
>>>> On Thursday, October 26, 2023 at 10:24:53 AM UTC-5, Timothy McCaffrey
>>>> wrote:
>>>>> I came late to this party, but I wanted to comment on a couple of
>>>>> things I saw:
>>>>>
>>>>> 1) An out of order (very) CISC stack machine was built and sold
>>>>> (using MECL III logic) 30 years ago.
>>>>> It was called the Unisys A19. It could fuse up to 6 operations into a
>>>>> single "operation" and have
>>>>> up to 6 of them working in parallel. Unfortunately, the memory
>>>>> interface couldn't keep up with
>>>>> the CPU execution rate. (And you could configure it with up to 6 CPUs).
>>>>>
>>>>> 2) Unisys also built the "micro-A" series, which was a SCAMP (single
>>>>> chip A-series mainframe processor)
>>>>> on an expansion card in a 386 system. Unisys sold a bunch of them,
>>>>> they were very popular.
>>>>> I suspect the PC/370 (and AT/370) were crippled by internal in
>>>>> fighting at IBM.
>>>>>
>>>>> 3) If I ever had the spare (hah!) time to work on my own ISA, I think
>>>>> I would start with a "fat" encoding
>>>>> of all the instructions (i.e. fixed length, easy to write an emulator
>>>>> for, etc.).
>>>> <
>>>> That is the intent of My 66000 encoding--the ability to express
>>>> succinctly what the compiler
>>>> wants to produce, and a way of encoding this succinctly. However, I
>>>> started at classical
>>>> RISC and then expanded with constants so the first clause above was
>>>> maifest.
>>>> <
>>>>> Write the compiler, analyze the output, add/subtract instructions as
>>>>> required, and repeat.
>>>> <
>>>> There is NO SUBSTITUTE for reading the code of your architecture out
>>>> of your compiler.
>>>> How else do you find those warts that is hard to perform in HW AND
>>>> simultaneously
>>>> hard to use in the compiler.
>>>
>>> And find common sequences of generated instructions that could benefit
>>> from a way of reworking the existing instructions, or adding a new one,
>>> that would provide performance benefit.
>>>
>> This was also a practice in my case, but sometimes this is limited not
>> so much by limitations in the available instructions, so much as playing
>> "whack-a-mole" within the compiler (like, the seemingly sometimes futile
>> effort to eliminate pointless register-register MOV instructions and
>> similar).
>>
>> Like, a human writing ASM has this amazing ability to realize that a
>> value going into one register, and then immediately being moved into
>> another register (with the original register not being touched again)
>> can be replaced by just targeting the final register. Or, that a value
>> being cast to a type which doesn't actually require any format
>> conversion, can be skipped and the original register used directly.
>>
>> But, asking this from my compiler, seems to be asking too much sometimes
>> (and, hard to avoid casts in some cases, without indirectly creating
>> other cases where the cast did actually matter and which results in
>> bugs, ...).
>>
> Perhaps it is time for less work on the FPGA and more on the compiler.

I have probably spent a lot more time, overall, on the compiler, than I
have on the FPGA / Verilog side of things.

Line count in Verilog: 188 kLOC

Line count in my compiler: 277 kLOC
Of this:
103 kLOC represents the BJX2 codegen backend
or ~ 37% of the total code.
49 kLOC mostly related to the "middle stages" (1).
17 kLOC for the preprocessor and parser.
20 kLOC, memory management and utility code.
...

For reference, my emulator is ~ 64 kLOC of C.

*1: The AST->RIL and RIL->3AC stages were partly mashed together as at
one point I thought RIL was going to go away. Then I realized I needed
*some* way to support static-linked libraries (and pulling in the C
library as a big blob of C source files would be stupid). So, RIL did
not go away, but now the code for these two stages is just sort of
awkwardly mashed together.

The Verilog also tends to be a lot more verbose as well, since generally
half the module it seems ends up being register declarations and
similar, and "trivial" tasks tend to end up needing significant amounts
of code.

But, the goal for the Verilog initially was to try to have a relatively
"simplistic" design that could perform well. To that end, it needs good
generation, and my compiler's code generation tends to be "kinda weak"
much of the time.

>>
>> Well, along with cases where the compiler still produces stale
>> instruction sequences, but where I had yet to find and weed out the source.
>>
>> For example, I have:
>> SHAR Rm, Ro, Rn
>> Yet, still sometimes see:
>> NEG Ro, Rtmp
>> SHAD Rm, Rtmp, Rn
>> Despite this now being pointless and unnecessary (and despite my
>> attempts to weed a lot of these cases out of the compiler).
> <
> ----------------------------------------------------------------------------------------------------------------------------------

Should probably have specified, this would be for:
Rn = Rm >> Ro;

So, the development was, say:
SH-4:
MOV Rm, Rn
NEG Ro, Rt
SHAD Rt, Rn
Early BJX2 (SHAD became 3R):
NEG Ro, Rt
SHAD Rm, Rt, Rn
Current BJX2:
SHAR Rm, Ro, Rn

Mostly because it was preferable to not need to negate the shift
direction for right shifts, and instead have an instruction where the
shift-unit could be told to shift in the other direction.

Looking stuff up, it seems the origin of the SHAD and SHLD mnemonics was
likely itself specific to SuperH... (either that or Google being
uncooperative; where it is starting to seem sometimes as if Google is
gradually failing at "search for stuff" and instead more intent on
trying to "spelling correct" ones search terms and pull up a bunch of
results for unrelated "online marketplace" sites and similar).

"But we all know by SuperH you really meant 'automotive supercharger on
eBay!'"...

>>
>> But, as code gets more big and hairy, it becomes more difficult to weed
>> out these sorts of cases (and one needs to be increasingly more
>> conservative to avoid fixing something in one case, breaking something
>> somewhere else).
>>
> It is more like a Jr. High School student trying to understand the nuances of
> Shakespeare (more difficult to weed out) compared to more straightforward
> plots like Agatha Christie.

Parts of my original design were bad (and some of my original
assumptions misguided), and then stuff just kept piling up, and
everything turned into a mess.

So, for example, how did I originally approach emitting instructions?...

/* illustration only */
int BGBCC_JX2C_TryEmitOpRegReg(BGBCC_JX2_Context *ctx,
int nmid, int rm, int rn)
{ int opw1, opw2;
...
opw1=-1; opw2=-1;
switch(nmid)
{
case BGBCC_NMID_MOV:
if(!BGBCC_JX2_RegIsGpr32(ctx, rm)) break;
if(!BGBCC_JX2_RegIsGpr32(ctx, rn)) break;
opw1=0x1800|((rn&15)<<4)|(rm&15)|((rn&16)<<5)|((rm&16)<<4);
break;
}
if(opw1>=0)
{
BGBCC_JX2C_EmitWord(ctx, opw1);
if(opw2>=0)
BGBCC_JX2C_EmitWord(ctx, opw1);
return(1);
}
return(-1);
}

And, to emit a 3AC operator as 3R:
nm1=-1;
if(opr==BGBCC_OPR_ADD)
nm1=BGBCC_NMID_ADD;
if(opr==BGBCC_OPR_SUB)
nm1=BGBCC_NMID_SUB;
...
if(nm1>=0)
{
csreg=BGBCC_JX2C_GetRegisterRead(ctx, sreg);
ctreg=BGBCC_JX2C_GetRegisterRead(ctx, sreg);
cdreg=BGBCC_JX2C_GetRegisterWrite(ctx, dreg);
BGBCC_JX2C_EmitOpRegRegReg(ctx, nm1, csreg, ctreg, cdreg);
BGBCC_JX2C_ReleaseRegister(ctx, csreg);
BGBCC_JX2C_ReleaseRegister(ctx, ctreg);
BGBCC_JX2C_ReleaseRegister(ctx, cdreg);
return(1);
}
...

Where, as noted, the primary interface to the register allocator is to
get a CPU register that is mapped to a given 3AC register, and then
release it when done. This may adjust a use-count, or potentially
trigger the register to be evicted. Getting a new register may also
cause a previously loaded register to be evicted (using a hairy-looking
"algorithm" to decide which registers to evict as needed).

On Thursday, October 26, 2023 at 10:38:24 PM UTC-4, MitchAlsup wrote:
> On Thursday, October 26, 2023 at 5:46:10 PM UTC-5, robf...@gmail.com wrote:
> >
> > I think things must be developed in concert. The ISA, compiler, and the code for
> > hardware all developed at the same time. Much of these components do not
> > depend on other components so a lot can be done in parallel. There still needs
> > to be feedback between the components. I believe in taking an eclectic mix of
> > instructions from other architectures.
> <
> First of all:: well stated.
> <
> Second of all:: we all understand that there 50-ish instruction basis. (11 LD+ST,
> 7-ish Integer, 7-ish Logical, 5-ish Shift, 10-ish FP, and 6-ish flow control)
> <
> Most of the rest is how one routes results back into operands and how
> one expresses that in ISA.
> >
> > The most recent change to my Thor ISA was to make conditional branch
> > displacements in terms of instructions rather than bytes. This means
> > multiplying the displacement constant by five. It amounts to a three-input
> > adder for the displacement rather than two-input.
> <
> It is unreasonable to expect that this (all by itself) will cost you any delay
> in any microarchitecture. So, consider it free. It is certainly not more than
> 1 gate of delay.
> <
> > I then also used some of
> > the displacement range (top nibble 7 or 8) to indicate branch-to-register and
> > micro-code address branches. Previously Thor had separate instructions for
> > these, so the number of instructions has been reduced, and opcodes freed
> > up, while supporting a greater number of branches. The conditional branch
> > range is a somewhat strange plus or minus 280kB. Roughly equal to 19 bits.
> <
> I hid {message-instructions, SVC, SVR, and ATOMIC queries} in BC, too. Real-
> estate in ISA is precious; Use it wisely.
> >
> > I have made this change after much of the ISA is fixed, and large parts of the
> > assembler written. I changed it because I realized that micro-code branches
> > did not support a full set of branches. I hit the “How am I going to approach
> > this?” question while coding micro-code.
> <
> Can I ask what in ISA or Thor is pushing you towards µCode ??
> <
> For myself, I have FP sequencers that are in charge of SQRT, FDIV, SIN, COS, TAN,
> LN, EXP, POW. I also have memory sequencers to do LDM, STM, MM, ENTER, and
> EXIT. I also have HW table walkers for TLBs..........
> None of that is even remotely associated with microcode (as Wilkes defined it).
> <
> So, what is pushing you to interrupt the FETCH-DECODE path with microcode ??

It is not really µcode in the normal sense as the code is regular instructions, but
some of the instruction fields are hard-wired externally. So I have been calling it
µcode for lack of a better term. It is somewhat like the PAL? code associated with
the 29k.

The µcode is being used mainly to improve code density and to implement long
multi-cycle instructions. I have shied away from using hardware sequencers for
now. I think the µcode approach is simple for exception handling. µcoded
instructions may use loads and stores and those can exception. The µcode may
be interrupted and continued after the exception is processed. I do not know how
to handle exceptions occurring while running some of the more complex
operations, other than to have interruptible µcode.

Current longest running instruction is 64-bit reciprocal square root that takes
<120 clocks.

Current µcoded instructions include ENTER, LEAVE (EXIT), PUSH multiple, POP
multiple, FDIV, RSQRT, float reciprocal, and the RESET routine.

ENTER and LEAVE perform stack allocation, de-allocation and pushing the link
register to the stack and zeroing-out the space for a pointer to an exception
handler. PUSH / POP push or pop up to any four registers within a single
instruction. RESET loads the reset vector and machine stack pointer from
memory vectors.

Pushing or popping multiple registers just uses multiple optional load and store
instructions in the µcode and takes care of adjusting the SP.

On Thursday, October 26, 2023 at 10:38:24 PM UTC-4, MitchAlsup wrote:
> On Thursday, October 26, 2023 at 5:46:10 PM UTC-5, robf...@gmail.com wrote:
> >
> > I think things must be developed in concert. The ISA, compiler, and the code for
> > hardware all developed at the same time. Much of these components do not
> > depend on other components so a lot can be done in parallel. There still needs
> > to be feedback between the components. I believe in taking an eclectic mix of
> > instructions from other architectures.
> <
> First of all:: well stated.
> <
> Second of all:: we all understand that there 50-ish instruction basis. (11 LD+ST,
> 7-ish Integer, 7-ish Logical, 5-ish Shift, 10-ish FP, and 6-ish flow control)
> <
> Most of the rest is how one routes results back into operands and how
> one expresses that in ISA.
> >
> > The most recent change to my Thor ISA was to make conditional branch
> > displacements in terms of instructions rather than bytes. This means
> > multiplying the displacement constant by five. It amounts to a three-input
> > adder for the displacement rather than two-input.
> <
> It is unreasonable to expect that this (all by itself) will cost you any delay
> in any microarchitecture. So, consider it free. It is certainly not more than
> 1 gate of delay.
> <
> > I then also used some of
> > the displacement range (top nibble 7 or 8) to indicate branch-to-register and
> > micro-code address branches. Previously Thor had separate instructions for
> > these, so the number of instructions has been reduced, and opcodes freed
> > up, while supporting a greater number of branches. The conditional branch
> > range is a somewhat strange plus or minus 280kB. Roughly equal to 19 bits.
> <
> I hid {message-instructions, SVC, SVR, and ATOMIC queries} in BC, too. Real-
> estate in ISA is precious; Use it wisely.
> >
> > I have made this change after much of the ISA is fixed, and large parts of the
> > assembler written. I changed it because I realized that micro-code branches
> > did not support a full set of branches. I hit the “How am I going to approach
> > this?” question while coding micro-code.
> <
> Can I ask what in ISA or Thor is pushing you towards µCode ??
> <
> For myself, I have FP sequencers that are in charge of SQRT, FDIV, SIN, COS, TAN,
> LN, EXP, POW. I also have memory sequencers to do LDM, STM, MM, ENTER, and
> EXIT. I also have HW table walkers for TLBs..........

Thor has a HW table walker for the TLB too now. I may make the table walker more
sophisticated as there is a single shared TLB. It is not replicated for each core.

> None of that is even remotely associated with microcode (as Wilkes defined it).
> <
> So, what is pushing you to interrupt the FETCH-DECODE path with microcode ??

On 10/26/2023 5:46 PM, robf...@gmail.com wrote:
> On Thursday, October 26, 2023 at 5:45:55 PM UTC-4, BGB wrote:
>> On 10/26/2023 3:01 PM, Stephen Fuld wrote:
>>> On 10/26/2023 12:14 PM, MitchAlsup wrote:
>>>> On Thursday, October 26, 2023 at 10:24:53 AM UTC-5, Timothy McCaffrey
>>>> wrote:
>>>>> I came late to this party, but I wanted to comment on a couple of
>>>>> things I saw:
>>>>>
>>>>> 1) An out of order (very) CISC stack machine was built and sold
>>>>> (using MECL III logic) 30 years ago.
>>>>> It was called the Unisys A19. It could fuse up to 6 operations into a
>>>>> single "operation" and have
>>>>> up to 6 of them working in parallel. Unfortunately, the memory
>>>>> interface couldn't keep up with
>>>>> the CPU execution rate. (And you could configure it with up to 6 CPUs).
>>>>>
>>>>> 2) Unisys also built the "micro-A" series, which was a SCAMP (single
>>>>> chip A-series mainframe processor)
>>>>> on an expansion card in a 386 system. Unisys sold a bunch of them,
>>>>> they were very popular.
>>>>> I suspect the PC/370 (and AT/370) were crippled by internal in
>>>>> fighting at IBM.
>>>>>
>>>>> 3) If I ever had the spare (hah!) time to work on my own ISA, I think
>>>>> I would start with a "fat" encoding
>>>>> of all the instructions (i.e. fixed length, easy to write an emulator
>>>>> for, etc.).
>>>> <
>>>> That is the intent of My 66000 encoding--the ability to express
>>>> succinctly what the compiler
>>>> wants to produce, and a way of encoding this succinctly. However, I
>>>> started at classical
>>>> RISC and then expanded with constants so the first clause above was
>>>> maifest.
>>>> <
>>>>> Write the compiler, analyze the output, add/subtract instructions as
>>>>> required, and repeat.
>>>> <
>>>> There is NO SUBSTITUTE for reading the code of your architecture out
>>>> of your compiler.
>>>> How else do you find those warts that is hard to perform in HW AND
>>>> simultaneously
>>>> hard to use in the compiler.
>>>
>>> And find common sequences of generated instructions that could benefit
>>> from a way of reworking the existing instructions, or adding a new one,
>>> that would provide performance benefit.
>>>
>> This was also a practice in my case, but sometimes this is limited not
>> so much by limitations in the available instructions, so much as playing
>> "whack-a-mole" within the compiler (like, the seemingly sometimes futile
>> effort to eliminate pointless register-register MOV instructions and
>> similar).
>>
>> Like, a human writing ASM has this amazing ability to realize that a
>> value going into one register, and then immediately being moved into
>> another register (with the original register not being touched again)
>> can be replaced by just targeting the final register. Or, that a value
>> being cast to a type which doesn't actually require any format
>> conversion, can be skipped and the original register used directly.
>>
>> But, asking this from my compiler, seems to be asking too much sometimes
>> (and, hard to avoid casts in some cases, without indirectly creating
>> other cases where the cast did actually matter and which results in
>> bugs, ...).
>>
>>
>> Well, along with cases where the compiler still produces stale
>> instruction sequences, but where I had yet to find and weed out the source.
>>
>> For example, I have:
>> SHAR Rm, Ro, Rn
>> Yet, still sometimes see:
>> NEG Ro, Rtmp
>> SHAD Rm, Rtmp, Rn
>> Despite this now being pointless and unnecessary (and despite my
>> attempts to weed a lot of these cases out of the compiler).
>>
>> But, as code gets more big and hairy, it becomes more difficult to weed
>> out these sorts of cases (and one needs to be increasingly more
>> conservative to avoid fixing something in one case, breaking something
>> somewhere else).
>>
>>
>> Along with various other hair as remnants of earlier forms of the ISA
>> where things didn't work as nicely.
>>
>> But, a full rewrite of my codegen backend (to bring everything more in
>> line with the ISA as it exists now) would not be a small effort (and
>> would likely involve its own mountain of debugging).
>>
>> Doesn't help that my original approach to the design of the compiler
>> backend sort of made sense with SH-4, but no longer makes sense. Not
>> necessarily helped by an early original assumption that I would not
>> have, and thus had no need to bother with, an assembler or linker (but,
>> now these are just sort of awkwardly glued onto the side of trying to
>> generate code from the 3AC; but, would have been better if they were
>> their own stages).
>>
>> Actually, a proper "ASM" stage would have more opened the possibility of
>> using a peephole optimizer on the intermediate instructions, which could
>> have potentially pruned away some more of the pointless MOV's and similar...
>>
>>
>> But, alas...
>
> I think things must be developed in concert. The ISA, compiler, and the code for
> hardware all developed at the same time. Much of these components do not
> depend on other components so a lot can be done in parallel. There still needs
> to be feedback between the components. I believe in taking an eclectic mix of
> instructions from other architectures.
>

A general summary of my process was:
Start messing with SH-4 (~ 2016);
Write a compiler backend for SH-4;
Realize that stuff in SH-4 kinda sucks;
Hack over the stuff that sucked in SH-4;
Extend it to 64-bits;
End up with a horrible mess (my original BJX1 ISA);
Reboot the encoding scheme (becoming BJX2, ~ 2018);
Initially, ISA design was mostly 16-bit instructions;
The 32-bit instructions were treated as prefixed escape forms.
An SH-4 style FPU was effectively hard-wired in Double mode.
The 32-bit ops had 32 GPRs, 3-register ops, etc.
The 16-bit ops were still mostly limited to R0 .. R15.
Added instruction bundling;
Partly inspired by the TMS320 and similar.
Significantly changed around the instruction encodings,
Added Imm9/Imm10 forms, as Imm5/Disp5 was not sufficient.
Dropped the original FPU, in favor of using GPRs for FPU ops.
Changed register ports so that 'Rm' was always the Base register.
Saved a lot of LUTs and helped with timing.
Added predicated instructions;
Reclaimed more space from 16-bit land for this.
Added jumbo prefixes (initially with a rather horrid encoding);
Reworked the encoding again
Changing how Jumbo prefixes were encoded;
Dropped the 48-bit encodings (this encoding space was repurposed).
At this point (~ 2020) we are now mostly at the current encoding.
Experimented with 24-bit ops, reclaiming odd corners of 16-bit land.
Nothing of value was really in these locations;
Quickly realized that 24-bit ops were horrid, dropped them.
Expanded the GPR space to 64 GPRs (~ 2021)
Reclaimed the encoding space from the 24-bit ops for these encodings
But, only covering a subset of the ISA...
Added XG2 Mode (early 2023)
This basically revived my initial design idea from 2021
This dropped the 16-bit ops in this mode, in favor of a
more orthogonal encoding scheme.

Experimented with RISC-V decoding, partly after noting that BJX2 was
mostly a superset of RISC-V (main features that RISC-V required being
compare-and-branch and a flexible link-register); along with the decoder.

However, getting to an "actually useful" version of the RISC-V ISA would
go well outside the scope of the areas where there is overlap (and being
limited to RV64IM is "kinda weak"; if RISC-V was the goal, makes more
sense to have a CPU actually designed to run RISC-V).

But, it keeps turning into a thing of, I could use RISC-V, and GCC seems
to pull some magic tricks in terms of code generation, but otherwise,
RISC-V, kinda sucks...

In theory, nearly anything that can be done in RISC-V, could be done in
BJX2 in fewer instructions, so likely the only real advantage going for
it is that GCC is "less bad" at code generation than BGBCC (but, then I
look at it, and it is mostly a game of playing whack-a-mole with the
compiler emitting unnecessary instructions and similar; and failing to
make effective use of instruction bundling and similar, though in part
because all the needless register MOVs and similar end up creating
register dependencies that get in the way of the "shuffle and bundle"
strategy, ...). But, it it does technically work at least (and as noted
else-thread, my attempts to address some of this by twiddling with the
logic for when and where type-promotions happen, has tended to result
bugs; with "less efficient code" generally being preferable to "buggy
and misbehaving code"; and there is already a lot of cruft in various
places to try to minimize emitting needless type promotions as-is).

On Thursday, October 26, 2023 at 2:05:49 PM UTC-4, Stephen Fuld wrote:
> On 10/26/2023 8:24 AM, Timothy McCaffrey wrote:
> > I came late to this party, but I wanted to comment on a couple of things I saw:
> >
> > 1) An out of order (very) CISC stack machine was built and sold (using MECL III logic) 30 years ago.
> > It was called the Unisys A19. It could fuse up to 6 operations into a single "operation" and have
> > up to 6 of them working in parallel. Unfortunately, the memory interface couldn't keep up with
> > the CPU execution rate. (And you could configure it with up to 6 CPUs).
> I vaguely remember the A19, but I can't find any information on it
> online. No mention in the Wikipedia article on Burroughs large scale
> systems, nothing at bitsavers, etc. Do you know of any links for more
> information?

If you put "Unisys A19" into Google you get a lot. It was built 5 years after the merger, so it was never a "Burroughs" system.

From Bloomberg:
https://www.bloomberg.com/news/articles/1991-03-24/unisys-new-mainframe-leaves-big-blue-in-the-dust

"A mainframe processor due from Unisys Corp. late this year will employ a relatively new internal design that may give the struggling computer maker a much-needed shot in the arm. The new A19 relies on "super-scalar" techniques from scientific computers to execute many instructions concurrently. The A19 can overlap as many as 140 operations, more than 10 times as many as conventional mainframes can."

- Tim
(So, I may have gotten the concurrency numbers a bit wrong....)
(And Unisys sold quite a few of them IIRC).

On Sunday, October 29, 2023 at 7:42:15 PM UTC-5, Timothy McCaffrey wrote:
> On Thursday, October 26, 2023 at 2:05:49 PM UTC-4, Stephen Fuld wrote:
> > On 10/26/2023 8:24 AM, Timothy McCaffrey wrote:
> > > I came late to this party, but I wanted to comment on a couple of things I saw:
> > >
> > > 1) An out of order (very) CISC stack machine was built and sold (using MECL III logic) 30 years ago.
> > > It was called the Unisys A19. It could fuse up to 6 operations into a single "operation" and have
> > > up to 6 of them working in parallel. Unfortunately, the memory interface couldn't keep up with
> > > the CPU execution rate. (And you could configure it with up to 6 CPUs).
> > I vaguely remember the A19, but I can't find any information on it
> > online. No mention in the Wikipedia article on Burroughs large scale
> > systems, nothing at bitsavers, etc. Do you know of any links for more
> > information?
> If you put "Unisys A19" into Google you get a lot. It was built 5 years after the merger, so it was never a "Burroughs" system.
>
> From Bloomberg:
> https://www.bloomberg.com/news/articles/1991-03-24/unisys-new-mainframe-leaves-big-blue-in-the-dust
>
> "A mainframe processor due from Unisys Corp. late this year will employ a relatively new internal design that may give the struggling computer maker a much-needed shot in the arm. The new A19 relies on "super-scalar" techniques from scientific computers to execute many instructions concurrently. The A19 can overlap as many as 140 operations, more than 10 times as many as conventional mainframes can."
>
> - Tim
> (So, I may have gotten the concurrency numbers a bit wrong....)
> (And Unisys sold quite a few of them IIRC).

James Brakefield <jim.brakefield@ieee.org>
9:59 PM (24 minutes ago)
to comp.arch

|>
|>If you put "Unisys A19" into Google you get a lot. It was built 5 years after the merger, so it was never a "Burroughs" system.

From looking at some of the manuals, appears to be a 36-bit word size, used descriptors extensively, targeted to the Federal market for record processing?
E.G. a data base machine with a very Burroughs 5500 style?

JimBrakefield <jim.brakefield@ieee.org> writes:
>On Sunday, October 29, 2023 at 7:42:15=E2=80=AFPM UTC-5, Timothy McCaffrey =
>wrote:
>> On Thursday, October 26, 2023 at 2:05:49=E2=80=AFPM UTC-4, Stephen Fuld w=
>rote:=20
>> > On 10/26/2023 8:24 AM, Timothy McCaffrey wrote:=20
>> > > I came late to this party, but I wanted to comment on a couple of thi=
>ngs I saw:=20
>> > >=20
>> > > 1) An out of order (very) CISC stack machine was built and sold (usin=
>g MECL III logic) 30 years ago.=20
>> > > It was called the Unisys A19. It could fuse up to 6 operations into a=
> single "operation" and have=20
>> > > up to 6 of them working in parallel. Unfortunately, the memory interf=
>ace couldn't keep up with=20
>> > > the CPU execution rate. (And you could configure it with up to 6 CPUs=
>).=20
>> > I vaguely remember the A19, but I can't find any information on it=20
>> > online. No mention in the Wikipedia article on Burroughs large scale=20
>> > systems, nothing at bitsavers, etc. Do you know of any links for more=
>=20
>> > information?
>> If you put "Unisys A19" into Google you get a lot. It was built 5 years a=
>fter the merger, so it was never a "Burroughs" system.=20
>>=20
>> From Bloomberg:=20
>> https://www.bloomberg.com/news/articles/1991-03-24/unisys-new-mainframe-l=
>eaves-big-blue-in-the-dust=20
>>=20
>> "A mainframe processor due from Unisys Corp. late this year will employ a=
> relatively new internal design that may give the struggling computer maker=
> a much-needed shot in the arm. The new A19 relies on "super-scalar" techni=
>ques from scientific computers to execute many instructions concurrently. T=
>he A19 can overlap as many as 140 operations, more than 10 times as many as=
> conventional mainframes can."=20
>>=20
>> - Tim=20
>> (So, I may have gotten the concurrency numbers a bit wrong....)=20
>> (And Unisys sold quite a few of them IIRC).
>
>
>James Brakefield <jim.brakefield@ieee.org>
>9:59=E2=80=AFPM (24 minutes ago)
>to comp.arch
>
>|>
>|>If you put "Unisys A19" into Google you get a lot. It was built 5 years =
>after the merger, so it was never a "Burroughs" system.
>
>From looking at some of the manuals, appears to be a 36-bit word size,

You found the wrong manuals, I think. The sperry/Unisys 1100/2200 systems
had a 36-bit word.

All the burroughs large systems (B[567]xxx and A-series) had 48-bit
words, dating back to the B5000/B5500 in the early 1960s.

V-series was BCD, addressed to the nibble.

On 10/30/2023 8:36 AM, Scott Lurndal wrote:
> JimBrakefield <jim.brakefield@ieee.org> writes:
>> On Sunday, October 29, 2023 at 7:42:15=E2=80=AFPM UTC-5, Timothy McCaffrey =
>> wrote:
>>> On Thursday, October 26, 2023 at 2:05:49=E2=80=AFPM UTC-4, Stephen Fuld w=
>> rote:=20
>>>> On 10/26/2023 8:24 AM, Timothy McCaffrey wrote:=20
>>>>> I came late to this party, but I wanted to comment on a couple of thi=
>> ngs I saw:=20
>>>>> =20
>>>>> 1) An out of order (very) CISC stack machine was built and sold (usin=
>> g MECL III logic) 30 years ago.=20
>>>>> It was called the Unisys A19. It could fuse up to 6 operations into a=
>> single "operation" and have=20
>>>>> up to 6 of them working in parallel. Unfortunately, the memory interf=
>> ace couldn't keep up with=20
>>>>> the CPU execution rate. (And you could configure it with up to 6 CPUs=
>> ).=20
>>>> I vaguely remember the A19, but I can't find any information on it=20
>>>> online. No mention in the Wikipedia article on Burroughs large scale=20
>>>> systems, nothing at bitsavers, etc. Do you know of any links for more=
>> =20
>>>> information?
>>> If you put "Unisys A19" into Google you get a lot. It was built 5 years a=
>> fter the merger, so it was never a "Burroughs" system.=20
>>> =20
>>> From Bloomberg:=20
>>> https://www.bloomberg.com/news/articles/1991-03-24/unisys-new-mainframe-l=
>> eaves-big-blue-in-the-dust=20
>>> =20
>>> "A mainframe processor due from Unisys Corp. late this year will employ a=
>> relatively new internal design that may give the struggling computer maker=
>> a much-needed shot in the arm. The new A19 relies on "super-scalar" techni=
>> ques from scientific computers to execute many instructions concurrently. T=
>> he A19 can overlap as many as 140 operations, more than 10 times as many as=
>> conventional mainframes can."=20
>>> =20
>>> - Tim=20
>>> (So, I may have gotten the concurrency numbers a bit wrong....)=20
>>> (And Unisys sold quite a few of them IIRC).
>>
>>
>> James Brakefield <jim.brakefield@ieee.org>
>> 9:59=E2=80=AFPM (24 minutes ago)
>> to comp.arch
>>
>> |>
>> |>If you put "Unisys A19" into Google you get a lot. It was built 5 years =
>> after the merger, so it was never a "Burroughs" system.
>>
>>From looking at some of the manuals, appears to be a 36-bit word size,
>
> You found the wrong manuals, I think. The sperry/Unisys 1100/2200 systems
> had a 36-bit word.
>
> All the burroughs large systems (B[567]xxx and A-series) had 48-bit
> words, dating back to the B5000/B5500 in the early 1960s.
>
> V-series was BCD, addressed to the nibble.

Not much comment on this, but this post (and a few others) does point
out something to me:
It seems recently, haven't been seeing any new posts from either Jim
Brakefield or Mitch Alsup...

It seems they have been posting, but their posts don't show up in my
newsreader.

I am using eternal-september and Thunderbird, no relevant filters in
place (apart from ones related to "ramdane" and ones for the various
thai characters to deal with the recent spam).

....

BGB <cr88192@gmail.com> writes:
>On 10/30/2023 8:36 AM, Scott Lurndal wrote:
>> JimBrakefield <jim.brakefield@ieee.org> writes:
>>> On Sunday, October 29, 2023 at 7:42:15=E2=80=AFPM UTC-5, Timothy McCaffrey =
>>> wrote:
>>>> On Thursday, October 26, 2023 at 2:05:49=E2=80=AFPM UTC-4, Stephen Fuld w=
>>> rote:=20
>>>>> On 10/26/2023 8:24 AM, Timothy McCaffrey wrote:=20
>>>>>> I came late to this party, but I wanted to comment on a couple of thi=
>>> ngs I saw:=20
>>>>>> =20
>>>>>> 1) An out of order (very) CISC stack machine was built and sold (usin=
>>> g MECL III logic) 30 years ago.=20
>>>>>> It was called the Unisys A19. It could fuse up to 6 operations into a=
>>> single "operation" and have=20
>>>>>> up to 6 of them working in parallel. Unfortunately, the memory interf=
>>> ace couldn't keep up with=20
>>>>>> the CPU execution rate. (And you could configure it with up to 6 CPUs=
>>> ).=20
>>>>> I vaguely remember the A19, but I can't find any information on it=20
>>>>> online. No mention in the Wikipedia article on Burroughs large scale=20
>>>>> systems, nothing at bitsavers, etc. Do you know of any links for more=
>>> =20
>>>>> information?
>>>> If you put "Unisys A19" into Google you get a lot. It was built 5 years a=
>>> fter the merger, so it was never a "Burroughs" system.=20
>>>> =20
>>>> From Bloomberg:=20
>>>> https://www.bloomberg.com/news/articles/1991-03-24/unisys-new-mainframe-l=
>>> eaves-big-blue-in-the-dust=20
>>>> =20
>>>> "A mainframe processor due from Unisys Corp. late this year will employ a=
>>> relatively new internal design that may give the struggling computer maker=
>>> a much-needed shot in the arm. The new A19 relies on "super-scalar" techni=
>>> ques from scientific computers to execute many instructions concurrently. T=
>>> he A19 can overlap as many as 140 operations, more than 10 times as many as=
>>> conventional mainframes can."=20
>>>> =20
>>>> - Tim=20
>>>> (So, I may have gotten the concurrency numbers a bit wrong....)=20
>>>> (And Unisys sold quite a few of them IIRC).
>>>
>>>
>>> James Brakefield <jim.brakefield@ieee.org>
>>> 9:59=E2=80=AFPM (24 minutes ago)
>>> to comp.arch
>>>
>>> |>
>>> |>If you put "Unisys A19" into Google you get a lot. It was built 5 years =
>>> after the merger, so it was never a "Burroughs" system.
>>>
>>>From looking at some of the manuals, appears to be a 36-bit word size,
>>
>> You found the wrong manuals, I think. The sperry/Unisys 1100/2200 systems
>> had a 36-bit word.
>>
>> All the burroughs large systems (B[567]xxx and A-series) had 48-bit
>> words, dating back to the B5000/B5500 in the early 1960s.
>>
>> V-series was BCD, addressed to the nibble.
>
>
>Not much comment on this, but this post (and a few others) does point
>out something to me:
>It seems recently, haven't been seeing any new posts from either Jim
>Brakefield or Mitch Alsup...
>
>It seems they have been posting, but their posts don't show up in my
>newsreader.

I believe eternal-september was agressively filtering posts from GG.

On 10/30/2023 12:56 PM, Scott Lurndal wrote:
> BGB <cr88192@gmail.com> writes:
>> On 10/30/2023 8:36 AM, Scott Lurndal wrote:
>>> JimBrakefield <jim.brakefield@ieee.org> writes:
>>>> On Sunday, October 29, 2023 at 7:42:15=E2=80=AFPM UTC-5, Timothy McCaffrey =
>>>> wrote:
>>>>> On Thursday, October 26, 2023 at 2:05:49=E2=80=AFPM UTC-4, Stephen Fuld w=
>>>> rote:=20
>>>>>> On 10/26/2023 8:24 AM, Timothy McCaffrey wrote:=20
>>>>>>> I came late to this party, but I wanted to comment on a couple of thi=
>>>> ngs I saw:=20
>>>>>>> =20
>>>>>>> 1) An out of order (very) CISC stack machine was built and sold (usin=
>>>> g MECL III logic) 30 years ago.=20
>>>>>>> It was called the Unisys A19. It could fuse up to 6 operations into a=
>>>> single "operation" and have=20
>>>>>>> up to 6 of them working in parallel. Unfortunately, the memory interf=
>>>> ace couldn't keep up with=20
>>>>>>> the CPU execution rate. (And you could configure it with up to 6 CPUs=
>>>> ).=20
>>>>>> I vaguely remember the A19, but I can't find any information on it=20
>>>>>> online. No mention in the Wikipedia article on Burroughs large scale=20
>>>>>> systems, nothing at bitsavers, etc. Do you know of any links for more=
>>>> =20
>>>>>> information?
>>>>> If you put "Unisys A19" into Google you get a lot. It was built 5 years a=
>>>> fter the merger, so it was never a "Burroughs" system.=20
>>>>> =20
>>>>> From Bloomberg:=20
>>>>> https://www.bloomberg.com/news/articles/1991-03-24/unisys-new-mainframe-l=
>>>> eaves-big-blue-in-the-dust=20
>>>>> =20
>>>>> "A mainframe processor due from Unisys Corp. late this year will employ a=
>>>> relatively new internal design that may give the struggling computer maker=
>>>> a much-needed shot in the arm. The new A19 relies on "super-scalar" techni=
>>>> ques from scientific computers to execute many instructions concurrently. T=
>>>> he A19 can overlap as many as 140 operations, more than 10 times as many as=
>>>> conventional mainframes can."=20
>>>>> =20
>>>>> - Tim=20
>>>>> (So, I may have gotten the concurrency numbers a bit wrong....)=20
>>>>> (And Unisys sold quite a few of them IIRC).
>>>>
>>>>
>>>> James Brakefield <jim.brakefield@ieee.org>
>>>> 9:59=E2=80=AFPM (24 minutes ago)
>>>> to comp.arch
>>>>
>>>> |>
>>>> |>If you put "Unisys A19" into Google you get a lot. It was built 5 years =
>>>> after the merger, so it was never a "Burroughs" system.
>>>>
>>> >From looking at some of the manuals, appears to be a 36-bit word size,
>>>
>>> You found the wrong manuals, I think. The sperry/Unisys 1100/2200 systems
>>> had a 36-bit word.
>>>
>>> All the burroughs large systems (B[567]xxx and A-series) had 48-bit
>>> words, dating back to the B5000/B5500 in the early 1960s.
>>>
>>> V-series was BCD, addressed to the nibble.
>>
>>
>> Not much comment on this, but this post (and a few others) does point
>> out something to me:
>> It seems recently, haven't been seeing any new posts from either Jim
>> Brakefield or Mitch Alsup...
>>
>> It seems they have been posting, but their posts don't show up in my
>> newsreader.
>
> I believe eternal-september was agressively filtering posts from GG.
>

Yeah.

This newsgroup has now been pretty quiet recently on my end.
Seemingly only posts from you, David Brown, and EricP, are the only
recent posts I have seen within the past few days...

A few other posters on 10/27 and 10/28, but it appears mostly as-if
"everything mostly went quiet" some time around 10/26 (and some of the
more recent posts have been to posts I have not seen).