I absolutely had to agree with Mitch Alsup about immediate values being so
much more efficient than ordinary memory references given the way RAM
works on today's machines.

But allowing immediates of any size was just totally incompatible with a
super-simple length indication for instructions like that of the IBM 360.

So inspired by heads or tails, but wanting to do better, I had my idea of
organizing instructions into blocks, with "pseudo-immediates"; the
instruction contains a pointer to the 'immediate', but it still isn't like fetching
a value from memory, because the pseudo-immediate is within
the instruction block.

But I refused to indicate where instructions ended, and supplementary
data began, by beginning the instructions with 0, 0, .... 1 as their first bit,
because this was too much of a temptation for a slow serial
implementation.

But that meant that any block with immediates had 32 bits of overhead,
because a full 32-bit instruction slot was the minimum thing you could
omit for a header! (Sometimes I managed to get it down to 16 bits,
because I did have a way to fit two 16-bit instructions in one instruction
slot, but that assumed a 16-bit instruction was useful at the start of a
block.)

Well, I have *finally* found a way out of the conundrum!

What I will do is this:

When there is a pair of instructions in a 32-bit instruction slot, it will
look like this:

0
15-bit instruction
0 15-bit instruction

The register-to-register instructions will look like this:
0 (15 bits including the opcode)
1 (15 bits, including the register fields)

and the memory-reference instructions, which need the last 16 bits clear for
the displacement will start with 1.

The trick is this:

Any block which contains a register-to-register instruction where one of the
input arguments is an immediate instead will begin with an instruction of
this form:

0
1111
3 bits: number of instruction slots not to be decoded
3 bits: effective instruction location
4 bits: opcode
C bit (1 if instruction sets the condition codes)
1 5 bits: opcode
5 bits: dR
5 bits: source pseudo-immediate pointer

So the overhead is cut down to about ten bits. The absolute minimum three
bits which indicate how much of the block is reserved for pseudo-
immediates, plus four bits to indicate there's an... instruction containing a
header... in the first instruction slot, plus three bits to indicate where, in the
sequence of instructions in the block, this particular immediate instruction
is to be positioned for execution.

One can also have an immediate instruction without the 1111 inside the
block which can have a longer opcode and/or destination, operand, and
source operands instead of just destination and source.

Finally, I've come up with a way to scrunch the overhead demanded by
pseudo-immediates down to a level I can live with.

John Savard

On Saturday, May 29, 2021 at 4:39:18 PM UTC-5, Quadibloc wrote:
> I absolutely had to agree with Mitch Alsup about immediate values being so
> much more efficient than ordinary memory references given the way RAM
> works on today's machines.
>
> But allowing immediates of any size was just totally incompatible with a
> super-simple length indication for instructions like that of the IBM 360.
>
> So inspired by heads or tails, but wanting to do better, I had my idea of
> organizing instructions into blocks, with "pseudo-immediates"; the
> instruction contains a pointer to the 'immediate', but it still isn't like fetching
> a value from memory, because the pseudo-immediate is within
> the instruction block.
>
> But I refused to indicate where instructions ended, and supplementary
> data began, by beginning the instructions with 0, 0, .... 1 as their first bit,
> because this was too much of a temptation for a slow serial
> implementation.
>
> But that meant that any block with immediates had 32 bits of overhead,
> because a full 32-bit instruction slot was the minimum thing you could
> omit for a header! (Sometimes I managed to get it down to 16 bits,
> because I did have a way to fit two 16-bit instructions in one instruction
> slot, but that assumed a 16-bit instruction was useful at the start of a
> block.)
>
> Well, I have *finally* found a way out of the conundrum!
>
> What I will do is this:
>
> When there is a pair of instructions in a 32-bit instruction slot, it will
> look like this:
>
> 0
> 15-bit instruction
> 0
> 15-bit instruction
<
See below: but when I saw this I thought::
2×5-bit register specifiers
5-bit OpCode
>
> The register-to-register instructions will look like this:
> 0
> (15 bits including the opcode)
> 1
> (15 bits, including the register fields)
<
10-bit OpCode, 5-bit destination register
up to 3×5-bit register specifiers.
<
Some of the OpCode field can be sacrificed to "point" at the immediate
>
> and the memory-reference instructions, which need the last 16 bits clear for
> the displacement will start with 1.
>
> The trick is this:
>
> Any block which contains a register-to-register instruction where one of the
> input arguments is an immediate instead will begin with an instruction of
> this form:
>
> 0
> 1111
> 3 bits: number of instruction slots not to be decoded
> 3 bits: effective instruction location
> 4 bits: opcode
> C bit (1 if instruction sets the condition codes)
> 1
> 5 bits: opcode
> 5 bits: dR
> 5 bits: source pseudo-immediate pointer
<
If you just had the 3-bit effective instruction location, it seems fairly
easy to scan the block and determine "number of slots not to be decoded"
saving you 3-bits for other encoding purposes.
<
But you are making forward progress.
>
> So the overhead is cut down to about ten bits. The absolute minimum three
> bits which indicate how much of the block is reserved for pseudo-
> immediates, plus four bits to indicate there's an... instruction containing a
> header... in the first instruction slot, plus three bits to indicate where, in the
> sequence of instructions in the block, this particular immediate instruction
> is to be positioned for execution.
>
> One can also have an immediate instruction without the 1111 inside the
> block which can have a longer opcode and/or destination, operand, and
> source operands instead of just destination and source.
>
> Finally, I've come up with a way to scrunch the overhead demanded by
> pseudo-immediates down to a level I can live with.
>
> John Savard

