Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Saturday, June 19, 2021 at 3:30:55 AM UTC-6, Theo wrote:
>
> > You would probably have to force alignment, effectively making instruction
> > words 72 bits and packing two instructions per word. That means you could
> > only branch into the first instruction of a word and might mean you'd have
> > to pad with NOPs in some circumstances. That would probably be doable
> > though, and the tradeoff might be worth it.
>
> I can see that alignment to byte boundaries is important, but why that would
> prevent branching to the second instruction is unclear.
>
> How to tell, when branching to a byte, if it is the first or second instruction in
> 72 bits that starts there? Also align to multiples of nine bytes, not just to the
> byte, even though that is not a physical memory issue.

I'm not sure I quite follow. Given instructions are aligned on 4.5 byte
addresses, then instruction pairs are aligned on 9 byte boundaries. You
could maybe work out if an address was divisible by 9 to determine if it's
the start of a pair or not, and if not assume the instruction is the second
of a pair. Not impossible but it's rather unwieldy to do that. You can do
it in hardware for the instruction fetch but there are times when software
needs to know too - maybe you would need a special instruction to do 'mod 9'
efficiently.

Another way around it would be to have a variation of a branch instruction
that says 'branch to the second of the pair'. But that wouldn't play nicely
with indirect branches where you only have the new PC and no information
which half it's going to.

I think you could probably make it work, although I think there's still risk
of confusing instruction halves, and it would be nice to avoid any
ambiguity.

Theo

Dne pondělí 21. června 2021 v 9:22:11 UTC+2 uživatel Quadibloc napsal:
> On Sunday, June 20, 2021 at 4:53:58 PM UTC-6, MitchAlsup wrote:
>
> > I would suggest you detect page crossings and not allow instructions to straddle
> > page boundaries. You get 910 instructions per page losing out on 1 byte but not
> > having a myriad of "other problems".
> I know that some machines were designed so as to take care to handle all the
> problems that might arise. Thus, the IBM System/360 had instructions that were
> 16, 32, and 48 bits long - and page boundaries were essentially invisible to the
> programmer.
>
> Of course, it wasn't until the Model 85 that cache memory was introduced to
> the line - and this was what forced IBM, in order to maintain compatibility, to
> do whatever it took to ensure that if there was a page fault in the middle of
> fetching an instruction... it was handled correctly.
>
> John Savard
Assuming the cache line size is at least 32B, there is another option. A 256-bit block can
hold 1 "virtual" I0 instruction (NOP of various flavors) and 7 full 36-bit I{1..7} instructions:
<code>
0 N0 3 4 N1 7 8 N2 11 12 N3 15 16 N4 19 20 N5 23 24 N6 27 28 N7 31
┌────────┬────────┬────────┬────────┬────────┬────────┬────────┬────────┐
│ I0 │ I1.H │ I2.H │ I3.H │ I4.H │ I5.H │ I6.H │ I7.H │ W0
├────────┴────────┴────────┴────────┴────────┴────────┴────────┴────────┤
│ I1.Low │ W1
├───────────────────────────────────────────────────────────────────────┤
│ I2.Low │ W2
├───────────────────────────────────────────────────────────────────────┤
│ I3.Low │ W3
├───────────────────────────────────────────────────────────────────────┤
│ I4.Low │ W4
├───────────────────────────────────────────────────────────────────────┤
│ I5.Low │ W5
├───────────────────────────────────────────────────────────────────────┤
│ I6.Low │ W6
├───────────────────────────────────────────────────────────────────────┤
│ I7.Low │ W7
└───────────────────────────────────────────────────────────────────────┘
</code>
I0 can be used as a crude form of 'flow control'. Thus, all CALL instructions must lead to
a 32B block starting with NOP(CALL ENTRY POINT).
I{1..7}.H can be used for instruction classification, e.g. all instructions requiring a 32/64/128b immediate value
can have their own class. The field normally encoding the register field (at the fixed position) can then contain
the information how long such value is. This makes parallel decoding of the whole block much easier.
For example, a 36b direct operand can be interpreted as 4b of metadata -
(uint/int/decimal/float/something completely different™..) and 32b of data.

Instructions are allowed to be aligned on 0.5 byte addresses, so that pages of memory can be loaded with instructions aligned to the page address. It is easy to use half-byte addressing as a base. I am leaning towards converting branch displacements back to half-byte displacements. The field is 12-bit which IIRC is enough to cover about 99% of branch according to H&P. Using a half-byte displacement means the hardware does not need to multiply the displacement by nine for a branch instruction. It also makes it easy for conditional branching across a page boundary. I am toying with the idea of supporting compressed instructions which would likely be 20 bits or less in size. Half-byte displacement may be needed in the long run.

Putting seven instructions in a block is a good number. Processing instructions in blocks with meta-data has its own challenges. ANY1 uses a 512-bit (64 byte) cache line with a 36-bit overflow area. The overflow area allows an instruction spanning cache lines to be entirely on the line. The fetch unit is then always able to read a whole instruction in a single cycle even when the instruction spans a cache line. It does cause some data replication in the cache though.
I have had a call target (TGT) instructions in a couple of ISA’s where the next instruction executed after a call had to be the TGT instruction or an exception would occur.

On Monday, June 21, 2021 at 5:26:02 PM UTC-5, robf...@gmail.com wrote:
> Instructions are allowed to be aligned on 0.5 byte addresses, so that pages of memory can be loaded with instructions aligned to the page address. It is easy to use half-byte addressing as a base. I am leaning towards converting branch displacements back to half-byte displacements.
<
This makes no sense, you lose a lot by doing this. The branch displacement should be in instructions.
So your typical RISC machine the 16-bit branch displacement gets shifted up by 2 bits making it effectively a 18-bit (signed) displacement.
<
In your case, the displacement gets added to the current nibble address IP as ::
newIP = oldIP + displacement<<3+displacement.
<
< The field is 12-bit which IIRC is enough to cover about 99% of branch according to H&P.
<
My way the field is equivalent to 15.25 bits (but I still think you should figure out how to get
16-bits in the field and 19.25 equivalent bytes out of it.)
<
>Using a half-byte displacement means the hardware does not need to multiply the displacement by nine for a branch instruction.
<
3-input adders solve this problem.
<
>It also makes it easy for conditional branching across a page boundary.
<
end around carry from bit 11 back to bit 0 realigns your instructions to page aligned at page boundaries.
<
>I am toying with the idea of supporting compressed instructions which would likely be 20 bits or less in size. Half-byte displacement may be needed in the long run.
>
> Putting seven instructions in a block is a good number. Processing instructions in blocks with meta-data has its own challenges. ANY1 uses a 512-bit (64 byte) cache line with a 36-bit overflow area. The overflow area allows an instruction spanning cache lines to be entirely on the line. The fetch unit is then always able to read a whole instruction in a single cycle even when the instruction spans a cache line. It does cause some data replication in the cache though.
> I have had a call target (TGT) instructions in a couple of ISA’s where the next instruction executed after a call had to be the TGT instruction or an exception would occur.

