Clearly, an old-style 24-bit machine, that has a memory-accumulator
architecture instead of a general register architecture, and a 32k
address space, wouldn't be very useful nowadays.

But that isn't necessarily the kind of machine you have to design to have a
24-bit instruction word, even if one might nod to retro styling to a limited
extent.

So, for example, you could have an architecture with these two major
instruction formats:

00 - to indicate register-to-register instruction
Opcode: 7 bits
Destinatiion register: 5 bits
Operand register: 5 bits
Source register: 5 bits

That looks a lot like a modern RISC architecture!

But memory-reference instructions are harder to do, I admit. One
possible format could be this:

1 - to indicate memory-reference instruction
Index register: 2 bits
Opcode: 4 bits
Destination register: 2 bits
Base register: 3 bits
Address/Displacement: 12 bits

And then one has additional instructions starting witn 01, to handle
extra instructions with one or two operands, and for the jump
instructions.

It would be a rather Spartan instruction set, but I think it could manage
to cover all the basic stuff, like both integer and floating-point
instructions.

John Savard

On 6/11/2022 8:24 PM, Quadibloc wrote:
> Clearly, an old-style 24-bit machine, that has a memory-accumulator
> architecture instead of a general register architecture, and a 32k
> address space, wouldn't be very useful nowadays.
>
> But that isn't necessarily the kind of machine you have to design to have a
> 24-bit instruction word, even if one might nod to retro styling to a limited
> extent.
>

24-bit is possible, though on a "generic" memory width machine would
decay to needing byte-aligned instructions.

> So, for example, you could have an architecture with these two major
> instruction formats:
>
> 00 - to indicate register-to-register instruction
> Opcode: 7 bits
> Destinatiion register: 5 bits
> Operand register: 5 bits
> Source register: 5 bits
>
> That looks a lot like a modern RISC architecture!
>

Possible.

> But memory-reference instructions are harder to do, I admit. One
> possible format could be this:
>
> 1 - to indicate memory-reference instruction
> Index register: 2 bits
> Opcode: 4 bits
> Destination register: 2 bits
> Base register: 3 bits
> Address/Displacement: 12 bits
>

This would suck.

Would be better off with 5-bit immediate and displacement fields.

Despite being "not exactly big", they are also not quite as useless as
one might intuitively expect.

> And then one has additional instructions starting witn 01, to handle
> extra instructions with one or two operands, and for the jump
> instructions.
>
> It would be a rather Spartan instruction set, but I think it could manage
> to cover all the basic stuff, like both integer and floating-point
> instructions.
>

Hmm, Maybe:
zzzz-zzzz_nnnn-nmmm_mmzo-oooo
0000-lttt_nnnn-nmmm_mmpo-oooo
l: 0=Store, 1=Load
ttt: Type
p: 0=Register, 1=Disp5u
0001-0ttt_nnnn-nmmm_mmpo-oooo
ttt: Operator (ADD/SUB/MULS/MULU,-,AND/OR/XOR)
p: 0=Register, 1=Imm5u
0001-1zzz_nnnn-nmmm_mmzz-zzzz
2R space

0010-0000_dddd-dddd_dddd-dddd //BRA Disp16
0010-0001_dddd-dddd_dddd-dddd //BSR Disp16
0010-0010_dddd-dddd_dddd-dddd //BT Disp16
0010-0011_dddd-dddd_dddd-dddd //BF Disp16

0010-1000_nnnn-niii_iiii-iiii //LDI Imm11u, Rn
0010-1001_nnnn-niii_iiii-iiii //LDI Imm11n, Rn
0010-1010_nnnn-niii_iiii-iiii //ADD Imm11u, Rn
0010-1011_nnnn-niii_iiii-iiii //ADD Imm11n, Rn

...

....

> John Savard

On Saturday, June 11, 2022 at 8:24:57 PM UTC-5, Quadibloc wrote:
> Clearly, an old-style 24-bit machine, that has a memory-accumulator
> architecture instead of a general register architecture, and a 32k
> address space, wouldn't be very useful nowadays.
>
> But that isn't necessarily the kind of machine you have to design to have a
> 24-bit instruction word, even if one might nod to retro styling to a limited
> extent.
>
> So, for example, you could have an architecture with these two major
> instruction formats:
>
> 00 - to indicate register-to-register instruction
> Opcode: 7 bits
> Destinatiion register: 5 bits
> Operand register: 5 bits
> Source register: 5 bits
<
There is a very large fraction of instructions needing reasonable immediates.
Comparing MIPS with SPARC one sees 16-bits seems to be enough while 13-bits
does not. 18-bit control transfer immediates are far more valuable 15-bit. And
you can supply a maximum of 10-bits. You will end up using a lot of instructions
pasting constants together.
>
> That looks a lot like a modern RISC architecture!
<
Only to the squinting eye.
>
> But memory-reference instructions are harder to do, I admit. One
> possible format could be this:
>
> 1 - to indicate memory-reference instruction
> Index register: 2 bits
> Opcode: 4 bits
> Destination register: 2 bits
> Base register: 3 bits
> Address/Displacement: 12 bits
<
Now you are just adding complications to make op for the poor starting
position.
>
> And then one has additional instructions starting witn 01, to handle
> extra instructions with one or two operands, and for the jump
> instructions.
>
> It would be a rather Spartan instruction set, but I think it could manage
> to cover all the basic stuff, like both integer and floating-point
> instructions.
>
> John Savard