On Saturday, May 29, 2021 at 5:30:22 PM UTC-6, MitchAlsup wrote:

> If you just had the 3-bit effective instruction location, it seems fairly
> easy to scan the block and determine "number of slots not to be decoded"
> saving you 3-bits for other encoding purposes.

Perhaps I didn't make clear what the effective instruction location was.

In a block that contains one or more immediate instructions, unless a
full header taking up 32 bits is needed for other reasons, if one of the
immediate instructions only needs a 9-bit opcode and only needs two
operands,

then that immediate instruction is placed in instruction slot 0 of the eight
instruction slots in the block.

The effective instruction location says which slot the instruction is treated
as being in for purposes of determining execution order.

So if EIL = 4, then the instructions in slots 1, 2, 3, and 4 are first performed
in order, then the instruction in slot 0, then the instructions in slots 5 and 6,
if present.

Since it's not clear whether 1, 2, or 3 instruction slots at the end of the block
will not be used for instructions, the decode field is still required.

But other aspects of this have let me squeeze things so that the load multiple
and store multiple instructions no longer force one to use one of the shorter
displacement types and alternate sets of base registers, instead full 16-bit
displacements are possible.

The price?

Because there's no bit to indicate whether the instruction is 'load multiple'
or 'store multiple'...

1) a load multiple or store multiple instruction _must_ operate on two or more
registers, and

2) if the fields contain the low register first, it's a load; if the high register is in
the first field, it's a store.

Another price is that I lose access to some of the addressing modes from within
32-bit instructions since I had to use only aligned load/store instructions to get
everything to fit. Avoiding those restrictions will be one of the reasons for
using a full 32-bit header, or for using 64-bit instructions.

The intent is that instructions use only 32 bits almost all the time, but in the cases
where more is needed, it is available.

John Savard

On Saturday, May 29, 2021 at 8:18:11 PM UTC-5, Quadibloc wrote:
> On Saturday, May 29, 2021 at 5:30:22 PM UTC-6, MitchAlsup wrote:
>
> > If you just had the 3-bit effective instruction location, it seems fairly
> > easy to scan the block and determine "number of slots not to be decoded"
> > saving you 3-bits for other encoding purposes.
<
> Perhaps I didn't make clear what the effective instruction location was.
>
> In a block that contains one or more immediate instructions, unless a
> full header taking up 32 bits is needed for other reasons, if one of the
> immediate instructions only needs a 9-bit opcode and only needs two
> operands,
>
> then that immediate instruction is placed in instruction slot 0 of the eight
> instruction slots in the block.
>
> The effective instruction location says which slot the instruction is treated
> as being in for purposes of determining execution order.
>
> So if EIL = 4, then the instructions in slots 1, 2, 3, and 4 are first performed
> in order, then the instruction in slot 0, then the instructions in slots 5 and 6,
> if present.
<
What if any of instructions 1,2,3,4 need the result of the immediate instruction ?
<
What if instruction 2 is a branch/predicate and the immediate instruction is
under the shadow of that branch ?
<
What if there are multiple instructions needing immediates ?
>
> Since it's not clear whether 1, 2, or 3 instruction slots at the end of the block
> will not be used for instructions, the decode field is still required.
>
> But other aspects of this have let me squeeze things so that the load multiple
> and store multiple instructions no longer force one to use one of the shorter
> displacement types and alternate sets of base registers, instead full 16-bit
> displacements are possible.
>
> The price?
>
> Because there's no bit to indicate whether the instruction is 'load multiple'
> or 'store multiple'...
<
Why is this not an OpCode that otherwise simply smells like a memory ref ?
>
> 1) a load multiple or store multiple instruction _must_ operate on two or more
> registers, and
<
While My 66000 uses the same memory format as LD/STs, it interprets the register
specifiers differently Rstart = Rd, Rstop = Rindex; Rbase remains the same.
>
> 2) if the fields contain the low register first, it's a load; if the high register is in
> the first field, it's a store.
<
What if you wanted to save registers R16-through-R31-wrap-to-R0-through-R8
in a single STM ?
>
> Another price is that I lose access to some of the addressing modes from within
> 32-bit instructions since I had to use only aligned load/store instructions to get
> everything to fit. Avoiding those restrictions will be one of the reasons for
> using a full 32-bit header, or for using 64-bit instructions.
>
> The intent is that instructions use only 32 bits almost all the time, but in the cases
> where more is needed, it is available.
>
> John Savard

On Saturday, May 29, 2021 at 8:05:32 PM UTC-6, MitchAlsup wrote:
> On Saturday, May 29, 2021 at 8:18:11 PM UTC-5, Quadibloc wrote:

> > So if EIL = 4, then the instructions in slots 1, 2, 3, and 4 are first performed
> > in order, then the instruction in slot 0, then the instructions in slots 5 and 6,
> > if present.

> What if any of instructions 1,2,3,4 need the result of the immediate instruction ?

Well, then it was a mistake to set the effective instruction location to 4.

The instruction is in the first slot because it needs to be in order to also serve as
the block prefix. But the effective instruction location is where it "really" is as far
as execution is concerned.

> What if instruction 2 is a branch/predicate and the immediate instruction is
> under the shadow of that branch ?

Then if the branch takes place, the instruction will not be executed.

> What if there are multiple instructions needing immediates ?

The other immediate instructions in the block will be _ordinary_
immediate instructions, which have more room for an opcode, and
which may have three operands instead of only two. So the only
restriction is that at least one of the immediate instructions in a block
must fit into the limitations of the header/immediate - if that isn't the
case, one needs to spend a full 32 bits on a header.

> > Because there's no bit to indicate whether the instruction is 'load multiple'
> > or 'store multiple'...

> Why is this not an OpCode that otherwise simply smells like a memory ref ?

I have to specify _two_ registers for a load multiple or store multiple. And I
don't quite have enough bits out of the 32 bits in an instruction to fit them in.

Previously, I got around this by omitting the address format with a 3-bit
base register specifier and a 16-bit displacement. By saving 3 bits, and only
using the short address formats, everything fit. But now I had squeezed things
enough that I was able - just barely - to avoid that omission.

> What if you wanted to save registers R16-through-R31-wrap-to-R0-through-R8
> in a single STM ?

You're out of luck. Actually, though, I think that there _will_ be an alternative
version of the load/store multiple instruction that may be 64 bits long.

Since I've discarded my old idea of using a pSupp to go with the pImm - to have
long instructions that have a pointer to a supplemental part that is a multiple of
16 bits in length - as too wasteful and cumbersome, what I seem to be left with
is a "don't decode" set of bits at the start of the instruction slot which allows
only multiples of 32 bits for an instruction.

I'm looking for something better that isn't also ridiculously complicated.

One possibility I've used before would be: begin the block with 1111, and now
the rest of it is seven instruction slots that are 36 bits long, with provision for
instruction lengths of any multiple of 18 bits. (For purposes of branching,
pretend the first four bits are 32 bits long, and every 18 bits that follows is 16 bits.)

I may do this again, except with the modification that the first two bits of every
18 bits will actually be grouped together at the beginning, so that fewer wires are
needed to connect to the existing decode circuitry looking at instructions the old
way.

Or I could come up with something better, although I am not greatly optimistic.

John Savard

My web site has now been updated. The old version of the
Concertina II architecture has been removed, and the beginning
of the description of the new version now begins at:

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

John Savard

On Saturday, May 29, 2021 at 8:05:32 PM UTC-6, MitchAlsup wrote:

> What if you wanted to save registers R16-through-R31-wrap-to-R0-through-R8
> in a single STM ?

I have been able to squeeze in an unrestricted 32-bit set of load and store multiple
instructions in the 'extended' instruction set, available using the fifth and sixth
header formats.

This was done by organizing the 'extended' instruction set so that 32-bit
instructions were effectively increased to 33 bits in length, and even then,
these instructions were just barely squeezed in.

Basically, I viewed it as vital to allow the load and store multiple instructions to use
16-bit displacements, so that they could use the same registers as base registers
as other memory-reference instructions. If instead their address modes were restricted,
using these instructions would be awkward; extra registers would have to be loaded and
tied up as base registers. Avoiding that for all use of those instructions was something
I viewed as _much_ more important than handling a corner case like wrapping around
the registers to be saved or loaded.

After all, trade-offs do have to be made; the issue arises from the fact that I'm using
RISC-like register banks of 32 registers, instead of just 8 registers, as I did in the
original Concertina architecture.

The extended instruction set - at least the 32-bit instructions in it - are visible on
the page

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

which has now been uploaded.

John Savard

On Saturday, May 29, 2021 at 9:30:39 PM UTC-6, Quadibloc wrote:
> On Saturday, May 29, 2021 at 8:05:32 PM UTC-6, MitchAlsup wrote:
> > On Saturday, May 29, 2021 at 8:18:11 PM UTC-5, Quadibloc wrote:

> > > Because there's no bit to indicate whether the instruction is 'load multiple'
> > > or 'store multiple'...

> > Why is this not an OpCode that otherwise simply smells like a memory ref ?

> I have to specify _two_ registers for a load multiple or store multiple. And I
> don't quite have enough bits out of the 32 bits in an instruction to fit them in.

Now I've figured out why you phrased your question in that specific way.

In some architectures, a load/store multiple can indeed look just like a
memory-reference instruction. The destination register field might contain
the "low register", while the index register field contains the "high register",
so the only restriction on load/store multiple instructions is that they
aren't indexable.

So there is a specific "why". The register banks in this architecture,
as it is RISC-like in some ways, have 32 bits in them. So the destination
register field in a memory-reference instruction, and the high and low
register fields in a load and store multiple instruction, are five bits long.