On Monday, June 21, 2021 at 7:09:43 PM UTC-4, MitchAlsup wrote:
> On Monday, June 21, 2021 at 5:26:02 PM UTC-5, robf...@gmail.com wrote:
> > Instructions are allowed to be aligned on 0.5 byte addresses, so that pages of memory can be loaded with instructions aligned to the page address. It is easy to use half-byte addressing as a base. I am leaning towards converting branch displacements back to half-byte displacements.
> <
> This makes no sense, you lose a lot by doing this. The branch displacement should be in instructions.
> So your typical RISC machine the 16-bit branch displacement gets shifted up by 2 bits making it effectively a 18-bit (signed) displacement.
> <
> In your case, the displacement gets added to the current nibble address IP as ::
> newIP = oldIP + displacement<<3+displacement.
> <
> < The field is 12-bit which IIRC is enough to cover about 99% of branch according to H&P.
> <
> My way the field is equivalent to 15.25 bits (but I still think you should figure out how to get
> 16-bits in the field and 19.25 equivalent bytes out of it.)
> <
> >Using a half-byte displacement means the hardware does not need to multiply the displacement by nine for a branch instruction.
> <
> 3-input adders solve this problem.
> <
> >It also makes it easy for conditional branching across a page boundary.
> <
> end around carry from bit 11 back to bit 0 realigns your instructions to page aligned at page boundaries.
> <
> >I am toying with the idea of supporting compressed instructions which would likely be 20 bits or less in size. Half-byte displacement may be needed in the long run.
> >
> > Putting seven instructions in a block is a good number. Processing instructions in blocks with meta-data has its own challenges. ANY1 uses a 512-bit (64 byte) cache line with a 36-bit overflow area. The overflow area allows an instruction spanning cache lines to be entirely on the line. The fetch unit is then always able to read a whole instruction in a single cycle even when the instruction spans a cache line. It does cause some data replication in the cache though.
> > I have had a call target (TGT) instructions in a couple of ISA’s where the next instruction executed after a call had to be the TGT instruction or an exception would occur.

The branch instruction format looks like:
Disp7|Tb2|Rb5|Ta2| Ra5| Ty2 | Disp5|v|opcode7

I can get one more bit of space in the instruction by restricting the Ra register field so that it must be a register. Reduces Ta2 to Ta1. Initially I had all the register specs the symmetrically the same, using two bits to indicate vector vs scalar vs constant. I can get one more bit by using more opcodes to represent branches for different data types. Currently there is a two-bit field “Ty2” in the branch instruction for the data type to compare. (int, float, decimal float, or posit). I could move one bit to the seven-bit opcode part. That gives 14-bits for a branch displacement. Not ideal but maybe good-enough, gives the equivalent of about 17 bits of displacement in terms of bytes. I suppose one more bit could be gotten by having only integer compare and branch. Branches for other types of data would need to use a set or compare instruction.

New format would look like:
Disp8|Tb2|Rb5|Ta1| Ra5|Ty1| Disp6|v1|opcode7

An alternative would be to go to a wider 38-bit instruction format.

I seem to have gotten the idea that for software portability reasons it might be a good idea to have the branch range at least 18 bits in terms of bytes.

On Monday, June 21, 2021 at 8:03:17 AM UTC-6, Theo wrote:
> You
> could maybe work out if an address was divisible by 9 to determine if it's
> the start of a pair or not, and if not assume the instruction is the second
> of a pair. Not impossible but it's rather unwieldy to do that.

I was thinking in terms of having instructions be addressed by an address
that indicates which 36-bit word in memory is desired. That address then
gets multiplied by nine and divided by two to figure out where that word
would be located in "real" memory.
The remainder, that last bit shifted out to the right, tells you if you have
an odd nybble to worry about.
Of course, the trouble is that if your data items are still 8, 16, 32, and 64
bits long, it's harder to tell, if programs and data are in the same address
space, where they bump into each other - while writing programs, because
you're using a different kind of address to refer to code.

John Savard

Theo wrote:
> Quadibloc <jsavard@ecn.ab.ca> wrote:
>> On Saturday, June 19, 2021 at 3:30:55 AM UTC-6, Theo wrote:
>>
>>> You would probably have to force alignment, effectively making instruction
>>> words 72 bits and packing two instructions per word. That means you could
>>> only branch into the first instruction of a word and might mean you'd have
>>> to pad with NOPs in some circumstances. That would probably be doable
>>> though, and the tradeoff might be worth it.
>>
>> I can see that alignment to byte boundaries is important, but why that would
>> prevent branching to the second instruction is unclear.
>>
>> How to tell, when branching to a byte, if it is the first or second instruction in
>> 72 bits that starts there? Also align to multiples of nine bytes, not just to the
>> byte, even though that is not a physical memory issue.
>
> I'm not sure I quite follow. Given instructions are aligned on 4.5 byte
> addresses, then instruction pairs are aligned on 9 byte boundaries. You
> could maybe work out if an address was divisible by 9 to determine if it's
> the start of a pair or not, and if not assume the instruction is the second
> of a pair. Not impossible but it's rather unwieldy to do that. You can do
> it in hardware for the instruction fetch but there are times when software
> needs to know too - maybe you would need a special instruction to do 'mod 9'
> efficiently.
>
> Another way around it would be to have a variation of a branch instruction
> that says 'branch to the second of the pair'. But that wouldn't play nicely
> with indirect branches where you only have the new PC and no information
> which half it's going to.
>
> I think you could probably make it work, although I think there's still risk
> of confusing instruction halves, and it would be nice to avoid any
> ambiguity.

It seems pretty obvious that any non-byte-aligned instruction set would
need to do all code addressing in instruction chunk size. (Even a
34/36-bit instruction set could have combined 68/72-bit opcodes to allow
large immediates etc.)

This way all branches and absolute addresses are in chunk units, only a
compiler/JIT would ever need to convert this to byte offsets, at which
point a compiler intrinsic/inline library function to do the conversions
would make sense.

Terje

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