On 6/12/2022 12:28 PM, MitchAlsup wrote:
> On Saturday, June 11, 2022 at 8:24:57 PM UTC-5, Quadibloc wrote:
>> Clearly, an old-style 24-bit machine, that has a memory-accumulator
>> architecture instead of a general register architecture, and a 32k
>> address space, wouldn't be very useful nowadays.
>>
>> But that isn't necessarily the kind of machine you have to design to have a
>> 24-bit instruction word, even if one might nod to retro styling to a limited
>> extent.
>>
>> So, for example, you could have an architecture with these two major
>> instruction formats:
>>
>> 00 - to indicate register-to-register instruction
>> Opcode: 7 bits
>> Destinatiion register: 5 bits
>> Operand register: 5 bits
>> Source register: 5 bits
> <
> There is a very large fraction of instructions needing reasonable immediates.
> Comparing MIPS with SPARC one sees 16-bits seems to be enough while 13-bits
> does not. 18-bit control transfer immediates are far more valuable 15-bit. And
> you can supply a maximum of 10-bits. You will end up using a lot of instructions
> pasting constants together.

Probably so, though 24-bits could potentially still hit a "sweet spot"
on the code-density front (similar to 16/32), but would likely still
give inferior performance to a 16/32 RISC ISA due to issues like
constants and immediate fields (fixed-length 24-bit would have some
similar disadvantages to fixed-length 16-bit regarding constants).

Can also note one thing as a semi-warning from dealing with SH-4:
If you run low on encoding space, and start banking in/out parts of the
ISA via modifying bits in control registers... This also sucks.

Like, SH-4 was like:
Well, we have FnmX, need to try to fit in:
Single precision instructions;
Double precision instructions;
A few 2x Single SIMD operations;
A MatMult helper instruction;
...
How do we do it?:
You load bits into FPSCR which indicate which ops to decode as.

Or, this sucked...

As for displacements:
~ 9-bit (scaled) or 11/12-bit (unscaled) seems to be mostly sufficient
for Load/Store;
One can go smaller, but then one really needs a register-indexed mode,
or else it is going to suck.

At these sizes, the number of (basic) displacements which fall outside
the range is pretty small (and those that fail, often do so by a much
larger amount).

For local branches (within a function), 8 bits can still be fairly
effective, though a fair number of functions will be larger than this
(so it is not sufficient "in general").

In my case, pretty much everything I have compiled thus far fits within
a 20-bit branch displacement (1MB), though a few programs are
approaching this limit.

Current fallback cases mostly involve Disp33 (8GB) and Abs48 encodings.

>>
>> That looks a lot like a modern RISC architecture!
> <
> Only to the squinting eye.
>>
>> But memory-reference instructions are harder to do, I admit. One
>> possible format could be this:
>>
>> 1 - to indicate memory-reference instruction
>> Index register: 2 bits
>> Opcode: 4 bits
>> Destination register: 2 bits
>> Base register: 3 bits
>> Address/Displacement: 12 bits
> <
> Now you are just adding complications to make op for the poor starting
> position.

As noted in my comment, "this would suck".

A larger displacement doesn't gain much if the register fields are useless.

>>
>> And then one has additional instructions starting witn 01, to handle
>> extra instructions with one or two operands, and for the jump
>> instructions.
>>
>> It would be a rather Spartan instruction set, but I think it could manage
>> to cover all the basic stuff, like both integer and floating-point
>> instructions.
>>
>> John Savard