But because I support, in a 32-bit memory-reference instruction, a
sixteen-bit displacement (like the 68000 and many other microcomputer
architectures, but unlike the twelve-bit displacement of the System/360)
and base-index addressing (whereas the 68020 forced you to use a 48-bit
instruction if you wanted a base, and index, and a 16-bit displacement)...
something had to give.

So in a 32-bit memory-reference instruction, the base register field is _three
bits_ and the index register field is _three bits_ in length. Not *five* bits.

So while I do have the load and store multiple instructions as non-indexable,
that still leaves me with two bits I have to find somewhere.

John Savard

On Monday, May 31, 2021 at 8:39:19 AM UTC-5, Quadibloc wrote:
> On Saturday, May 29, 2021 at 8:05:32 PM UTC-6, MitchAlsup wrote:
> > What if you wanted to save registers R16-through-R31-wrap-to-R0-through-R8
> > in a single STM ?
> I have been able to squeeze in an unrestricted 32-bit set of load and store multiple
> instructions in the 'extended' instruction set, available using the fifth and sixth
> header formats.
>
> This was done by organizing the 'extended' instruction set so that 32-bit
> instructions were effectively increased to 33 bits in length, and even then,
> these instructions were just barely squeezed in.
>
> Basically, I viewed it as vital to allow the load and store multiple instructions to use
> 16-bit displacements, so that they could use the same registers as base registers
> as other memory-reference instructions. If instead their address modes were restricted,
> using these instructions would be awkward; extra registers would have to be loaded and
> tied up as base registers. Avoiding that for all use of those instructions was something
> I viewed as _much_ more important than handling a corner case like wrapping around
> the registers to be saved or loaded.
<
One of the important things LDM and STM do is to save and restore registers at
prologue and epilogue of subroutines. Here since we KNOW that the data is going
on the stack and we know the stack needs to grow downward, we can combine
all three effects and that is essentially what ENTER and EXIT do. Rsp is the stack
pointer and upon arrival at the subroutine points at the lowest doubleword on the
stack. So we dump the registers on the stack in reverse order while growing the
stack for each register and when the last register has been stored, we add the
immediate to the (now modified) stack pointer -- allocating local data storage.
<
Here Rd = Rstart, Rbase = Rstop, Rsp is implied, and imm16 is the size of LDS
(not including saved registers). {{If I get around to building the "safe stack"
the threads will not be allowed access to the stored register areas--preventing
ROP attacks; only ENTER and EXIT have access to this data. Note: without an
instruction such as ENTER you don't have the information necessary to guard
many multiple safe areas on the stack.}}
<
This is the immediate for of LDM and STM. Then there is a memory ref version
[Rbase+Rindex<<scale+disp] of LDM and STM which can point anywhere in memory.
<
>
> After all, trade-offs do have to be made; the issue arises from the fact that I'm using
> RISC-like register banks of 32 registers, instead of just 8 registers, as I did in the
> original Concertina architecture.
>
> The extended instruction set - at least the 32-bit instructions in it - are visible on
> the page
>
> http://www.quadibloc.com/arch/cp0102.htm
>
> which has now been uploaded.
>
> John Savard

On Monday, May 31, 2021 at 8:47:34 AM UTC-5, Quadibloc wrote:
> On Saturday, May 29, 2021 at 9:30:39 PM UTC-6, Quadibloc wrote:
> > On Saturday, May 29, 2021 at 8:05:32 PM UTC-6, MitchAlsup wrote:
> > > On Saturday, May 29, 2021 at 8:18:11 PM UTC-5, Quadibloc wrote:
>
> > > > Because there's no bit to indicate whether the instruction is 'load multiple'
> > > > or 'store multiple'...
>
> > > Why is this not an OpCode that otherwise simply smells like a memory ref ?
>
> > I have to specify _two_ registers for a load multiple or store multiple. And I
> > don't quite have enough bits out of the 32 bits in an instruction to fit them in.
<
> Now I've figured out why you phrased your question in that specific way.
<
I've been waiting........
>
> In some architectures, a load/store multiple can indeed look just like a
> memory-reference instruction. The destination register field might contain
> the "low register", while the index register field contains the "high register",
> so the only restriction on load/store multiple instructions is that they
> aren't indexable.
>
> So there is a specific "why". The register banks in this architecture,
> as it is RISC-like in some ways, have 32 bits in them. So the destination
> register field in a memory-reference instruction, and the high and low
> register fields in a load and store multiple instruction, are five bits long.
<
So, as noted above, I use Rsp as the base for ENTER and EXIT even
though it is not encoded with the instruction ! And I use Rbase as
the base pointer for LDM/STM in the 2-operand memory reference
OpCode space where I have access to 32-bit and 64-bit displacements.
>
> But because I support, in a 32-bit memory-reference instruction, a
> sixteen-bit displacement (like the 68000 and many other microcomputer
> architectures, but unlike the twelve-bit displacement of the System/360)
> and base-index addressing (whereas the 68020 forced you to use a 48-bit
> instruction if you wanted a base, and index, and a 16-bit displacement)...
> something had to give.
<
I might note that since LDM/STM perform so much data movement, it is
OK that they take up more than 32-bits of the instruction stream. Just a
thought.
>
> So in a 32-bit memory-reference instruction, the base register field is _three
> bits_ and the index register field is _three bits_ in length. Not *five* bits.
<
Yuck !
>
> So while I do have the load and store multiple instructions as non-indexable,
> that still leaves me with two bits I have to find somewhere.
>
> John Savard