On Tuesday, June 22, 2021 at 4:59:39 AM UTC-4, Terje Mathisen wrote:
> Theo wrote:
> > Quadibloc <jsa...@ecn.ab.ca> wrote:
> >> On Saturday, June 19, 2021 at 3:30:55 AM UTC-6, Theo wrote:
> >>
> >>> You would probably have to force alignment, effectively making instruction
> >>> words 72 bits and packing two instructions per word. That means you could
> >>> only branch into the first instruction of a word and might mean you'd have
> >>> to pad with NOPs in some circumstances. That would probably be doable
> >>> though, and the tradeoff might be worth it.
> >>
> >> I can see that alignment to byte boundaries is important, but why that would
> >> prevent branching to the second instruction is unclear.
> >>
> >> How to tell, when branching to a byte, if it is the first or second instruction in
> >> 72 bits that starts there? Also align to multiples of nine bytes, not just to the
> >> byte, even though that is not a physical memory issue.
> >
> > I'm not sure I quite follow. Given instructions are aligned on 4.5 byte
> > addresses, then instruction pairs are aligned on 9 byte boundaries. You
> > could maybe work out if an address was divisible by 9 to determine if it's
> > the start of a pair or not, and if not assume the instruction is the second
> > of a pair. Not impossible but it's rather unwieldy to do that. You can do
> > it in hardware for the instruction fetch but there are times when software
> > needs to know too - maybe you would need a special instruction to do 'mod 9'
> > efficiently.
> >
> > Another way around it would be to have a variation of a branch instruction
> > that says 'branch to the second of the pair'. But that wouldn't play nicely
> > with indirect branches where you only have the new PC and no information
> > which half it's going to.
> >
> > I think you could probably make it work, although I think there's still risk
> > of confusing instruction halves, and it would be nice to avoid any
> > ambiguity.
> It seems pretty obvious that any non-byte-aligned instruction set would
> need to do all code addressing in instruction chunk size. (Even a
> 34/36-bit instruction set could have combined 68/72-bit opcodes to allow
> large immediates etc.)
>
> This way all branches and absolute addresses are in chunk units, only a
> compiler/JIT would ever need to convert this to byte offsets, at which
> point a compiler intrinsic/inline library function to do the conversions
> would make sense.
>
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

It may seem obvious to use chunk addressing, but it may be a lot easier to use a lowest-common denominator addressing even though it may not be as efficient. For 36 bits machine this is a nybble. For 34-bits a bit pair. At one point I made a 36-bit ISA machine with 18-bit compressed instructions that required bit-pair alignment.
Currently working on the assembler, to use chunk addressing with inline parameters they must be a multiple of a chunk size. This means counting the nybbles output and making sure it is a multiple of nine. Nonsense like this would not be necessary with LCD addressing.

On Thursday, June 17, 2021 at 3:10:20 AM UTC-6, Quadibloc wrote:
> On Thursday, June 17, 2021 at 1:21:51 AM UTC-6, robf...@gmail.com wrote:
> > 15 34-bit instructions fit into a 512-bit cache line nicely with only two unused bits.
> That makes sense, because 512 is equal to two plus 17 times 30. Or 34 times 15.

> In Concertina II, I've been working with 34-bit instructions myself, but since they're
> one of several alternatives within an elaborate header structure, based on blocks
> of 256 bits in length, it is less efficient. I do have one efficient choice where there are
> four unused bits, plus seven 36-bit instructions. Or fourteen 18-bit instructions.

I've streamlined the architecture down from five instruction sets to two, but I was
still dissatisfied.

Basically, there's one instruction set composed of 32-bit instructions and pairs of 16 bit
instructions only. To make that instruction set complete by my standards, all sorts of
restrictions on addressing modes and so on have been used to squeeze everything in.

The other instruction set works this way:

Every 16 bits left after the header has two bits associated with it, to specify 'immediately'
how it is to be decoded.

If those two bits are 00 or 01, the 16 bits are the first 16 bits of a 32-bit instruction.
If those two bits are 11, the 16 bits don't begin an instruction, so the decoder ignores them
until an instruction begun in a previous halfword calls for their decoding as part of that
instruction - if that happens.
If those two bits are 10, the instruction could be 16, 48, or 64 bits long - as determined by the
first few bits of the instruction.

The idea is that one goes _directly_ from these bits to decoding the instruction at the point
they refer to; there's no need to decode instructions one after the other.

To attain that goal, the coding is somewhat redundant.

I was dissatisfied because making the 32-bit instructions into 33-bit instructions got rid of
the _worst_ of the compromises made to squeeze them all in, but not all the compromises
that... of course could be avoided by going to a 48-bit instruction, but in many cases that would
be wasteful.

I considered a number of alternatives, and I finally came up with one I liked. The decoding is
a little more complicated, but it's still direct, and now the 32-bit instructions have become 34 bits.

Step 1: The pairs of bits that are 00 and 01 begin 32-bit instructions. The following pair of bits,
now known to be the second half of a 32-bit instruction, can be either 10 or 11, and the two pairs
of bits together indicate one of four sets of 32-bit instructions.

Step 2: Any remaining pairs of bits that are 10 or 11, which don't follow a pair of bits starting
with zero, are interpreted as before: 10 - an instruction begins here that is not 32 bits long,
11 - no instruction begins here.

John Savard

On Sunday, June 27, 2021 at 1:09:52 AM UTC-4, Quadibloc wrote:
> On Thursday, June 17, 2021 at 3:10:20 AM UTC-6, Quadibloc wrote:
> > On Thursday, June 17, 2021 at 1:21:51 AM UTC-6, robf...@gmail.com wrote:
> > > 15 34-bit instructions fit into a 512-bit cache line nicely with only two unused bits.
> > That makes sense, because 512 is equal to two plus 17 times 30. Or 34 times 15.
>
> > In Concertina II, I've been working with 34-bit instructions myself, but since they're
> > one of several alternatives within an elaborate header structure, based on blocks
> > of 256 bits in length, it is less efficient. I do have one efficient choice where there are
> > four unused bits, plus seven 36-bit instructions. Or fourteen 18-bit instructions.
>
> I've streamlined the architecture down from five instruction sets to two, but I was
> still dissatisfied.
>
> Basically, there's one instruction set composed of 32-bit instructions and pairs of 16 bit
> instructions only. To make that instruction set complete by my standards, all sorts of
> restrictions on addressing modes and so on have been used to squeeze everything in.
>
> The other instruction set works this way:
>
> Every 16 bits left after the header has two bits associated with it, to specify 'immediately'
> how it is to be decoded.
>
> If those two bits are 00 or 01, the 16 bits are the first 16 bits of a 32-bit instruction.
> If those two bits are 11, the 16 bits don't begin an instruction, so the decoder ignores them
> until an instruction begun in a previous halfword calls for their decoding as part of that
> instruction - if that happens.
> If those two bits are 10, the instruction could be 16, 48, or 64 bits long - as determined by the
> first few bits of the instruction.
>
> The idea is that one goes _directly_ from these bits to decoding the instruction at the point
> they refer to; there's no need to decode instructions one after the other..
>
> To attain that goal, the coding is somewhat redundant.
>
> I was dissatisfied because making the 32-bit instructions into 33-bit instructions got rid of
> the _worst_ of the compromises made to squeeze them all in, but not all the compromises
> that... of course could be avoided by going to a 48-bit instruction, but in many cases that would
> be wasteful.
>
> I considered a number of alternatives, and I finally came up with one I liked. The decoding is
> a little more complicated, but it's still direct, and now the 32-bit instructions have become 34 bits.
>
> Step 1: The pairs of bits that are 00 and 01 begin 32-bit instructions. The following pair of bits,
> now known to be the second half of a 32-bit instruction, can be either 10 or 11, and the two pairs
> of bits together indicate one of four sets of 32-bit instructions.
>
> Step 2: Any remaining pairs of bits that are 10 or 11, which don't follow a pair of bits starting
> with zero, are interpreted as before: 10 - an instruction begins here that is not 32 bits long,
> 11 - no instruction begins here.
>
> John Savard