On Sunday, June 12, 2022 at 2:29:07 PM UTC-5, BGB wrote:
> On 6/12/2022 12:28 PM, MitchAlsup wrote:
> > On Saturday, June 11, 2022 at 8:24:57 PM UTC-5, Quadibloc wrote:
> >> Clearly, an old-style 24-bit machine, that has a memory-accumulator
> >> architecture instead of a general register architecture, and a 32k
> >> address space, wouldn't be very useful nowadays.
> >>
> >> But that isn't necessarily the kind of machine you have to design to have a
> >> 24-bit instruction word, even if one might nod to retro styling to a limited
> >> extent.
> >>
> >> So, for example, you could have an architecture with these two major
> >> instruction formats:
> >>
> >> 00 - to indicate register-to-register instruction
> >> Opcode: 7 bits
> >> Destinatiion register: 5 bits
> >> Operand register: 5 bits
> >> Source register: 5 bits
> > <
> > There is a very large fraction of instructions needing reasonable immediates.
> > Comparing MIPS with SPARC one sees 16-bits seems to be enough while 13-bits
> > does not. 18-bit control transfer immediates are far more valuable 15-bit. And
> > you can supply a maximum of 10-bits. You will end up using a lot of instructions
> > pasting constants together.
> Probably so, though 24-bits could potentially still hit a "sweet spot"
> on the code-density front (similar to 16/32), but would likely still
> give inferior performance to a 16/32 RISC ISA due to issues like
> constants and immediate fields (fixed-length 24-bit would have some
> similar disadvantages to fixed-length 16-bit regarding constants).
>
>
> Can also note one thing as a semi-warning from dealing with SH-4:
> If you run low on encoding space, and start banking in/out parts of the
> ISA via modifying bits in control registers... This also sucks.
>
> Like, SH-4 was like:
> Well, we have FnmX, need to try to fit in:
> Single precision instructions;
> Double precision instructions;
> A few 2x Single SIMD operations;
> A MatMult helper instruction;
> ...
> How do we do it?:
> You load bits into FPSCR which indicate which ops to decode as.
>
> Or, this sucked...
>
Understatement of the month ???
>
>
> As for displacements:
> ~ 9-bit (scaled) or 11/12-bit (unscaled) seems to be mostly sufficient
> for Load/Store;
<
Works better for C than FORTRAN.
<
> One can go smaller, but then one really needs a register-indexed mode,
> or else it is going to suck.
<
It is reasons such as these that My 66000 ISA never uses instructions to
paste constants together.
>
> At these sizes, the number of (basic) displacements which fall outside
> the range is pretty small (and those that fail, often do so by a much
> larger amount).
>
Then think about 64-bit address space where .bss and .data may be
placed more than 1GB away from each other and the code and at
randomized addresses/offsets. Even if 64-bit address/displacements
are only 1%-2% of all memory references, using LDs pollutes the D$,
using instructions pollutes the I$. The only reasonable way out is to
provide access means in the decode structure of the instructions
themselves (ala My 66000).
>
>
> For local branches (within a function), 8 bits can still be fairly
> effective, though a fair number of functions will be larger than this
> (so it is not sufficient "in general").
<
And then there are inner loops such as FPPPP (8K instructions).
So while 8-10-bits is sufficient for a lot of things, it still leaves a few
things dangling.
>
> In my case, pretty much everything I have compiled thus far fits within
> a 20-bit branch displacement (1MB), though a few programs are
> approaching this limit.
>
> Current fallback cases mostly involve Disp33 (8GB) and Abs48 encodings.
> >>
> >> That looks a lot like a modern RISC architecture!
> > <
> > Only to the squinting eye.
> >>
> >> But memory-reference instructions are harder to do, I admit. One
> >> possible format could be this:
> >>
> >> 1 - to indicate memory-reference instruction
> >> Index register: 2 bits
> >> Opcode: 4 bits
> >> Destination register: 2 bits
> >> Base register: 3 bits
> >> Address/Displacement: 12 bits
> > <
> > Now you are just adding complications to make op for the poor starting
> > position.
> As noted in my comment, "this would suck".
>
> A larger displacement doesn't gain much if the register fields are useless.
> >>
> >> And then one has additional instructions starting witn 01, to handle
> >> extra instructions with one or two operands, and for the jump
> >> instructions.
> >>
> >> It would be a rather Spartan instruction set, but I think it could manage
> >> to cover all the basic stuff, like both integer and floating-point
> >> instructions.
> >>
> >> John Savard