On Monday, May 31, 2021 at 10:29:08 AM UTC-6, MitchAlsup wrote:

> I might note that since LDM/STM perform so much data movement, it is
> OK that they take up more than 32-bits of the instruction stream. Just a
> thought.

Oh, yes. I basically agree with that, _but_, since my Concertina II architecture,
at least in most of its incarnations, *required* that a block have a header if
instructions are going to have the ability to be longer than 32 bits, any instruction
that is common enough that most programs will need at least one... is highly
desirable to make available in a 32 bit length, if at all possible.

> > So in a 32-bit memory-reference instruction, the base register field is _three
> > bits_ and the index register field is _three bits_ in length. Not *five* bits.

> Yuck !

Yes, I realize that this constitutes a sad departure from orthogonality.

So of the 32 general registers, from 0 to 31, only registers 1 through 7 may
be index registers, and only registers 25 through 31 may be ordinary
base registers, pointing to a 65,536-byte segment in memory.

If this hadn't been the case, and these fields had been five bits long, there is
no way I could have made the address formats I desired fit into a 32-bit
word. My goal is to achieve the nearly impossible task of...

matching the IBM System/360 in how much space instructions of different
types take up, while

having 32 registers instead of 16,

and having 16-bit displacements instead of 12-bit displacements.

Back when I just had 8 registers, I managed by shortening the opcode
field to seven bits for general memory-reference instructions. With 32
registers, something has to give - trade-offs have to be made.

So my architecture attempts to straddle the divide between a 32-register
RISC and an 8-register CISC.

John Savard

On 5/31/2021 2:07 PM, Quadibloc wrote:
> On Monday, May 31, 2021 at 10:29:08 AM UTC-6, MitchAlsup wrote:
>
>> I might note that since LDM/STM perform so much data movement, it is
>> OK that they take up more than 32-bits of the instruction stream. Just a
>> thought.
>
> Oh, yes. I basically agree with that, _but_, since my Concertina II architecture,
> at least in most of its incarnations, *required* that a block have a header if
> instructions are going to have the ability to be longer than 32 bits, any instruction
> that is common enough that most programs will need at least one... is highly
> desirable to make available in a 32 bit length, if at all possible.
>
>>> So in a 32-bit memory-reference instruction, the base register field is _three
>>> bits_ and the index register field is _three bits_ in length. Not *five* bits.
>
>> Yuck !
>
> Yes, I realize that this constitutes a sad departure from orthogonality.

As perhaps a lightly less ugly departure, at the cost of a little
generality, you could require the starting register number for a LDM/STM
to be say a multiple of 4, thus saving 2 bits. Also, instead of making
the second field a register number to stop at, you could make it a count
of the number of registers, and also, by a slight loss in generality
require the count to be a multiple of say 2, thus saving another bit.
Obvious variations are possible. Since, as Mitch pointed out, the major
use of these is on function calls, you can make the all part of the ABI.

Not great, but perhaps better than the restrictions you indicated.

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

On Monday, May 31, 2021 at 4:44:50 PM UTC-5, Stephen Fuld wrote:
> On 5/31/2021 2:07 PM, Quadibloc wrote:
> > On Monday, May 31, 2021 at 10:29:08 AM UTC-6, MitchAlsup wrote:
> >
> >> I might note that since LDM/STM perform so much data movement, it is
> >> OK that they take up more than 32-bits of the instruction stream. Just a
> >> thought.
> >
> > Oh, yes. I basically agree with that, _but_, since my Concertina II architecture,
> > at least in most of its incarnations, *required* that a block have a header if
> > instructions are going to have the ability to be longer than 32 bits, any instruction
> > that is common enough that most programs will need at least one... is highly
> > desirable to make available in a 32 bit length, if at all possible.
> >
> >>> So in a 32-bit memory-reference instruction, the base register field is _three
> >>> bits_ and the index register field is _three bits_ in length. Not *five* bits.
> >
> >> Yuck !
> >
> > Yes, I realize that this constitutes a sad departure from orthogonality.
> As perhaps a lightly less ugly departure, at the cost of a little
> generality, you could require the starting register number for a LDM/STM
> to be say a multiple of 4, thus saving 2 bits. Also, instead of making
> the second field a register number to stop at, you could make it a count
> of the number of registers, and also, by a slight loss in generality
> require the count to be a multiple of say 2, thus saving another bit.
> Obvious variations are possible. Since, as Mitch pointed out, the major
> use of these is on function calls, you can make the all part of the ABI.
<
Yes, notice that I imply SP as the Rbase for the function call prologue
and epilogue--saving the register specifier entirely.
>
> Not great, but perhaps better than the restrictions you indicated.
<
The other big use of LDM and STM is structure assignment, for which
My 66000 has MM memory to memory move Rfrom, Rto, Rbytes.
>
>
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On Monday, May 31, 2021 at 3:44:50 PM UTC-6, Stephen Fuld wrote:

> Not great, but perhaps better than the restrictions you indicated.

The restrictions on the index and base registers aren't just for the
LM and STM instructions, but for *all the memory-reference
instructions* in order to make load-store memory-reference
instructions that work with all 32 registers, and allow full base-index
addressing, possible.

John Savard

On Monday, May 31, 2021 at 5:23:24 PM UTC-5, Quadibloc wrote:
> On Monday, May 31, 2021 at 3:44:50 PM UTC-6, Stephen Fuld wrote:
>
> > Not great, but perhaps better than the restrictions you indicated.
> The restrictions on the index and base registers aren't just for the
> LM and STM instructions, but for *all the memory-reference
> instructions* in order to make load-store memory-reference
> instructions that work with all 32 registers, and allow full base-index
> addressing, possible.
<
With My 66000,
LD Rd,[Rb+Disp16] is a 32-bit instruction
LD Rd,[Rb+Rindex<<s] is a 32-bit instruction
LD Rd,[Rb+Ri<<s+Disp] is a 64-bit instruction or a 96 bit instruction
<
The flavor with both registers and displacement is only used on the
order of 2% of the time.
>
> John Savard

On Monday, May 31, 2021 at 5:46:49 PM UTC-6, MitchAlsup wrote:

> The flavor with both registers and displacement is only used on the
> order of 2% of the time.

Well, that may be. But I have a basic goal of allowing code to be
produced that is as functional, and as dense, as that of the IBM
System/360. To further approach that goal, I have just updated
the pages on the architecture with another change to more fully
achieve that goal; now, at least in the extended instruction mode,
I have 32-bit instructions that are memory-reference instructions
which are not restricted to being load/store operations. However,
these are limited to displacements shorter than the normal 16-bit
displacement, as that is now unavoidable.

John Savard

On 2021-06-01, MitchAlsup wrote:
> On Monday, May 31, 2021 at 5:23:24 PM UTC-5, Quadibloc wrote:
>> On Monday, May 31, 2021 at 3:44:50 PM UTC-6, Stephen Fuld wrote:
>>
>>> Not great, but perhaps better than the restrictions you indicated.
>> The restrictions on the index and base registers aren't just for the
>> LM and STM instructions, but for *all the memory-reference
>> instructions* in order to make load-store memory-reference
>> instructions that work with all 32 registers, and allow full base-index
>> addressing, possible.
> <
> With My 66000,
> LD Rd,[Rb+Disp16] is a 32-bit instruction
> LD Rd,[Rb+Rindex<<s] is a 32-bit instruction
> LD Rd,[Rb+Ri<<s+Disp] is a 64-bit instruction or a 96 bit instruction
> <
> The flavor with both registers and displacement is only used on the
> order of 2% of the time.

Out of curiosity: How would you characterize the HW cost of adding three
integers vs. only adding two integers (esp. in terms of timing and
delays)?

I guess that in your design it would mostly be a matter of setting one
of the three addends to zero to perform reg+disp or reg+index.

And another question: I have seen that you often present statistics
about how common certain instructions are. What data do you usually use
to get those numbers?

I have found that it's really hard to get consistent measurements of how
common certain operations are, as they are influenced by lots of things
such as the code base, compiler, optimization flags, target ISA, etc.

/Marcus

>>
>> John Savard

On Tuesday, June 1, 2021 at 12:51:47 AM UTC-6, Marcus wrote:

> Out of curiosity: How would you characterize the HW cost of adding three
> integers vs. only adding two integers (esp. in terms of timing and
> delays)?

Even a duffer like myself can answer that question.

A clever circuit has been found, called the "carry-save adder", which allows
three integers to be added, not to just one integer, but to two integers, which
doesn't need to wait for carry propagation at all.

Therefore, three integers can be sent to a carry-save adder stage, and then
its output can be sent to a conventional adder (with, of course, carry-select
circuitry to make it as fast as possible) so that adding three integers will only
take a small number of gate delays above that for adding two.

The main use of the carry-save adder is to expedite adding together all
the partial sums in a high-speed multiplier.

John Savard

On Monday, May 31, 2021 at 11:47:20 PM UTC-6, Quadibloc wrote:
> To further approach that goal, I have just updated
> the pages on the architecture

....another update has taken place, to make explicitly visible where
room for expansion of the register-to-register operate instructions
exists in the basic and extended instruction sets.

John Savard