I believe I understand the instruction layout. Is it using the block header to select the instruction set? I have shied away from using block headers because the software has to somehow come up with them. How does the linker / loader handle moving instructions around?

I settled on 512-bit cache line length as that is four 128-bit accesses to memory. The system memory controller acts on data in 128-bit strips. The more consecutive burst accesses that can be made, the more efficient they are.. Loading more strips would be even more efficient from a memory access point of view, but more than 512-bits seems excessive.

To support a variable length instruction set for the RTF64, the instructions are pre-decoded at cache load time. The cache load is from memory so there are lots of cycles available to do efficient decoding. All that is needed at that point is the length so only a length decoder is used. Decoders amount to a lookup-table as the length can be determined solely by looking at the first byte of the instruction. Instructions vary in length from one to eight bytes.
At every possible instruction boundary the length of the instruction that might be beginning at that location is calculated. The length information is stored in a cache line shadowing the regular instruction data. Whenever an instruction is fetched the length is immediately available with no decoding required. This makes it possible to find instructions with minimal delay.

I am a fan of the way RISC-V represents instruction lengths. I do not think it could be much more efficient. But I think for larger machines (64-bit+) I think the instruction really needs to be a little wider than 32—bits, 34 or 36 bits.

Robert Finch

On Sunday, June 27, 2021 at 12:29:30 AM UTC-6, robf...@gmail.com wrote:

> I believe I understand the instruction layout. Is it using the block header
> to select the instruction set? I have shied away from using block headers
> because the software has to somehow come up with them. How does
> the linker / loader handle moving instructions around?

Just as programs for the Itanium are built up from 128-bit blocks which
are treated as single instructions by the linker/loader, my Concertina II
architecture builds programs from 256-bit blocks.

The computer reads 256 bits of program code from memory, which
must be aligned on a 256-bit boundary.

Unless the first 32 bits of that block contains one of two special bit
patterns, the block would consist of eight 32-bit instructions. In this
default case, because all the instructions are the same length, the
computer can immediately start decoding each one of the instructions
in parallel.

But the instructions still have to be executed one after the other in order -
or at least it has to _look_ like that's what happened (no doubt you've
heard of out-of-order execution, reservation stations, rename registers,
the arcane tech used to achieve that).

But the block _can_ have a header. If it does, it's in an alternative format.

The alternative block formats serve a number of purposes.

The most basic purpose is to state that instead of seven instructions after
the header, there are only five or six or even less. This allows some register-to-register
operate instructions to replace one of their source register operands by a pointer
into that unused space.

As Mitch Alsup has noted, there's an advantage if programs use instructions in
"immediate mode" instead of fetching constant values from the data area of memory.
Memory fetches are expensive these days compared to CPU calculations; an
immediate value is within the instruction stream, which is being fetched in consecutive
locations - which are the easiest for today's DRAM chips to supply.

But I had a problem with putting immediate values in instructions in the ordinary way:
immediate values come in different lengths, and this would make decoding the length
of an instruction complicated. I took inspiration from a scheme called "heads-and-tails
encoding", but I modified it to use pointers, even though they would take up some extra
space, again so that every instruction could be fully decoded independently of every other
instruction in the same block, for greater speed.

That's what I started with. But having a block header let me do other things.

One other thing I was able to do was add VLIW features to the architecture.

Things like instruction predication - I included a set of flag bits in the architecture
that could be set up ahead of time, and then in a block format including predication,
some instructions could be specified as only to be executed if a certain flag was set
a certain way.

Or explicit indication of parallelism. After all the instructions in a block have been
decoded separately in parallel... do they have to be executed one after the other?
Or are some instructions independent of the other instructions before them in the
block, so they can be started right away?

The Itanium did this. So do DSP chips, and I've modelled my scheme more on how
DSP chips work than on the Itanium.

And another thing the block headers can let me do is use an alternate instruction
set. I wanted that option because the requirement for every instruction to be
exactly 32 bits long (actually, I also allowed pairs of 16-bit instructions in a 32-bit
instruction slot, even without a header) was restrictive. Some types of instruction I
wanted to make available needed at least 48 bits to be specified. And even just
fitting all the basic operations into 32 bit instructions - because of the addressing
modes I wanted, and because I wanted to use register banks of 32 registers instead
of just eight (so that there would be less need for out-of-order operation for the
processor to run efficiently) - was difficult. I had to restrict the addressing modes
available on some types of instructions.

So if a program only needs the 32-bit instructions for most of its length, then it
can mostly consist of blocks in the simplest posible format. Occasionally, it
can include blocks in other formats to use the additional instructions in the
alternate set.

Or a subroutine meant to be very efficient - on a minimal implementation without
the out-of-order feature - can be made up of blocks in one of the formats that use
DSP features. So the architecture is suited to implementation on small chips for
embedded use, or big chips for high-power processing - at least, that's my goal.

John Savard