On 6/12/2022 2:39 PM, MitchAlsup wrote:
> On Sunday, June 12, 2022 at 2:29:07 PM UTC-5, BGB wrote:
>> On 6/12/2022 12:28 PM, MitchAlsup wrote:
>>> On Saturday, June 11, 2022 at 8:24:57 PM UTC-5, Quadibloc wrote:
>>>> Clearly, an old-style 24-bit machine, that has a memory-accumulator
>>>> architecture instead of a general register architecture, and a 32k
>>>> address space, wouldn't be very useful nowadays.
>>>>
>>>> But that isn't necessarily the kind of machine you have to design to have a
>>>> 24-bit instruction word, even if one might nod to retro styling to a limited
>>>> extent.
>>>>
>>>> So, for example, you could have an architecture with these two major
>>>> instruction formats:
>>>>
>>>> 00 - to indicate register-to-register instruction
>>>> Opcode: 7 bits
>>>> Destinatiion register: 5 bits
>>>> Operand register: 5 bits
>>>> Source register: 5 bits
>>> <
>>> There is a very large fraction of instructions needing reasonable immediates.
>>> Comparing MIPS with SPARC one sees 16-bits seems to be enough while 13-bits
>>> does not. 18-bit control transfer immediates are far more valuable 15-bit. And
>>> you can supply a maximum of 10-bits. You will end up using a lot of instructions
>>> pasting constants together.
>> Probably so, though 24-bits could potentially still hit a "sweet spot"
>> on the code-density front (similar to 16/32), but would likely still
>> give inferior performance to a 16/32 RISC ISA due to issues like
>> constants and immediate fields (fixed-length 24-bit would have some
>> similar disadvantages to fixed-length 16-bit regarding constants).
>>
>>
>> Can also note one thing as a semi-warning from dealing with SH-4:
>> If you run low on encoding space, and start banking in/out parts of the
>> ISA via modifying bits in control registers... This also sucks.
>>
>> Like, SH-4 was like:
>> Well, we have FnmX, need to try to fit in:
>> Single precision instructions;
>> Double precision instructions;
>> A few 2x Single SIMD operations;
>> A MatMult helper instruction;
>> ...
>> How do we do it?:
>> You load bits into FPSCR which indicate which ops to decode as.
>>
>> Or, this sucked...
>>
> Understatement of the month ???

It sorta worked, but yeah, preferably one doesn't design their FPU this way.

If compiling code as-written, switching between Single and Double would
waste a lot of clock-cycles. GCC seemed to take an approach of in some
cases (when mixing Single and Double) just sort of converting everything
to Single and leaving it there (even if the C rules say you should
promote to Double and then convert the result back to Single).