On Tuesday, June 1, 2021 at 1:51:47 AM UTC-5, Marcus wrote:
> On 2021-06-01, MitchAlsup wrote:
> > On Monday, May 31, 2021 at 5:23:24 PM UTC-5, Quadibloc wrote:
> >> On Monday, May 31, 2021 at 3:44:50 PM UTC-6, Stephen Fuld wrote:
> >>
> >>> Not great, but perhaps better than the restrictions you indicated.
> >> The restrictions on the index and base registers aren't just for the
> >> LM and STM instructions, but for *all the memory-reference
> >> instructions* in order to make load-store memory-reference
> >> instructions that work with all 32 registers, and allow full base-index
> >> addressing, possible.
> > <
> > With My 66000,
> > LD Rd,[Rb+Disp16] is a 32-bit instruction
> > LD Rd,[Rb+Rindex<<s] is a 32-bit instruction
> > LD Rd,[Rb+Ri<<s+Disp] is a 64-bit instruction or a 96 bit instruction
> > <
> > The flavor with both registers and displacement is only used on the
> > order of 2% of the time.
<
> Out of curiosity: How would you characterize the HW cost of adding three
> integers vs. only adding two integers (esp. in terms of timing and
> delays)?
<
3-input adder is 2 gate delays slower than a 2-input adder, and under 8% bigger.
>
> I guess that in your design it would mostly be a matter of setting one
> of the three addends to zero to perform reg+disp or reg+index.
>
> And another question: I have seen that you often present statistics
> about how common certain instructions are. What data do you usually use
> to get those numbers?
<
Mostly, I took the data from Hennessy and Patterson and cooked it in
a spreadsheet. They had data from VAX, and a couple of RISC machines.
So depending on how close your machine is to one of theirs, I vary the
blending. For example, H&P has data on how often constants are pasted
together, so after cooking this data is then removed from the My 66000
instruction stream, while judiciously added to the size of the instructions.
Also since I have predicates and none of their machines do, I took some
data from papers and, again, suitably alter the instruction statistics.
<
Finally, I take sample code from Brian's compiler and see if the cooked
data is representative of actual produced instruction. I have "read' the
ASM of his LLVM front end, Livermore Loops, and a few other choice
applications. I wish I had access of SPEC (of any era) so I could "read"
that, too.
>
> I have found that it's really hard to get consistent measurements of how
> common certain operations are, as they are influenced by lots of things
> such as the code base, compiler, optimization flags, target ISA, etc.
<
It is a lot easier to figure out the stats (or read them) when all the SIMD
stuff is turned off.
>
> /Marcus
>
> >>
> >> John Savard

Marcus <m.delete@this.bitsnbites.eu> schrieb:
> On 2021-06-01, MitchAlsup wrote:
>> On Monday, May 31, 2021 at 5:23:24 PM UTC-5, Quadibloc wrote:
>>> On Monday, May 31, 2021 at 3:44:50 PM UTC-6, Stephen Fuld wrote:
>>>
>>>> Not great, but perhaps better than the restrictions you indicated.
>>> The restrictions on the index and base registers aren't just for the
>>> LM and STM instructions, but for *all the memory-reference
>>> instructions* in order to make load-store memory-reference
>>> instructions that work with all 32 registers, and allow full base-index
>>> addressing, possible.
>> <
>> With My 66000,
>> LD Rd,[Rb+Disp16] is a 32-bit instruction
>> LD Rd,[Rb+Rindex<<s] is a 32-bit instruction
>> LD Rd,[Rb+Ri<<s+Disp] is a 64-bit instruction or a 96 bit instruction
>> <
>> The flavor with both registers and displacement is only used on the
>> order of 2% of the time.
>
> Out of curiosity: How would you characterize the HW cost of adding three
> integers vs. only adding two integers (esp. in terms of timing and
> delays)?

One option would be to use one layer of full adders to reduce the
three numbers to two. You keep the low-order bit and continue
with adding two numbers together, one of which is one bit shorter.

On Saturday, May 29, 2021 at 8:05:32 PM UTC-6, MitchAlsup wrote:

> What if you wanted to save registers R16-through-R31-wrap-to-R0-through-R8
> in a single STM ?

While I felt my forwards-only no-wrap-around restricton was an entirely reasonable
restriction as a trade-off,

there was a different reason why I, too, very much disliked the trick I used.

Checking to see if the register number in the 'start' register field was greater than,
or less than, the register number in the 'end' register field... complicated instruction
decoding unduly, in my opinion.

So, loath as I was to contemplate it, I was able to remove this restriction, and gain
one opcode bit, by moving the load and store multiple instructions to an otherwise
unsuable portion of the opcode space by moving over some of the fields in the
instruction (but at least I was able to avoid splitting any fields into two pieces).

The update is on the page

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

John Savard

MitchAlsup <MitchAlsup@aol.com> schrieb:

> Finally, I take sample code from Brian's compiler and see if the cooked
> data is representative of actual produced instruction. I have "read' the
> ASM of his LLVM front end, Livermore Loops, and a few other choice
> applications. I wish I had access of SPEC (of any era) so I could "read"
> that, too.

I have done a bit of disassembly on POWER and done some very
rudimentary statistics, with a view towards what a kind of
compressed instruction set should have.

Of course, this does not help for constructs which POWER does
not support.

Here is an example output from /usr/bin/git :