On Sunday, June 27, 2021 at 12:09:52 AM UTC-5, Quadibloc wrote:
> On Thursday, June 17, 2021 at 3:10:20 AM UTC-6, Quadibloc wrote:
> > On Thursday, June 17, 2021 at 1:21:51 AM UTC-6, robf...@gmail.com wrote:
> > > 15 34-bit instructions fit into a 512-bit cache line nicely with only two unused bits.
> > That makes sense, because 512 is equal to two plus 17 times 30. Or 34 times 15.
>
> > In Concertina II, I've been working with 34-bit instructions myself, but since they're
> > one of several alternatives within an elaborate header structure, based on blocks
> > of 256 bits in length, it is less efficient. I do have one efficient choice where there are
> > four unused bits, plus seven 36-bit instructions. Or fourteen 18-bit instructions.
>
> I've streamlined the architecture down from five instruction sets to two, but I was
> still dissatisfied.
>
> Basically, there's one instruction set composed of 32-bit instructions and pairs of 16 bit
> instructions only. To make that instruction set complete by my standards, all sorts of
> restrictions on addressing modes and so on have been used to squeeze everything in.
>
> The other instruction set works this way:
>
> Every 16 bits left after the header has two bits associated with it, to specify 'immediately'
> how it is to be decoded.
>
> If those two bits are 00 or 01, the 16 bits are the first 16 bits of a 32-bit instruction.
> If those two bits are 11, the 16 bits don't begin an instruction, so the decoder ignores them
> until an instruction begun in a previous halfword calls for their decoding as part of that
> instruction - if that happens.
> If those two bits are 10, the instruction could be 16, 48, or 64 bits long - as determined by the
> first few bits of the instruction.
<
Once you added the 10 format, which requires you to look at more bits to determine instruction
length, you ended up at the same gate delay as My 66000 in determining the location of the
successive instruction.
<
And as we have seen, My 66000 can decode as many as 16 instruction lengths per cycle
and is more likely instruction buffer width bound than instruction length bound when decoding
into SuperScalarity.
>
> The idea is that one goes _directly_ from these bits to decoding the instruction at the point
> they refer to; there's no need to decode instructions one after the other.
<
This is what the PARSE stage of my pipelines do, identify the position and width of each instruction
and then route the required bits to the subsequent DECODE stage. But even here, with My 66000,
Once issue width gets in the range of 6-8 inst/cycle I flip over to a different encoding technique
where I cache instruction issues not a stream of instructions.
>
> To attain that goal, the coding is somewhat redundant.
>
> I was dissatisfied because making the 32-bit instructions into 33-bit instructions got rid of
> the _worst_ of the compromises made to squeeze them all in, but not all the compromises
> that... of course could be avoided by going to a 48-bit instruction, but in many cases that would
> be wasteful.
>
> I considered a number of alternatives, and I finally came up with one I liked. The decoding is
> a little more complicated, but it's still direct, and now the 32-bit instructions have become 34 bits.
>
> Step 1: The pairs of bits that are 00 and 01 begin 32-bit instructions. The following pair of bits,
> now known to be the second half of a 32-bit instruction, can be either 10 or 11, and the two pairs
> of bits together indicate one of four sets of 32-bit instructions.
>
> Step 2: Any remaining pairs of bits that are 10 or 11, which don't follow a pair of bits starting
> with zero, are interpreted as before: 10 - an instruction begins here that is not 32 bits long,
> 11 - no instruction begins here.
>
> John Savard

On Sunday, June 27, 2021 at 2:47:39 AM UTC-5, Quadibloc wrote:
> On Sunday, June 27, 2021 at 12:29:30 AM UTC-6, robf...@gmail.com wrote:
>
> > I believe I understand the instruction layout. Is it using the block header
> > to select the instruction set? I have shied away from using block headers
> > because the software has to somehow come up with them. How does
> > the linker / loader handle moving instructions around?
> Just as programs for the Itanium are built up from 128-bit blocks which
> are treated as single instructions by the linker/loader, my Concertina II
> architecture builds programs from 256-bit blocks.
>
> The computer reads 256 bits of program code from memory, which
> must be aligned on a 256-bit boundary.
>
> Unless the first 32 bits of that block contains one of two special bit
> patterns, the block would consist of eight 32-bit instructions. In this
> default case, because all the instructions are the same length, the
> computer can immediately start decoding each one of the instructions
> in parallel.
>
> But the instructions still have to be executed one after the other in order -
> or at least it has to _look_ like that's what happened (no doubt you've
> heard of out-of-order execution, reservation stations, rename registers,
> the arcane tech used to achieve that).
>
> But the block _can_ have a header. If it does, it's in an alternative format.
>
> The alternative block formats serve a number of purposes.
>
> The most basic purpose is to state that instead of seven instructions after
> the header, there are only five or six or even less. This allows some register-to-register
> operate instructions to replace one of their source register operands by a pointer
> into that unused space.
>
> As Mitch Alsup has noted, there's an advantage if programs use instructions in
> "immediate mode" instead of fetching constant values from the data area of memory.
<
Available earlier in the pipeline,
No pollution of the data cache,
No silly readable status in the MMU tables for fetch only data,
No wasting of registers to hold a constant,
.....
<
> Memory fetches are expensive these days compared to CPU calculations; an
> immediate value is within the instruction stream, which is being fetched in consecutive
> locations - which are the easiest for today's DRAM chips to supply.
<
The I cache is faster than the D cache because the D cache will invariably have a
load aligner whereas everything coming out of the I cache has word alignment.
<
>
> But I had a problem with putting immediate values in instructions in the ordinary way:
> immediate values come in different lengths, and this would make decoding the length
> of an instruction complicated.
>
As I just showed above, yours is already as hard (in delay) to decode as My 66000
in the case where the 2 leading bits are 10.
>
> I took inspiration from a scheme called "heads-and-tails
> encoding", but I modified it to use pointers, even though they would take up some extra
> space, again so that every instruction could be fully decoded independently of every other
> instruction in the same block, for greater speed.
>
> That's what I started with. But having a block header let me do other things.
>
> One other thing I was able to do was add VLIW features to the architecture.
>
> Things like instruction predication - I included a set of flag bits in the architecture
> that could be set up ahead of time, and then in a block format including predication,
> some instructions could be specified as only to be executed if a certain flag was set
> a certain way.
>
> Or explicit indication of parallelism. After all the instructions in a block have been
> decoded separately in parallel... do they have to be executed one after the other?
> Or are some instructions independent of the other instructions before them in the
> block, so they can be started right away?
>
> The Itanium did this. So do DSP chips, and I've modelled my scheme more on how
> DSP chips work than on the Itanium.
>
> And another thing the block headers can let me do is use an alternate instruction
> set. I wanted that option because the requirement for every instruction to be
> exactly 32 bits long (actually, I also allowed pairs of 16-bit instructions in a 32-bit
> instruction slot, even without a header) was restrictive. Some types of instruction I
> wanted to make available needed at least 48 bits to be specified. And even just
> fitting all the basic operations into 32 bit instructions - because of the addressing
> modes I wanted, and because I wanted to use register banks of 32 registers instead
> of just eight (so that there would be less need for out-of-order operation for the
> processor to run efficiently) - was difficult. I had to restrict the addressing modes
> available on some types of instructions.
>
> So if a program only needs the 32-bit instructions for most of its length, then it
> can mostly consist of blocks in the simplest posible format. Occasionally, it
> can include blocks in other formats to use the additional instructions in the
> alternate set.
>
> Or a subroutine meant to be very efficient - on a minimal implementation without
> the out-of-order feature - can be made up of blocks in one of the formats that use
> DSP features. So the architecture is suited to implementation on small chips for
> embedded use, or big chips for high-power processing - at least, that's my goal.
>
> John Savard