When I designed the FPU for BJX2, I went over instead to treating Double
as the default internal format, with scalar Float values being operated
on as Double, in which case format conversions for scalar operations are
essentially free. I had also initially eliminated any "modal" concepts
from the FPU (later re-adding them only in a limited form as required
for C's "fenv_access" mechanism).

>>
>>
>> As for displacements:
>> ~ 9-bit (scaled) or 11/12-bit (unscaled) seems to be mostly sufficient
>> for Load/Store;
> <
> Works better for C than FORTRAN.
> <

Can generally deal with the sizes of most structs and stack frames.

>> One can go smaller, but then one really needs a register-indexed mode,
>> or else it is going to suck.
> <
> It is reasons such as these that My 66000 ISA never uses instructions to
> paste constants together.

If all you have is a 5 bit displacement, and no indexed mode, the ISA is
kinda screwed as:
Stack frames are frequently bigger than this;
Structs are also frequently bigger than this.

In SuperH, options were:
If the value is a 32-bit type, you can have a 4 bit load/store displacement;
Else, you can load the displacement into a register (R0 was hard-wired
as an index register);
If your displacement doesn't fit in 8-bits (sign extended), you need to
use a memory load to load the displacement;
Because the PC-relative load displacement was also pretty limited, one
would (typically) also need to branch over the constants they needed to
dump into the middle of the instruction stream in order to be able to
constant-load the memory displacements;
....

This... also sucked...

One of my extensions was an LDSH instruction:
MOV 0xXX, R0
LDSH 0xXX, R0 //R0=(R0<<8)|Imm8u
MOV.L @(R4, R0), R2

This could replace a 16-bit memory load with a 2-instruction bit-paste,
which was at least a little better.

>>
>> At these sizes, the number of (basic) displacements which fall outside
>> the range is pretty small (and those that fail, often do so by a much
>> larger amount).
>>
> Then think about 64-bit address space where .bss and .data may be
> placed more than 1GB away from each other and the code and at
> randomized addresses/offsets. Even if 64-bit address/displacements
> are only 1%-2% of all memory references, using LDs pollutes the D$,
> using instructions pollutes the I$. The only reasonable way out is to
> provide access means in the decode structure of the instructions
> themselves (ala My 66000).

In my current ABI, ".data" and ".bss" are accessed relative to GBR.

With Jumbo encodings, I can access a 4GB section data/bss section via a
single instruction.

Not currently a good way to deal with a data/bss section larger than 4GB
though (this case would require using ALU ops for the address calculations).

>>
>>
>> For local branches (within a function), 8 bits can still be fairly
>> effective, though a fair number of functions will be larger than this
>> (so it is not sufficient "in general").
> <
> And then there are inner loops such as FPPPP (8K instructions).
> So while 8-10-bits is sufficient for a lot of things, it still leaves a few
> things dangling.

In these cases, 20-bit branches are available in my case.

My compiler is generally able to figure out when to use a Disp8 or
Disp20 branch (16-bit or 32-bit instruction formats, eg: 20dd or F0dd_Cddd).

It would start using Disp33 if the program got too large for Disp20, but
this hasn't happened yet.

>>
>> In my case, pretty much everything I have compiled thus far fits within
>> a 20-bit branch displacement (1MB), though a few programs are
>> approaching this limit.
>>
>> Current fallback cases mostly involve Disp33 (8GB) and Abs48 encodings.
>>>>
>>>> That looks a lot like a modern RISC architecture!
>>> <
>>> Only to the squinting eye.
>>>>
>>>> But memory-reference instructions are harder to do, I admit. One
>>>> possible format could be this:
>>>>
>>>> 1 - to indicate memory-reference instruction
>>>> Index register: 2 bits
>>>> Opcode: 4 bits
>>>> Destination register: 2 bits
>>>> Base register: 3 bits
>>>> Address/Displacement: 12 bits
>>> <
>>> Now you are just adding complications to make op for the poor starting
>>> position.
>> As noted in my comment, "this would suck".
>>
>> A larger displacement doesn't gain much if the register fields are useless.
>>>>
>>>> And then one has additional instructions starting witn 01, to handle
>>>> extra instructions with one or two operands, and for the jump
>>>> instructions.
>>>>
>>>> It would be a rather Spartan instruction set, but I think it could manage
>>>> to cover all the basic stuff, like both integer and floating-point
>>>> instructions.
>>>>
>>>> John Savard

On Sunday, June 12, 2022 at 11:28:21 AM UTC-6, MitchAlsup wrote:

> Now you are just adding complications to make op for the poor starting
> position.

Essentially, this all stems from... the Control Data 8600.

That was to have been a 6600, but expanded from 60 bits to 64 bits. You noted
that it failed. My guess was that it was because they intended the performance
gain over the 7600 to be more than they could achieve.

I started thinking, based on my old idea of having 36, 48, and 60 bit floats that
I decided I should abandon - given that both the 1604, with 48-bit single precision,
and the 6600, with 60-bit single precision, just doubled those longer lengths for
their double precisiion - to go the 8600 one further.

Increase the word size from 60 bits to 72 bits. That way, half of a word would be
a decent single precision number of 36 bits.

But then, based on the fact that the 1604 fit two 24-bit instructions into a 48-bit
word, I thought to fit three 24-bit instructions into a 72-bit word. But the 15-bit
addresses would have to indicate halfwords if we're using 36-bit floats.

So *instead* of a 6600 expanded to 72 bits, I end up with a 1604 with the memory
shrunk to 3/4 of its original size - the same as a 7090. And having accumulator-memory
instructions (unlike the 1604, though, I would never think of using floats for integer
arithmetic; the SDS 9300 has an instruction set with both floating-point and integer
instructions, I'd go with something like that) unlike the register-to-register arithmetic
of the 6600, it would be slow given today's memory latencies.

But the Sigma 9 wormed its way out of the limitations of the Sigma's 32-bit instruction
format to allow a larger memory. And one can fit register-to-register instructions in 16 bits,
so they can certainly fit in 24 bits. So I tried to change the architecture from 1604-ish to
a bit more 6600-ish. Of course, it would be easier just to have 18-bit and 36-bit instructions
that don't cross 72-bit boundaries - to go full 6600.

John Savard

On Monday, June 20, 2022 at 8:18:42 AM UTC-5, Quadibloc wrote:
> On Sunday, June 12, 2022 at 11:28:21 AM UTC-6, MitchAlsup wrote:
>
> > Now you are just adding complications to make op for the poor starting
> > position.
> Essentially, this all stems from... the Control Data 8600.
>
> That was to have been a 6600, but expanded from 60 bits to 64 bits. You noted
> that it failed. My guess was that it was because they intended the performance
> gain over the 7600 to be more than they could achieve.
<
Rumors are that the performance was "almost" there.
Cray and several others left to build Cray--while CDC set is eyes on building STARs.
>
> I started thinking, based on my old idea of having 36, 48, and 60 bit floats that
> I decided I should abandon - given that both the 1604, with 48-bit single precision,
> and the 6600, with 60-bit single precision, just doubled those longer lengths for
> their double precisiion - to go the 8600 one further.
>
> Increase the word size from 60 bits to 72 bits. That way, half of a word would be
> a decent single precision number of 36 bits.
<
1108 proved that 36 bits was sufficiently better than 32 for SP maths.
>
> But then, based on the fact that the 1604 fit two 24-bit instructions into a 48-bit
> word, I thought to fit three 24-bit instructions into a 72-bit word. But the 15-bit
> addresses would have to indicate halfwords if we're using 36-bit floats.
>
> So *instead* of a 6600 expanded to 72 bits, I end up with a 1604 with the memory
> shrunk to 3/4 of its original size - the same as a 7090. And having accumulator-memory
> instructions (unlike the 1604, though, I would never think of using floats for integer
> arithmetic; the SDS 9300 has an instruction set with both floating-point and integer
> instructions, I'd go with something like that) unlike the register-to-register arithmetic
> of the 6600, it would be slow given today's memory latencies.
<
THis is what 24-bit ISAs do to you.
>
> But the Sigma 9 wormed its way out of the limitations of the Sigma's 32-bit instruction
> format to allow a larger memory. And one can fit register-to-register instructions in 16 bits,
> so they can certainly fit in 24 bits. So I tried to change the architecture from 1604-ish to
> a bit more 6600-ish. Of course, it would be easier just to have 18-bit and 36-bit instructions
> that don't cross 72-bit boundaries - to go full 6600.
<
Sigma 5-7-9 were IBM format ISAs without the memory to memory cruft.
>
> John Savard

On Monday, June 20, 2022 at 10:50:43 AM UTC-6, MitchAlsup wrote:

> Sigma 5-7-9 were IBM format ISAs without the memory to memory cruft.

I see that indeed the Sigma 5 didn't have that.

But, as I remembered, the Sigma 7 *did*. How did it manage with only
32 bit instructions? One had to set up two consecutive registers with
the necessary information to describe the instruction.

The Sigma 7 had translate and test, edit, and all that stuff, like the 360.

There were other machines that did it the same way; the Sigmas weren't
the only ones.

John Savard

On Monday, June 20, 2022 at 5:32:40 PM UTC-5, Quadibloc wrote:
> On Monday, June 20, 2022 at 10:50:43 AM UTC-6, MitchAlsup wrote:
>
> > Sigma 5-7-9 were IBM format ISAs without the memory to memory cruft.
> I see that indeed the Sigma 5 didn't have that.
<
I spend 3 years programming real time applications in FORTRAN (and a bit
of ASM) from 1975-1978. We were primarily limited at the data collection side
of things, but we pounded down the ISR time so that "waiting for interrupt"
to "ready to wait for interrupt" was only 12 cycles. In the mean time, we had
to read an A/D converter, store the 22-bit quantity to memory, increment a
pointer/index, do a limit check, and Return from interrupt. The S5 had no
instruction cache, no data cache, and memory was 5 cycles away.
<
>
> But, as I remembered, the Sigma 7 *did*. How did it manage with only
> 32 bit instructions? One had to set up two consecutive registers with
> the necessary information to describe the instruction.
<
I thought S5 had 16-bit instructions, but it has been a LONG time.
>
> The Sigma 7 had translate and test, edit, and all that stuff, like the 360.
>
> There were other machines that did it the same way; the Sigmas weren't
> the only ones.
<
Interdata, S.E.L, and one other I can't remember right now.
>
> John Savard

On Monday, June 20, 2022 at 4:53:46 PM UTC-6, MitchAlsup wrote:

> Interdata, S.E.L, and one other I can't remember right now.

I was thinking of an option for a higher-end PDP-11, and possibly also
some machine by Hewlett-Packard.

John Savard

On 6/20/2022 3:53 PM, MitchAlsup wrote:
> On Monday, June 20, 2022 at 5:32:40 PM UTC-5, Quadibloc wrote:
>> On Monday, June 20, 2022 at 10:50:43 AM UTC-6, MitchAlsup wrote:
>>
>>> Sigma 5-7-9 were IBM format ISAs without the memory to memory cruft.
>> I see that indeed the Sigma 5 didn't have that.
> <
> I spend 3 years programming real time applications in FORTRAN (and a bit
> of ASM) from 1975-1978. We were primarily limited at the data collection side
> of things, but we pounded down the ISR time so that "waiting for interrupt"
> to "ready to wait for interrupt" was only 12 cycles. In the mean time, we had
> to read an A/D converter, store the 22-bit quantity to memory, increment a
> pointer/index, do a limit check, and Return from interrupt. The S5 had no
> instruction cache, no data cache, and memory was 5 cycles away.
> <
>>
>> But, as I remembered, the Sigma 7 *did*. How did it manage with only
>> 32 bit instructions? One had to set up two consecutive registers with
>> the necessary information to describe the instruction.
> <
> I thought S5 had 16-bit instructions, but it has been a LONG time.
>>
>> The Sigma 7 had translate and test, edit, and all that stuff, like the 360.
>>
>> There were other machines that did it the same way; the Sigmas weren't
>> the only ones.
> <
> Interdata, S.E.L, and one other I can't remember right now.

Burroughs B500 series had an edit micro; essentially single argument
printf in an instruction.

>>
>> John Savard

On Monday, June 20, 2022 at 6:09:22 PM UTC-6, Quadibloc wrote:

> I was thinking of an option for a higher-end PDP-11,

Found it: the KE44-A Commercial Instruction Set Processor for the
PDP-11/44.

John Savard

MitchAlsup wrote:
> On Monday, June 20, 2022 at 5:32:40 PM UTC-5, Quadibloc wrote:
>> On Monday, June 20, 2022 at 10:50:43 AM UTC-6, MitchAlsup wrote:
>>
>>> Sigma 5-7-9 were IBM format ISAs without the memory to memory cruft.
>> I see that indeed the Sigma 5 didn't have that.
> <
> I spend 3 years programming real time applications in FORTRAN (and a bit
> of ASM) from 1975-1978. We were primarily limited at the data collection side
> of things, but we pounded down the ISR time so that "waiting for interrupt"
> to "ready to wait for interrupt" was only 12 cycles. In the mean time, we had
> to read an A/D converter, store the 22-bit quantity to memory, increment a
> pointer/index, do a limit check, and Return from interrupt. The S5 had no
> instruction cache, no data cache, and memory was 5 cycles away.

Nice work!

Reminds me of Drew Major at Novell who got the total processing time for
a file read request (on NetWare 386) down to ~300 clock cycles. I.e.
accepting the network packet interrupt, parsing the request (verifying
access rights etc), locating the relevant data somewhere in the memory
cache, construct the reply packet and hand it back to the network card.

Terje

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

On Monday, June 20, 2022 at 9:18:42 AM UTC-4, Quadibloc wrote:
> On Sunday, June 12, 2022 at 11:28:21 AM UTC-6, MitchAlsup wrote:
>
> > Now you are just adding complications to make op for the poor starting
> > position.
> Essentially, this all stems from... the Control Data 8600.
>
> That was to have been a 6600, but expanded from 60 bits to 64 bits. You noted
> that it failed. My guess was that it was because they intended the performance
> gain over the 7600 to be more than they could achieve.
>

I haven't heard of the 8600 before now, but reading the Wikipedia page it sounds
like the CDC 800 series borrowed a lot of architecture from it (except the SIMD stuff).
The CDC 800 series added segmentation though, so they weren't *really* looking for performance,
but security & reliability.

- Tim

On Monday, June 27, 2022 at 5:03:04 PM UTC-4, Timothy McCaffrey wrote:
> On Monday, June 20, 2022 at 9:18:42 AM UTC-4, Quadibloc wrote:
> > On Sunday, June 12, 2022 at 11:28:21 AM UTC-6, MitchAlsup wrote:
> >
> > > Now you are just adding complications to make op for the poor starting
> > > position.
> > Essentially, this all stems from... the Control Data 8600.
> >
> > That was to have been a 6600, but expanded from 60 bits to 64 bits. You noted
> > that it failed. My guess was that it was because they intended the performance
> > gain over the 7600 to be more than they could achieve.
> >
> I haven't heard of the 8600 before now, but reading the Wikipedia page it sounds
> like the CDC 800 series borrowed a lot of architecture from it (except the SIMD stuff).
> The CDC 800 series added segmentation though, so they weren't *really* looking for performance,
> but security & reliability.
>
> - Tim
Sorry, I meant the CDC Cyber 180 series (its been awhile).

On Saturday, June 11, 2022 at 7:24:57 PM UTC-6, Quadibloc wrote:
> Clearly, an old-style 24-bit machine, that has a memory-accumulator
> architecture instead of a general register architecture, and a 32k
> address space, wouldn't be very useful nowadays.

And thus, it's not very useful that the Control Data 924 has inspired
me to suggest a way to improve that kind of machine.

Many 24-bit machines had a three bit tag field, consisting of one
bit to indicate indirection, and two index bits to indicate no indexing,
or choose one of three index registers.

The 924, instead, had six index registers. The three bit tag field was
0 for plain direct addressing, 1 to 6 to pick one of the index registers,
and 7 for indirect addressing.

That was a great idea on the part of Seymour Cray, but I think it can
be improved just a bit.

Let us just have _five_ index registers.

0: direct addressing, no index
1 - 5: indexed, with the index register indicated
6: indirect
7: indexed with index register 1 _and_ indirect.

So the number of index registers is increased, but not only is
indirection not sacrificed, but also the ability to combine indirection and
indexing, albeit for only one index register, is also retained.

John Savard

On Friday, August 5, 2022 at 1:35:04 PM UTC-5, Quadibloc wrote:
> On Saturday, June 11, 2022 at 7:24:57 PM UTC-6, Quadibloc wrote:
> > Clearly, an old-style 24-bit machine, that has a memory-accumulator
> > architecture instead of a general register architecture, and a 32k
> > address space, wouldn't be very useful nowadays.
> And thus, it's not very useful that the Control Data 924 has inspired
> me to suggest a way to improve that kind of machine.
>
> Many 24-bit machines had a three bit tag field, consisting of one
> bit to indicate indirection, and two index bits to indicate no indexing,
> or choose one of three index registers.
>
> The 924, instead, had six index registers. The three bit tag field was
> 0 for plain direct addressing, 1 to 6 to pick one of the index registers,
> and 7 for indirect addressing.
>
> That was a great idea on the part of Seymour Cray, but I think it can
> be improved just a bit.
<
If it was so great, why did none of the RISC generation 1 machines or any
that followed them follow suit ?
>
> Let us just have _five_ index registers.
>
> 0: direct addressing, no index
> 1 - 5: indexed, with the index register indicated
> 6: indirect
> 7: indexed with index register 1 _and_ indirect.
>
> So the number of index registers is increased, but not only is
> indirection not sacrificed, but also the ability to combine indirection and
> indexing, albeit for only one index register, is also retained.
>
> John Savard

On Friday, August 5, 2022 at 1:35:04 PM UTC-5, Quadibloc wrote:
> On Saturday, June 11, 2022 at 7:24:57 PM UTC-6, Quadibloc wrote:
> > Clearly, an old-style 24-bit machine, that has a memory-accumulator
> > architecture instead of a general register architecture, and a 32k
> > address space, wouldn't be very useful nowadays.
> And thus, it's not very useful that the Control Data 924 has inspired
> me to suggest a way to improve that kind of machine.
>
> Many 24-bit machines had a three bit tag field, consisting of one
> bit to indicate indirection, and two index bits to indicate no indexing,
> or choose one of three index registers.
>
> The 924, instead, had six index registers. The three bit tag field was
> 0 for plain direct addressing, 1 to 6 to pick one of the index registers,
> and 7 for indirect addressing.
>
> That was a great idea on the part of Seymour Cray, but I think it can
> be improved just a bit.
>
> Let us just have _five_ index registers.
>
> 0: direct addressing, no index
> 1 - 5: indexed, with the index register indicated
> 6: indirect
> 7: indexed with index register 1 _and_ indirect.
>
> So the number of index registers is increased, but not only is
> indirection not sacrificed, but also the ability to combine indirection and
> indexing, albeit for only one index register, is also retained.
>
> John Savard
AFIR the CDC 924, 1604 and 3000 series varied between a single indirect bit with three index registers and six index registers and a single indirect mode. The 15-bit address/displacement field is no longer adequate, so may as well shorten the field and increase the number of index or base registers..
The Livermore Loops mostly use a single index register with up to 15 base registers. Question is if a single index register is sufficient in most loops? Am considering whether the index field should specify add or subtract the index register?

On 8/5/2022 12:11 PM, MitchAlsup wrote:
> On Friday, August 5, 2022 at 1:35:04 PM UTC-5, Quadibloc wrote:
>> On Saturday, June 11, 2022 at 7:24:57 PM UTC-6, Quadibloc wrote:
>>> Clearly, an old-style 24-bit machine, that has a memory-accumulator
>>> architecture instead of a general register architecture, and a 32k
>>> address space, wouldn't be very useful nowadays.
>> And thus, it's not very useful that the Control Data 924 has inspired
>> me to suggest a way to improve that kind of machine.
>>
>> Many 24-bit machines had a three bit tag field, consisting of one
>> bit to indicate indirection, and two index bits to indicate no indexing,
>> or choose one of three index registers.
>>
>> The 924, instead, had six index registers. The three bit tag field was
>> 0 for plain direct addressing, 1 to 6 to pick one of the index registers,
>> and 7 for indirect addressing.
>>
>> That was a great idea on the part of Seymour Cray, but I think it can
>> be improved just a bit.
> <
> If it was so great, why did none of the RISC generation 1 machines or any
> that followed them follow suit ?

I think John may have a different definition of "great" than most of the
rest of us. :-)

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

On Friday, August 5, 2022 at 1:11:45 PM UTC-6, MitchAlsup wrote:
> On Friday, August 5, 2022 at 1:35:04 PM UTC-5, Quadibloc wrote:

> > That was a great idea on the part of Seymour Cray, but I think it can
> > be improved just a bit.
> <
> If it was so great, why did none of the RISC generation 1 machines or any
> that followed them follow suit ?

I meant a great idea - in its day. The 924 was still a memory-accumulator
machine, and I'm not arguing that those are useful or practical at the
present time.

I also spend some time thinking about retrocomputing.

John Savard