destructive three register op: 4327
non-destructive three register op: 1223
destructive register constant op: 34891
two register op: 4864
non-destructive register constant op: 29326
load/store with constant offset: 93058
fp load/store with constant offset: 26
load/store base+index reg: 4038
load immediate: 22058
load immediate and shift: 2827
move register: 31607
move special: 8764
compare instructions: 22160
branch instructions: 65712
of which bctr: 240
of which blr: 3302
of which bctrl: 217
floating point operations: 61
byte reversal: 82
condition register set: 13
vector scalar registers: 588
altivec: 38
load/store base+index fp: 0
barrier: 0
supervisor call: 0
abort trap: 0
default prefetch: 0
nop: 23345
service processor attention: 2
load / store offset statistics:
offset = 0: 7787
1 <= abs(offset) < 15: 2407, 616 disible by 4
16 <= abs(offset) < 128: 61950, 61596 disible by 4
128 <= abs(offset) < 2048: 13746, 13663 disible by 4
2048 <= abs(offset) 7168, 7046 disible by 4
Branch statistics:
offset < 127: 5035
128 <= offset < 2048: 9760
2048 <= offset < 4096: 1540
4096 <= offset < 8192: 1211
8192 <= offset < 32768: 1645
32768 <= offset < 65536: 673
65536 <= offset <131072: 1389
132027<= offset <262144: 2425
262144<= offset 16191

By comparison, here is a scientific code, aermod.f90 from
the Polyhedron benchmark suite:

destructive three register op: 7866
non-destructive three register op: 1523
destructive register constant op: 19791
two register op: 2854
non-destructive register constant op: 24625
load/store with constant offset: 56247
fp load/store with constant offset: 10309
load/store base+index reg: 2101
load immediate: 17422
load immediate and shift: 2026
move register: 5994
move special: 2109
compare instructions: 7099
branch instructions: 23590
of which bctr: 50
of which blr: 805
of which bctrl: 8
floating point operations: 8255
byte reversal: 62
condition register set: 961
vector scalar registers: 2523
altivec: 93
load/store base+index fp: 1720
barrier: 0
supervisor call: 0
abort trap: 0
default prefetch: 0
nop: 13563
service processor attention: 1
load / store offset statistics:
offset = 0: 630
1 <= abs(offset) < 15: 382, 260 disible by 4
16 <= abs(offset) < 128: 21435, 21424 disible by 4
128 <= abs(offset) < 2048: 12760, 12757 disible by 4
2048 <= abs(offset) 21040, 20922 disible by 4
Branch statistics:
offset < 127: 3334
128 <= offset < 2048: 7217
2048 <= offset < 4096: 1185
4096 <= offset < 8192: 906
8192 <= offset < 32768: 901
32768 <= offset < 65536: 620
65536 <= offset <131072: 569
132027<= offset <262144: 1266
262144<= offset 6111
Instructions: 213306

By comparison, you see theat there are far more floating point
operations (obviously).

Also, load and store with a constant offset seems to be a
very frequent operation no matter what.

Seeing which of the operations could have been fused into
a load or store from register + register + offset would
require a much more elaborate analysis than my simplistic
Perl script.

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

On Monday, May 31, 2021 at 11:47:20 PM UTC-6, Quadibloc wrote:
> On Monday, May 31, 2021 at 5:46:49 PM UTC-6, MitchAlsup wrote:

> > The flavor with both registers and displacement is only used on the
> > order of 2% of the time.

> Well, that may be. But I have a basic goal of allowing code to be
> produced that is as functional, and as dense, as that of the IBM
> System/360.

So, the idea is:

A register-to-register arithmetic instruction takes only 16 bits on the IBM 360!

Well, all right, there are 16-bit register-to-register instructions on this architecture,
although they come with certain restrictions those on the 360 don't have.

Memory-reference instructions with full base-index addressing take only 32 bits
on the IBM 360!

Load and store instructions with full base-index addressing are provided in this
architecture, despite the fact that register banks have 32 registers instead of 15,
and a 16-bit displacement (to match that used on the 68000 and many other modern
architectures) instead of a 12-bit displacement is used.

Aside from only allowing load and store instructions, other restrictions include having
only seven possible index registers instead of fifteen, only seven possible base registers
instead of fifteen, and only allowing the addresses of aligned operands to be specified
(a trick, used on the SEL 32 minicomputer is used to allow this limitation to provide additional
opcode space).

There's also an extended mode, which allows only seven instruction slots instead of eight
per 256-bit block. In that mode, some restrictions are lifted.

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

Memory-reference operate instructions (for the most common and standard arithmetic
operations) are provided. These are restricted to aligned operands, and they also have an
additional restriction, in that the form with 16-bit displacements is not available.

In addition to the seven of the general registers which may be used as base registers
with 16-bit displacements, one register may also be used as the base register for a 15-bit
displacement, and another seven registers may be used as base registers with 12-bit
displacements. The remaining modes when the one with 16-bit displacements is removed
are available for these instructions.

And the extended mode also provides for instructions like the string and packed-decimal
instructions of the 360. These have a 48-bit form which matches the length of the corresponding
System/360 instructions, but which has the restriction that 16-bit displacements are not
available, and they also have a 64-bit form which does allow 16-bit displacements, and
even indexing.

Attempting to approach the instruction density of the System/360 may seem like a fairly
useless goal in itself, except possibly for marketing purposes, but attention has _also_
been paid to minimizing the overhead impacts of meeting that goal. So effort may have been
apparently wasted in keeping some rare instructions short, but this has not led to more common
instructions becoming *longer*.

John Savard