On Sunday, June 27, 2021 at 10:51:47 AM UTC-6, MitchAlsup wrote:

> Once you added the 10 format, which requires you to look at more bits to determine instruction
> length, you ended up at the same gate delay as My 66000 in determining the location of the
> successive instruction.

Ah, but you were able to decode My 66000 that quickly because you are an expert logic designer,
whereas my format is intended to be decoded quickly even if the logic to decode it is designed
by duffers like myself!

Also, remember that I'm not just thinking of the time to decode the length of _one instruction_;
I'm trying to decode all the instructions in a 256-bit block *in parallel*, where decoding takes
place locally, without any need to worry about the lengths of preceding instructions. Are you
sure you've taken _that_ into consideration?

In any case, though, my joy at finding so much more opcode space has now been dampened.

My goal was, with such a vast amount of opcode space for "32-bit" instructions, to remove all
the silly addressing mode restrictions from them, so as to return to the simplicity of such
architectures as the IBM System/360.

However, if I'm going to include memory-to-register operate instructions without any address
mode restrictions, but just for the basic operations... even without a C bit (oops!) I need three
of the four 32-bit opcode spaces I've made available for myself. The fourth one isn't quite
enough to handle removing address mode restrictions for everything else.

I have come up with ideas to increase the amount of opcode space available from four
opcode spaces to five and one-quarter opcode spaces, but they're ugly. The other alternative
is to accept a restriction to aligned operands for the memory-to-register operate instructions
only, which is not unreasonable.

So I still am not satisfied. That, of course, is my own fault, for being so unreasonable and
greedy. Ah well, I can always make another visit to the drawing board, and perhaps come up
with something that I will be content to accept.

John Savard

On Sunday, June 27, 2021 at 2:39:52 PM UTC-5, Quadibloc wrote:
> On Sunday, June 27, 2021 at 10:51:47 AM UTC-6, MitchAlsup wrote:
>
> > Once you added the 10 format, which requires you to look at more bits to determine instruction
> > length, you ended up at the same gate delay as My 66000 in determining the location of the
> > successive instruction.
> Ah, but you were able to decode My 66000 that quickly because you are an expert logic designer,
> whereas my format is intended to be decoded quickly even if the logic to decode it is designed
> by duffers like myself!
<
I fretted long and hard about coming up with a code before getting that part of the decode process
enumerated. Logic drove the encoding--which is why is can be so expressive and (delay) efficient.
>
> Also, remember that I'm not just thinking of the time to decode the length of _one instruction_;
> I'm trying to decode all the instructions in a 256-bit block *in parallel*, where decoding takes
> place locally, without any need to worry about the lengths of preceding instructions. Are you
> sure you've taken _that_ into consideration?
<
Yes,
<
As I have enumerated several times, I am targeting a range of implementations from the
small (MIPS R-2000 level) up to the large (bigger than 8-instruction per cycle Out of Order).
But having done a 6-wide GBOoO I am aware of instruction caching techniques that solve
not just the decode problem, but the enumerated register data flow problem, too.
>
> In any case, though, my joy at finding so much more opcode space has now been dampened.
<
And yet MY 66000 has only grown from 59 instruction to 61 because I made a power×efficiency
argument on ABS and CopySign. Routing in {0, or S2<63>} for S1<63> is more power efficient
than a compare instruction, in addition, I can conceive of implementations where this takes
zero cycles of execution (it is done in the forwarding path.)
>
> My goal was, with such a vast amount of opcode space for "32-bit" instructions, to remove all
> the silly addressing mode restrictions from them, so as to return to the simplicity of such
> architectures as the IBM System/360.
<
Which I continue to think of as misguided (if not an outright mistake); but I am willing to watch
your gyrations to see if you are closing in, or just appearing to make forward progress.
>
> However, if I'm going to include memory-to-register operate instructions without any address
> mode restrictions, but just for the basic operations... even without a C bit (oops!) I need three
> of the four 32-bit opcode spaces I've made available for myself. The fourth one isn't quite
> enough to handle removing address mode restrictions for everything else.
<
I have roughly 23 out of 64 Major OpCodes reserved for the future and another 6 reserved in
perpetuity for protection against executing data. I have more than ½ of my memory OpCOde
space reserved for the future, more than ½ my 2-operand space reserved for the future, 3 of 8
of my 3-operand space reserved for the future, and 96% of my 1-operand space so reserved.
>
> I have come up with ideas to increase the amount of opcode space available from four
> opcode spaces to five and one-quarter opcode spaces, but they're ugly. The other alternative
> is to accept a restriction to aligned operands for the memory-to-register operate instructions
> only, which is not unreasonable.
<
This is the gyrations I was mentioning above.
>
> So I still am not satisfied. That, of course, is my own fault, for being so unreasonable and
> greedy. Ah well, I can always make another visit to the drawing board, and perhaps come up
> with something that I will be content to accept.
<
I did similarly over my 38 year career, and then I saw the light and got rid of the things in my
way and distilled it down to the necessities in an elegant and efficient encoding. Perhaps you
will eventually arrive at your destination.
>
> John Savard

On Sunday, June 27, 2021 at 1:39:52 PM UTC-6, Quadibloc wr
> However, if I'm going to include memory-to-register operate instructions without any address
> mode restrictions, but just for the basic operations... even without a C bit (oops!) I need three
> of the four 32-bit opcode spaces I've made available for myself.

As that meant I would have to accept restricting those instructions to aligned operands,
I decided it was possible to go ahead. Also removing address mode restrictions from the
load/store instructions for the enlarged sets of 128 registers meant I still did have to use
the technique to expand the opcode space to five 32-bit opcode spaces, but at least now
I have the result that:

- everything fits that I intended to put in;
- the "extended mode" set now contrasts with the plain 32-bit instruction set, by
providing a significantly expanded instruction code repertoire in return for its
overhead costs, thus justifying its existence better;
- the coding for the prefix bits is more efficient - there are still only two of them
per each 16 bits of code, but now they provide more information - and yet they're
still decoded in a local and parallel manner.

None the less, the criticism that my ISA is overly complicated...

is one the validity of which is obvious even to me. If I manage to think of a simpler
way to achieve my goals to an extent that satisfies me, that will be wonderful. Although
I suspect that it is my goals that are badly flawed in that they can't really be achieved in
a reasonable manner.

John Savard

In article <8439317b-cf4e-4b07-b461-d7e23da9d31fn@googlegroups.com>,
robf...@gmail.com <robfi680@gmail.com> wrote:
>Instructions are allowed to be aligned on 0.5 byte addresses, so that
>pages of memory can be loaded with instructions aligned to the page
>address. It is easy to use half-byte addressing as a base. I am leaning
>towards converting branch displacements back to half-byte displacements.
>The field is 12-bit which IIRC is enough to cover about 99% of branch
>according to H&P. Using a half-byte displacement means the hardware does
>not need to multiply the displacement by nine for a branch instruction.
>It also makes it easy for conditional branching across a page boundary.
>I am toying with the idea of supporting compressed instructions which
>would likely be 20 bits or less in size. Half-byte displacement may be
>needed in the long run.

IA64 showed that they could put 3 instructions in 128 bits and have this
not be a problem. It basically treated instruction pointers [63:4] pointing
to a 128-bit block, and [3:2] pointing to the instruction offset, where
only the values 0, 1, 2 are valid.

For you to pack 15 34-bit instructions in 512 (64 bytes) bits, the PC would
be:

[63:6]: Addr[63:6] to point to this 64-byte block
[5:2]: Instr offset, in the range 0...0xe. 0xf (1111) is an illegal value
[1:0]: 00

So, PC = 0x1234 would point to the 64-byte block at 0x1200, and would
point to instruction 0xd displacement, which is +13*34 bits into that block.

PC would increment by 4 generally for each instruction executed, but if
[5:2] would equal '1111', it instead wraps up the next block.

The overall cost of this in hardware is almost 0, in terms of logic, and
in terms of speed. The cost to software is very nearly 0, but the
assembler/linker need changes (but if they already support IA64, the
changes are easy).

This idea can support any number of weird instructions in any size block. I
think 512 bits is a large chunk size, and you're better off fitting into
256-bits, merely because it's likely the linker will require all functions to
start at a chunk size (otherwise, the final link would be very annoying).
Spending all this effort to squeeze instructions to this weird size could be
wasted by the alignment issues--the last chunk of a function would likely be
just 1/2 full on average, wasting 256 bits for every function. This adds up
if there are a lot of small methods. It's very possible 36 bit instructions
fitting in 256 bits would actually result in less code bytes (since now
you're wasting on everage 128 bits per method, and not 256-bits), and even
more likely if you can use the extra instruction bits to sometimes save an
instruction.

The instructions don't even all have to be the same size, or have a simple
offset formula--IA64 places an encoding template in the 128-bit chunk, but
this isn't a good use of those bits. You have 2 bits left over (34*15=510
bits), you can make that a runt first instruction, where an encoding could be:

00: NOP, almost always used when not the first chunk of a function
01: BIG_ENTER: save all callee-saves registers, FP=SP, whatever else you want.
10: SMALL_ENTER: save half of the callee-saves registers
11: SP=SP-256; FP=SP. Simple function entry, creates small frame

Another idea is a sort-of-delayed branch:
11: RET at end of this chunk

This is sort of like a delayed branch, but it really isn't. This would
be useful in every function (in the last chunk), and it saves one RET
instruction per function. This saves one full chunk 1/15th of the time (when
the final RET would be in a new chunk all by itself). To use the runt
instruction, now PC[5:2] can take on all values, where the 0000 encoding
points to the runt instruction.

Kent

>IA64 showed that they could put 3 instructions in 128 bits and have this
>not be a problem. It basically treated instruction pointers [63:4] pointing
>to a 128-bit block, and [3:2] pointing to the instruction offset, where
>only the values 0, 1, 2 are valid.

>The overall cost of this in hardware is almost 0, in terms of logic, and
>in terms of speed. The cost to software is very nearly 0, but the
>assembler/linker need changes (but if they already support IA64, the
>changes are easy).

I agree that it is not that difficult a hardware issue to have odd sized instructions. I am surprised that there are not more designs with differing instruction sizes. Getting the software working with odd sized instructions is a bit more challenging.

>This idea can support any number of weird instructions in any size block. I
>think 512 bits is a large chunk size, and you're better off fitting into
>256-bits, merely because it's likely the linker will require all functions to
>start at a chunk size (otherwise, the final link would be very annoying).

I had not thought a lot about the linker. But at the moment instructions can be aligned on any nybble boundary. I find nybble addressing a simpler approach than packing instructions into chunks. So, the start of a function could be aligned on a 256-bit or even a 128-bit boundary. I guess it depends on what works the best for the linker. With nybble addressing the linker can choose the chunk size. I suppose it could be stipulated that all functions must be at least 16-byte aligned or more. That way the least significant five bits of a nybble address are always zero. Meaning the branch and jump instructions can omit them.

>00: NOP, almost always used when not the first chunk of a function
>01: BIG_ENTER: save all callee-saves registers, FP=SP, whatever else you want.
>10: SMALL_ENTER: save half of the callee-saves registers
>11: SP=SP-256; FP=SP. Simple function entry, creates small frame

>Another idea is a sort-of-delayed branch:
>11: RET at end of this chunk

Reminds me to look more into ENTER and LEAVE instructions. I have been doing some thought as to how to get multiple registers saved and restored.

Using a block header would make the instruction aligner a tiny bit more complex. It would have to start the realignment after the block header, instead of simply starting at the first bit.

On Wednesday, June 30, 2021 at 11:27:48 PM UTC-6, robf...@gmail.com wrote:

> I agree that it is not that difficult a hardware issue to have odd sized instructions.
> I am surprised that there are not more designs with differing instruction sizes.

I'm not. After all, an odd size for instructions is an additional bit of complexity,
so that's a cost that normally would not be accepted without a good reason.
Companies selling processors commercially want to be taken seriously, and so
they would be at pains to avoid anything that might seem like a needless eccentricity
in their designs.

John Savard

On 2021-07-01, robf...@gmail.com wrote:
>> IA64 showed that they could put 3 instructions in 128 bits and have this
>> not be a problem. It basically treated instruction pointers [63:4] pointing
>> to a 128-bit block, and [3:2] pointing to the instruction offset, where
>> only the values 0, 1, 2 are valid.
>
>> The overall cost of this in hardware is almost 0, in terms of logic, and
>> in terms of speed. The cost to software is very nearly 0, but the
>> assembler/linker need changes (but if they already support IA64, the
>> changes are easy).
>
> I agree that it is not that difficult a hardware issue to have odd sized instructions. I am surprised that there are not more designs with differing instruction sizes. Getting the software working with odd sized instructions is a bit more challenging.
>
>> This idea can support any number of weird instructions in any size block. I
>> think 512 bits is a large chunk size, and you're better off fitting into
>> 256-bits, merely because it's likely the linker will require all functions to
>> start at a chunk size (otherwise, the final link would be very annoying).
>
> I had not thought a lot about the linker. But at the moment instructions can be aligned on any nybble boundary. I find nybble addressing a simpler approach than packing instructions into chunks. So, the start of a function could be aligned on a 256-bit or even a 128-bit boundary. I guess it depends on what works the best for the linker. With nybble addressing the linker can choose the chunk size. I suppose it could be stipulated that all functions must be at least 16-byte aligned or more. That way the least significant five bits of a nybble address are always zero. Meaning the branch and jump instructions can omit them.
>

If you want allow the linker to do any kind of relaxations (transform
machine code for the benefit of reduced code size and/or improved
performance once final addresses and branch distances etc are known),
things could get quite messy with a block based odd sized instruction
encoding scheme like this.

>> 00: NOP, almost always used when not the first chunk of a function
>> 01: BIG_ENTER: save all callee-saves registers, FP=SP, whatever else you want.
>> 10: SMALL_ENTER: save half of the callee-saves registers
>> 11: SP=SP-256; FP=SP. Simple function entry, creates small frame
>
>> Another idea is a sort-of-delayed branch:
>> 11: RET at end of this chunk
>
> Reminds me to look more into ENTER and LEAVE instructions. I have been doing some thought as to how to get multiple registers saved and restored.
>
> Using a block header would make the instruction aligner a tiny bit more complex. It would have to start the realignment after the block header, instead of simply starting at the first bit.
>

On Thursday, July 1, 2021 at 12:27:48 AM UTC-5, robf...@gmail.com wrote:
> >IA64 showed that they could put 3 instructions in 128 bits and have this
> >not be a problem. It basically treated instruction pointers [63:4] pointing
> >to a 128-bit block, and [3:2] pointing to the instruction offset, where
> >only the values 0, 1, 2 are valid.
> >The overall cost of this in hardware is almost 0, in terms of logic, and
> >in terms of speed. The cost to software is very nearly 0, but the
> >assembler/linker need changes (but if they already support IA64, the
> >changes are easy).
> I agree that it is not that difficult a hardware issue to have odd sized instructions.
<
<
>I am surprised that there are not more designs with differing instruction sizes. Getting the software working with odd sized instructions is a bit more challenging.
<
I would have been surprised, except I invented instruction-modifiers which
allowed me to effectively move the extra bits from the instruction itself
to the modifier so the very vast majority of instruction do not need modification.
<
> >This idea can support any number of weird instructions in any size block.. I
> >think 512 bits is a large chunk size, and you're better off fitting into
> >256-bits, merely because it's likely the linker will require all functions to
> >start at a chunk size (otherwise, the final link would be very annoying)..
> I had not thought a lot about the linker. But at the moment instructions can be aligned on any nybble boundary. I find nybble addressing a simpler approach than packing instructions into chunks. So, the start of a function could be aligned on a 256-bit or even a 128-bit boundary. I guess it depends on what works the best for the linker. With nybble addressing the linker can choose the chunk size. I suppose it could be stipulated that all functions must be at least 16-byte aligned or more. That way the least significant five bits of a nybble address are always zero. Meaning the branch and jump instructions can omit them.
> >00: NOP, almost always used when not the first chunk of a function
> >01: BIG_ENTER: save all callee-saves registers, FP=SP, whatever else you want.
> >10: SMALL_ENTER: save half of the callee-saves registers
> >11: SP=SP-256; FP=SP. Simple function entry, creates small frame
>
> >Another idea is a sort-of-delayed branch:
> >11: RET at end of this chunk
> Reminds me to look more into ENTER and LEAVE instructions. I have been doing some thought as to how to get multiple registers saved and restored.
>
> Using a block header would make the instruction aligner a tiny bit more complex. It would have to start the realignment after the block header, instead of simply starting at the first bit.

On Thursday, July 1, 2021 at 12:25:57 PM UTC-6, MitchAlsup wrote:

> I would have been surprised, except I invented instruction-modifiers which
> allowed me to effectively move the extra bits from the instruction itself
> to the modifier so the very vast majority of instruction do not need modification.

Isn't the VAX-11/780 prior art on that one?

John Savard

On Thursday, July 1, 2021 at 1:37:35 PM UTC-5, Quadibloc wrote:
> On Thursday, July 1, 2021 at 12:25:57 PM UTC-6, MitchAlsup wrote:
>
> > I would have been surprised, except I invented instruction-modifiers which
> > allowed me to effectively move the extra bits from the instruction itself
> > to the modifier so the very vast majority of instruction do not need modification.
> Isn't the VAX-11/780 prior art on that one?
<
In what way ? If I understand VAX correctly, they had instruction modifiers within
an instruction (called address modes) whereas this is between instructions.
>
> John Savard

On Thursday, July 1, 2021 at 2:40:44 PM UTC-4, MitchAlsup wrote:
> On Thursday, July 1, 2021 at 1:37:35 PM UTC-5, Quadibloc wrote:
> > On Thursday, July 1, 2021 at 12:25:57 PM UTC-6, MitchAlsup wrote:
> >
> > > I would have been surprised, except I invented instruction-modifiers which
> > > allowed me to effectively move the extra bits from the instruction itself
> > > to the modifier so the very vast majority of instruction do not need modification.
> > Isn't the VAX-11/780 prior art on that one?
> <
> In what way ? If I understand VAX correctly, they had instruction modifiers within
> an instruction (called address modes) whereas this is between instructions.
> >
> > John Savard

What is the difference between instruction modifiers and instruction prefixes such as on the x86 and other machines ?

On Friday, July 2, 2021 at 5:55:49 AM UTC-5, robf...@gmail.com wrote:
> On Thursday, July 1, 2021 at 2:40:44 PM UTC-4, MitchAlsup wrote:
> > On Thursday, July 1, 2021 at 1:37:35 PM UTC-5, Quadibloc wrote:
> > > On Thursday, July 1, 2021 at 12:25:57 PM UTC-6, MitchAlsup wrote:
> > >
> > > > I would have been surprised, except I invented instruction-modifiers which
> > > > allowed me to effectively move the extra bits from the instruction itself
> > > > to the modifier so the very vast majority of instruction do not need modification.
> > > Isn't the VAX-11/780 prior art on that one?
> > <
> > In what way ? If I understand VAX correctly, they had instruction modifiers within
> > an instruction (called address modes) whereas this is between instructions.
> > >
> > > John Savard
> What is the difference between instruction modifiers and instruction prefixes such as on the x86 and other machines ?
<
Instruction-modifiers (Note: Hyphen) can modify several succeeding instructions;
Prefixes are for the current instruction only.
<
A 128-bit shift (by less than 64-bits):
<
CARRY R14,{{I}{IO}{IO}{O}}
SL R11,R1,Rshift
SL R12,R2,Rshift
SL R13,R3,Rshift
SL R14,R4,Rshift
<