From Newsgroup: comp.arch

What can't I get?
You know darn well!

Oh, wait a moment, that's Oscar and Hammerstein, not the Rolling
Stones.

In any case... in looking into the possibility of abandoning block
structure for my new Concertina II+ ISA, I've thought of new ways to
squeeze things into the ISA.
And so I've come to some conclusions.
Basically, if I use the techniques I've found, and, in addition,
abandon the idea of having paired short instructions in plain
non-blocked code, I can have at least very limited versions of the
various types of instructions which previously had been placed in
"alternate" 32-bit instruction sets in the main 32-bit instruction
set.
This lets me get rid of the complexity of headers, letting me get by
with just three headers - one for variable-length instructions, one
for allowing pseudo-immediates iwith minimal overhead, and one for
VLIW features like explicit parallelism and predication.
The benefits of keeping block structure are:
- immediate values are contiguous, in the same form as values of the
same type in data;
- greater bit-efficiency of the code, with less overhead for
additional types of instruction (17-bit short instructions, 48-bit instructions, and so on).

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 11 Oct 2026 01:41:09 GMT, [email protected] (John Savard)
wrote:

What can't I get?
You know darn well!

Oh, wait a moment, that's Oscar and Hammerstein, not the Rolling
Stones.

The references, of course, are to "There is Nothing Like a Dame", from
South Pacific, and "I Can't Get No Satisfaction".

In any case, I have uploaded the first few pages of my latest
iteration of Concertina II, at

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

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


[email protected] (John Savard) posted:

What can't I get?
You know darn well!

Oh, wait a moment, that's Oscar and Hammerstein, not the Rolling
Stones.

In any case... in looking into the possibility of abandoning block
structure for my new Concertina II+ ISA, I've thought of new ways to
squeeze things into the ISA.
And so I've come to some conclusions.

Basically, if I use the techniques I've found, and, in addition,
abandon the idea of having paired short instructions in plain
non-blocked code, I can have at least very limited versions of the
various types of instructions which previously had been placed in
"alternate" 32-bit instruction sets in the main 32-bit instruction
set.

Have you measured the space saving of paired 16-bit instructions
versus not having any 16-bit instructions ?

This lets me get rid of the complexity of headers, letting me get by
with just three headers - one for variable-length instructions, one
for allowing pseudo-immediates iwith minimal overhead,

I get all of these without any headers.

and one for
VLIW features like explicit parallelism and predication.

In my opinion, one of the most valuable parallelism features is to be
able to write:

Simultaneous{ Mov R10,R20, Mov R20,R10 }

Which swaps the register values in 2 instructions rather than 3. In K9
we had a HW-peep-hole optimizer which found theses and we re-wrote the
register specifiers with an encoding which allowed the above.

The benefits of keeping block structure are:
- immediate values are contiguous, in the same form as values of the
same type in data;

I see no benefit, constants are constants, as long as you can parse the
VLE to find instruction boundaries and constants easily.

- greater bit-efficiency of the code,

Bit efficiency is worthless unless you end up executing fewer instructions
but retain the same semantic content.

with less overhead for
additional types of instruction (17-bit short instructions, 48-bit instructions, and so on).

Since I don't have these, I need not worry.

John Savard

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 11 Oct 2026 21:34:47 GMT, MitchAlsup
<[email protected]d> wrote:

In my opinion, one of the most valuable parallelism features is to be
able to write:

Simultaneous{ Mov R10,R20, Mov R20,R10 }

Which swaps the register values in 2 instructions rather than 3. In K9
we had a HW-peep-hole optimizer which found theses and we re-wrote the >register specifiers with an encoding which allowed the above.

I do have a swap instruction as one of my basic operate instructions.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 10/10/2026 6:41 PM, John Savard wrote:

What can't I get?
You know darn well!

Oh, wait a moment, that's Oscar and Hammerstein,

Rogers and Hammerstein. But Hammerstein's first name was Oscar. And if
you only refer to the lyrics, they are Hammersteins. Richard Rogers
wrote the music.
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 11 Oct 2026 18:06:51 -0700, Stephen Fuld
<[email protected]d> wrote:

Rogers and Hammerstein. But Hammerstein's first name was Oscar. And if
you only refer to the lyrics, they are Hammersteins. Richard Rogers
wrote the music.

You are absolutely right. It should have been Rogers and Hammerstein.
My memory is clearly not what it used to be.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 11 Oct 2026 19:37:53 GMT, [email protected] (John Savard)
wrote:

In any case, I have uploaded the first few pages of my latest
iteration of Concertina II, at

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

I have now made a bit further progress; I have now uploaded the
formats of instructions longer than 32 bits at

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

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 11 Oct 2026 21:34:47 GMT, MitchAlsup
<[email protected]d> wrote:

Have you measured the space saving of paired 16-bit instructions
versus not having any 16-bit instructions ?

No, I'm not even sure how to conduct a valid measurement of that type. Constructing a compiler for my ISA and then turning it loose on a
large corpus of FORTRAN would involve an immense amount of work.

If a program consists mostly of operate instructions, and only a small percentage of them need to be three-address, then having 16-bit
instructions would almost shrink the size of the program in half.

If the 16-bit instructions had to come in pairs, then half the time,
the last instruction in any run of operate instructions would have to
be expanded to 32 bits. So that would be a small loss of savings.

Does that mean I made a horribly disastrous choice, then, by getting
rid of the paired 16-bit short instructions? Hold on! I still have
short instructions. Instead of 15-bit ones in pairs, I have 17-bit
ones. So those don't have the restriction that both registers have to
be in the same group of eight registers - about which I recieved many complaints here.

They do come with 12.5% overhead (less the extra 17th bits in the
header) for the Type I header required to use them. But that
percentage is over all instructions in a block with such short
instructions, not just for the short instructions themselves.

So your question _seems_ to be only relevant to a case which does not
exist: the case where I got rid of short instructions entirely. When I
got rid of block structure, though, short instructions effectively
grew to 24 bits, so I did lose a big chunk of the space savings.

Yes, I _know_ _you_ don't need block structure for a lot of the things
I'm using it for. But I want to simplify instruction decoding even for implementors who may not be terribly clever. And I'm trying to cram an
awful lot of stuff into my ISA - particularly into the opcode space
for instructions that are 32 bits long; this goal also prevents me
from doing as well as you have done in these departments.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Mon, 12 Oct 2026 03:12:21 GMT, [email protected] (John Savard)
wrote:

On Sun, 11 Oct 2026 19:37:53 GMT, [email protected] (John Savard)
wrote:

In any case, I have uploaded the first few pages of my latest
iteration of Concertina II, at

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

I have now made a bit further progress; I have now uploaded the
formats of instructions longer than 32 bits at

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

I have also modified the page at

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

to correct my mistake in throwing away a significant amount of
available opcode space.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Mon, 12 Oct 2026 04:47:37 GMT, [email protected] (John Savard)
wrote:

I have also modified the page at

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

to correct my mistake in throwing away a significant amount of
available opcode space.

Since then, I found a couple of other minor changes to make - one
simply made it easier to explain the instructions in order, the other
left more freedom to allocate some remaining opcode space to either of
two different groups of instructions.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

In article <[email protected]>, [email protected] (John Savard) wrote:

On Sun, 11 Oct 2026 21:34:47 GMT, MitchAlsup <[email protected]d> wrote:

Have you measured the space saving of paired 16-bit instructions
versus not having any 16-bit instructions ?

No, I'm not even sure how to conduct a valid measurement of that
type. Constructing a compiler for my ISA and then turning it loose
on a large corpus of FORTRAN would involve an immense amount of work.

Hand-compiling code is easy enough, in small quantities. It will show you
some kinds of mistake, and writing a program that scans code and checks
that you've obeyed the various restrictions is also pretty simple.

John
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Now the page at

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

has been modified: I intended to place, among the 48-bit instructions,
all the things that didn't require an instruction much longer than 32
bits, but which wouldn't fit in the 32-bit opcode space.
However, I had been a bit too profligate in assigning 48-bit opcode
space to instruction types to do so; much was missing from the 48-bit instructions that needed to be there.
This has now been addressed.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Further tweaks have taken place on

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

Now, I have the same opcode length for supplemental load/store
instructions for the extended register banks of 128 registers as for
the regular register banks.
As well, I have added mixed-register two-operand operate instructions;
those for the regular registers, for the extended register banks, and
the mixed-register ones all have the same opcode length.
This ensures that the additional data types and additional operations
provided by the architecture will be equally available on both sets of registers.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Tue, 13 Oct 2026 13:12:06 GMT, [email protected] (John Savard)
wrote:

Further tweaks have taken place on

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

Now, I have the same opcode length for supplemental load/store
instructions for the extended register banks of 128 registers as for
the regular register banks.
As well, I have added mixed-register two-operand operate instructions;
those for the regular registers, for the extended register banks, and
the mixed-register ones all have the same opcode length.
This ensures that the additional data types and additional operations >provided by the architecture will be equally available on both sets of >registers.

After adding all these nice instructions to make better use of the
extended register banks of 128 registers, I realized that these
register banks were the most useful in code that makes use of VLIW
features. But only 32-bit instructions are available in blocks with
Type III headers which make those features available!

So, on
http://www.quadibloc.com/arch/ct26int.htm
I have now added the description of a means by which 48-bit or longer instructions (but not the 17-bit short instructions) may be executed
from within a block with a Type III header.
It's not particularly efficient - each such instruction wastes at
least 12 bits in the instruction stream - but I felt that this was
worth it to avoid the complexity of an additional type of header, and forgivable given the degree to which the rest of the ISA goes to great
lengths to achieve economy of code space.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


[email protected] (John Savard) posted:

On Sun, 11 Oct 2026 21:34:47 GMT, MitchAlsup <[email protected]d> wrote:

Have you measured the space saving of paired 16-bit instructions
versus not having any 16-bit instructions ?

No, I'm not even sure how to conduct a valid measurement of that type. Constructing a compiler for my ISA and then turning it loose on a
large corpus of FORTRAN would involve an immense amount of work.

If a program consists mostly of operate instructions, and only a small percentage of them need to be three-address, then having 16-bit
instructions would almost shrink the size of the program in half.

You can always have a 16-bit instruction after a 32-bit instruction.
You cannot have a 32-bit instruction after a 16-bit instruction (unless
your IP indexes memory on 16-bit boundaries. CDC 6600 did not. CDC 7600
did.

In my ASM reading of My 66000 compiled output, about 35% of instructions
could be 16-bits, with your constants, your compiled output could be similar since we get rid of instructions which paste constants, and both have index- ing. I saw this as getting rid of the "easy" 16-bit instructions; leaving opportunities. Also note, my LOOP instruction performs ADD-CMP-BC where
the ADD and CMP could be 16-bits--but I get all 3 in a single 32-bit instruction.

When I see:

MEM Rd,[IP,Rindex<<scale+DISP]

This gets rid of 2× 16-bit instructions all by itself; reducing opportunities.

If the 16-bit instructions had to come in pairs, then half the time,
the last instruction in any run of operate instructions would have to
be expanded to 32 bits. So that would be a small loss of savings.

I think reading real code you will find the lack-of-savings greater.

Does that mean I made a horribly disastrous choice, then, by getting
rid of the paired 16-bit short instructions? Hold on! I still have
short instructions. Instead of 15-bit ones in pairs, I have 17-bit
ones. So those don't have the restriction that both registers have to
be in the same group of eight registers - about which I recieved many complaints here.

They do come with 12.5% overhead (less the extra 17th bits in the
header) for the Type I header required to use them. But that
percentage is over all instructions in a block with such short
instructions, not just for the short instructions themselves.

So your question _seems_ to be only relevant to a case which does not
exist: the case where I got rid of short instructions entirely. When I
got rid of block structure, though, short instructions effectively
grew to 24 bits, so I did lose a big chunk of the space savings.

Yes, I _know_ _you_ don't need block structure for a lot of the things
I'm using it for. But I want to simplify instruction decoding even for implementors who may not be terribly clever.

It took me less time to not-need block structure than it did for you
to meander around to some-kind-of sensible block structure. This does
not bode well for implementation.

And I'm trying to cram an
awful lot of stuff into my ISA - particularly into the opcode space
for instructions that are 32 bits long; this goal also prevents me
from doing as well as you have done in these departments.

An ISA is just as much about what you leave out as to what you leave in.

John Savard

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Tue, 13 Oct 2026 21:24:56 GMT, MitchAlsup
<[email protected]d> wrote:

You can always have a 16-bit instruction after a 32-bit instruction.
You cannot have a 32-bit instruction after a 16-bit instruction (unless
your IP indexes memory on 16-bit boundaries. CDC 6600 did not. CDC 7600
did.

Where 16-bit instructions are allowed, 32-bit instructions are only
required to be aligned on 16-bit boundaries, and they are allowed to
cross the boundary between successive 256-bit instruction blocks of
the applicable form (the ones with Type I headers).
Thus, I do avoid problems, and have the same flexibility as the
System/360, just with an overhead cost.

An ISA is just as much about what you leave out as to what you leave in.

Yes, I am aware of the sage wisdom of this maxim.
My goal is not, however, to design an ISA that sets records for
elegance and beauty, desirable as those characteristics may be.
My thinking here is motivated by these considerations:

- If an architecture doesn't support, for example, IBM's old
hexadecimal floating-point type, and someone has a need for it, say to
carry out emulation, simulating it in software will be a lot slower
than what hardware could have achieved.
- Including an FPGA as part of a microprocessor, along with
instructions to use it, would make the ISA dependent on the state of
the technology at a particular point in time, one of the major flaws,
in my opinion, of the Itanium.

So perhaps I've chosen to leave out sanity and common sense, in order
to leave in instructions capable of handling any concievable data type
that someone historically had a reason to use on a computer.
Thus, I've been tweaking my 48-bit instructions so that, now, they
allow register-to-register operate instructions with 21-bit opcodes,
and load/store instructions with 10-bit opcodes - both for the regular
register banks of 32 registers each and for the extended register
banks of 128 registers each, so that there is opcode space for a wide
variety of data types.

But when I spell out what I have done, I see that I have made a
mistake! For each of the basic integer and floating data types, I have
from 2 to 4 load/store instructions, and from 8 to 16 operate
instructions. I might have some additional operate instructions, but
this seems to suggest that if my load/store instructions can have 10
bit opcodes, anything much above 13 bits for my operate instructions
is wasted. Or, if I have operate instructions with 21-bit opcodes, I
need 18-bit opcodes for the load/store instructions!
Ah, well, I'm sure I can find _some_ way of easily squeezing out the
opcode space with which to remedy this.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

John Savard <[email protected]> schrieb:

- If an architecture doesn't support, for example, IBM's old
hexadecimal floating-point type, and someone has a need for it, say to
carry out emulation, simulating it in software will be a lot slower
than what hardware could have achieved.

Nobody needs IBM's horrible hex floating point format. Well,
maybe somebody still needs for hysterical raisins, but if they do,
they can still run the S/360 system successors. Serious scientific
and engineering use died out when Fujitsu and Hitachi switched from
IBM hex float to IEEE, and IBM introduced IEEE on their mainframes.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 10/13/2026 2:24 PM, MitchAlsup wrote:

[email protected] (John Savard) posted:

On Sun, 11 Oct 2026 21:34:47 GMT, MitchAlsup
<[email protected]d> wrote:

Have you measured the space saving of paired 16-bit instructions
versus not having any 16-bit instructions ?

No, I'm not even sure how to conduct a valid measurement of that type.
Constructing a compiler for my ISA and then turning it loose on a
large corpus of FORTRAN would involve an immense amount of work.

If a program consists mostly of operate instructions, and only a small
percentage of them need to be three-address, then having 16-bit
instructions would almost shrink the size of the program in half.

You can always have a 16-bit instruction after a 32-bit instruction.
You cannot have a 32-bit instruction after a 16-bit instruction (unless
your IP indexes memory on 16-bit boundaries.

How costly is doing that? Clearly, it means half the maximum
displacement for control instructions, but since most targets are fairly close, that may not be too big an issue. Then there is the potential
for a 32 bit instruction to cross a cache line boundary. This seems to
cost some, but again how much? ISTM that the costs appears to be non
zero, but modest. Is that correct?
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Stephen Fuld <[email protected]d> schrieb:

On 10/13/2026 2:24 PM, MitchAlsup wrote:

[email protected] (John Savard) posted:

On Sun, 11 Oct 2026 21:34:47 GMT, MitchAlsup
<[email protected]d> wrote:

Have you measured the space saving of paired 16-bit instructions
versus not having any 16-bit instructions ?

No, I'm not even sure how to conduct a valid measurement of that type.
Constructing a compiler for my ISA and then turning it loose on a
large corpus of FORTRAN would involve an immense amount of work.

If a program consists mostly of operate instructions, and only a small
percentage of them need to be three-address, then having 16-bit
instructions would almost shrink the size of the program in half.

You can always have a 16-bit instruction after a 32-bit instruction.
You cannot have a 32-bit instruction after a 16-bit instruction (unless
your IP indexes memory on 16-bit boundaries.

How costly is doing that? Clearly, it means half the maximum
displacement for control instructions, but since most targets are fairly close, that may not be too big an issue. Then there is the potential
for a 32 bit instruction to cross a cache line boundary. This seems to
cost some, but again how much? ISTM that the costs appears to be non
zero, but modest. Is that correct?

Different implementations treat this differently. The POWER ISA 3.1
(POWER10), which introduced 64-bit instructions, forbids them when
they cross a cache line and just insert a NOP. They didn't want to
add the logic to handle that case, and if the ABI specifies that
functions are always aligned on a cache line (which makes sense)
then the assembler can handle that.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Thomas Koenig <[email protected]> writes:

Different implementations treat this differently. The POWER ISA 3.1 >(POWER10), which introduced 64-bit instructions, forbids them when
they cross a cache line and just insert a NOP. They didn't want to
add the logic to handle that case, and if the ABI specifies that
functions are always aligned on a cache line (which makes sense)
then the assembler can handle that.

This will complicate not only assemblers, but also JIT compilers.

And it means that code-copying compilers (whether plain code-copying
like Gforth or copy-and-patch compilers like what the CPython people
are working at) will not work, because they know little about the
instructions in the code fragments they copy. Potential solutions:

1) Disable code-copying for Power and fall back to the interpreter.

2) Compile at least the copied code fragments for Power <3.1, avoiding
the problem.

3) On Power, align each fragment you copy to the alignment it has in
the original location, using noops for padding.

Option 2 probably dominates over 3 for both ease of implementation and performance. Option 1 is slightly easier to implement than Option 2.

I expect that, just as with S/360's alignment restrictions and Power's
original alignment restrictions in little-endian mode (they were smart
enough not to require alignment in big-endian mode), this alignment
restriction will eventually be lifted. But the existing hardware with
the alignment limitation will mean that this bad idea will have to be
worked around for several decades after they fix it.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <[email protected]>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Wed, 14 Oct 2026 07:03:28 -0000 (UTC), Thomas Koenig
<[email protected]> wrote:

Different implementations treat this differently. The POWER ISA 3.1 >(POWER10), which introduced 64-bit instructions, forbids them when
they cross a cache line and just insert a NOP. They didn't want to
add the logic to handle that case,

I do not allow myself, or the implementors of Concertina II, such
luxuries.

They are instead required to behave as if Concertina II was originally implemented in microcode without cache being available, and so if an implementation wishes to add cache, it must ensure that the existence
of caching is utterly invisible and transparent to the applications
programmer.
The same applies to out-of-order execution, and thus the logic for
precise exceptions is mandatory. Even though the archetype permitted
itself to nod in this area.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Wed, 14 Oct 2026 01:05:25 GMT, [email protected] (John Savard)
wrote:

But when I spell out what I have done, I see that I have made a
mistake! For each of the basic integer and floating data types, I have
from 2 to 4 load/store instructions, and from 8 to 16 operate
instructions. I might have some additional operate instructions, but
this seems to suggest that if my load/store instructions can have 10
bit opcodes, anything much above 13 bits for my operate instructions
is wasted. Or, if I have operate instructions with 21-bit opcodes, I
need 18-bit opcodes for the load/store instructions!
Ah, well, I'm sure I can find _some_ way of easily squeezing out the
opcode space with which to remedy this.

I did indeed, and then I decided I could improve on my remedial
actions still further.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Tue, 13 Oct 2026 13:59:53 GMT, [email protected] (John Savard)
wrote:

So, on
http://www.quadibloc.com/arch/ct26int.htm
I have now added the description of a means by which 48-bit or longer >instructions (but not the 17-bit short instructions) may be executed
from within a block with a Type III header.
It's not particularly efficient - each such instruction wastes at
least 12 bits in the instruction stream - but I felt that this was
worth it to avoid the complexity of an additional type of header, and >forgivable given the degree to which the rest of the ISA goes to great >lengths to achieve economy of code space.

I managed to modify this so that the mandatory wastage is now three
bits. And I find a use for those three bits.

I have not yet described in my ISA how 17-bit instructions which start
with 11111 are used to allow these extra instructions, indicated by
the three "wasted" bits not all being zero, to be placed within blocks
with a Type I header (the pointer field, if used, is replaced by
11111, and, after eight zero bits, the rest of the instruction
immediately follows its first 24 bits).

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Wed, 14 Oct 2026 11:23:28 GMT, [email protected] (John Savard)
wrote:

I do not allow myself, or the implementors of Concertina II, such
luxuries.

And, in any case, if an instruction longer than 16 bits crosses a
cache line... it will _also_ be crossing a 256-bit instruction block
boundary, which means that pretty much all the required logic will
already have to be present in any case.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Wed, 14 Oct 2026 11:29:23 GMT, [email protected] (John Savard)
wrote:

I managed to modify this so that the mandatory wastage is now three
bits. And I find a use for those three bits.

The reason it's three bits and not four bits is because one bit got
moved from 'wastage' to 'overhead'. The net gain, of course, had to be
an even 8 bits.

I've now found more opcode space lurking around with which I was able
to add back in some instructions from previous Concertina II
incarnations I had needed to leave out. These extra instructions,
though, will not be amenable to inclusion within blocks with Type III
or Type II headers by the mechanism described above, as they belong to
another opcode space.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


[email protected] (John Savard) posted:

On Tue, 13 Oct 2026 21:24:56 GMT, MitchAlsup <[email protected]d> wrote:

You can always have a 16-bit instruction after a 32-bit instruction.
You cannot have a 32-bit instruction after a 16-bit instruction (unless >your IP indexes memory on 16-bit boundaries. CDC 6600 did not. CDC 7600 >did.

Where 16-bit instructions are allowed, 32-bit instructions are only
required to be aligned on 16-bit boundaries, and they are allowed to
cross the boundary between successive 256-bit instruction blocks of
the applicable form (the ones with Type I headers).
Thus, I do avoid problems, and have the same flexibility as the
System/360, just with an overhead cost.

Nearly 2× the number of multiplexers compared to My 66000 without
16-bit instructions. at 1-2-wide it matters little. At 10 wide it
maters more.

An ISA is just as much about what you leave out as to what you leave in.

Yes, I am aware of the sage wisdom of this maxim.
My goal is not, however, to design an ISA that sets records for
elegance and beauty, desirable as those characteristics may be.
My thinking here is motivated by these considerations:

- If an architecture doesn't support, for example, IBM's old
hexadecimal floating-point type, and someone has a need for it, say to
carry out emulation, simulating it in software will be a lot slower
than what hardware could have achieved.

I can see SW performing the conversion once {either from binary or from
ASCII} and then using IEEE 754 from then on. This is because IEEE simply
has better arithmetic {accuracy, precision, and bounds (FP64)} only
the large exponents of FP32 is questionable--and with today's memory
costs (well before AI data centers ate the market) just use FP64 in
IEEE.

I cannot see a need to preserving Hex normalizing FP in HW calculations
any longer--ever--the market has moved on.

- Including an FPGA as part of a microprocessor, along with
instructions to use it, would make the ISA dependent on the state of
the technology at a particular point in time, one of the major flaws,
in my opinion, of the Itanium.

So perhaps I've chosen to leave out sanity and common sense, in order
to leave in instructions capable of handling any concievable data type
that someone historically had a reason to use on a computer.
Thus, I've been tweaking my 48-bit instructions so that, now, they
allow register-to-register operate instructions with 21-bit opcodes,
and load/store instructions with 10-bit opcodes - both for the regular register banks of 32 registers each and for the extended register
banks of 128 registers each, so that there is opcode space for a wide
variety of data types.

But when I spell out what I have done, I see that I have made a
mistake! For each of the basic integer and floating data types, I have
from 2 to 4 load/store instructions, and from 8 to 16 operate
instructions.

My transcendental {FP} instructions come in 3×2×3 = 18 per base tran- sendental {Ln, Exp, Sin/Cos/Tan, A[Sin/Cos/Tan]} for a grand total of
96×3 = 288 transcendental calculation instructions. And I have not even calculted the {ADD, SUB, MUL, MAC, DIV, MAX, MIN, ABS, ...} stuff times
{FP8, FP16, FP32, FP64}

I might have some additional operate instructions, but
this seems to suggest that if my load/store instructions can have 10
bit opcodes, anything much above 13 bits for my operate instructions
is wasted. Or, if I have operate instructions with 21-bit opcodes, I
need 18-bit opcodes for the load/store instructions!
Ah, well, I'm sure I can find _some_ way of easily squeezing out the
opcode space with which to remedy this.

John Savard

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Wed, 14 Oct 2026 18:10:56 GMT, [email protected] (John Savard)
wrote:

I've now found more opcode space lurking around with which I was able
to add back in some instructions from previous Concertina II
incarnations I had needed to leave out. These extra instructions,
though, will not be amenable to inclusion within blocks with Type III
or Type II headers by the mechanism described above, as they belong to >another opcode space.

I should be happy about this. But this little bit of opcode space I
found hiding under the rug is twice as large as the regular opcode
space I started out using for 48-bit instructions!
That seems a bit... odd.
Still, I am glad to have those instructions back.

Also, though, one change I made for this iteration of Concertina II
may have been - indeed, almost certainly was - a mistake that I will
need to change back.
I shortened the exponent field of the internal form of floating-point
numbers, to match that of the 8087's "temporary real". This rules out supporting the new IEEE 754 128-bit and 256-bit floats with
interoperable floating-point operations in registers. (That is - load
a single precision float, store a double or extended or whatever, and
the value is correct. Just like on a 360.)
I could definitely add, out there in exotic operation land, a set of floating-point operations that use an internal form with the longer
exponent! But isn't it better for the standard, ordinary,
floating-point operations to be compatible with the standard?
I think it is better. My instincts were to design an ISA that looks
like it was designed back in 1978 or even earlier, but those are not
really good instincts; they're guiding me wrongly in matters such as
this.

During the design of this iteration, because I was using 48-bit
instructions to make up for having only one 32-bit instruction set -
and giving up the header complexity that led to 33-bit and 35-bit
instruction sets - the idea crossed my mind of adding a fourth header
type which allowed extra variability in instruction lengths.
In addition to 17-bit short instructions, and the 32, 48, 64, 80, and
96-bit instructions I now have, I was considering adding 24-bit and
40-bit instructions. (And possibly 56-bit, 72-bit, and 88-bit
instructions, though I doubted there would be any need for that.)

Fortunately, though, I couldn't manage to think of a block header
format which would be efficient in indicating where each instruction
began. Since adding 40-bit instructions was in the interest of having
more compact code, having a block header that was overly large would
cancel out any benefits. (My best approach was to use a bit vector
with only one bit for each 8 bits remaining in the block, _plus_ a
five-bit decode field, so no space would be allowed between
instructions before the area it reserves. Thus, since the bit vector
always indicated the lengths of instructions accurately, and there are
no 8-bit instructions, a 17-bit instruction starting with 0 could be
encoded as a 16-bit instruction, and a 17-bit instruction starting
with 1 could be encoded as a pair of 8-bit instructions! I felt doing
that in a 48-bit header would still be wasteful, but if it could fit
in a 40-bit header, this would indeed be "workable" - however, the
idea was clearly too bizarre even for me to consider attempting.)

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


Stephen Fuld <[email protected]d> posted:

On 10/13/2026 2:24 PM, MitchAlsup wrote:

[email protected] (John Savard) posted:

On Sun, 11 Oct 2026 21:34:47 GMT, MitchAlsup
<[email protected]d> wrote:

Have you measured the space saving of paired 16-bit instructions
versus not having any 16-bit instructions ?

No, I'm not even sure how to conduct a valid measurement of that type.
Constructing a compiler for my ISA and then turning it loose on a
large corpus of FORTRAN would involve an immense amount of work.

If a program consists mostly of operate instructions, and only a small
percentage of them need to be three-address, then having 16-bit
instructions would almost shrink the size of the program in half.

You can always have a 16-bit instruction after a 32-bit instruction.
You cannot have a 32-bit instruction after a 16-bit instruction (unless your IP indexes memory on 16-bit boundaries.

How costly is doing that? Clearly, it means half the maximum
displacement for control instructions, but since most targets are fairly close, that may not be too big an issue.

It is close to being an issue with 32-bit branch boundaries and very large functions {think FPPPP which has close to 8192 instructions as straight
line code. (from SPARC V8/V9 memory). I can conceive of My 66000 16-bit
branch displacement sufficient (18-bits of signed byte offset), but it
starts to cramp at 14-bits (15-bits of byte offset). I do not think any
single subroutine will cross the direct BR 26-bit limit (28-bit byte
offset).

Then there is the potential
for a 32 bit instruction to cross a cache line boundary. This seems to
cost some, but again how much? ISTM that the costs appears to be non
zero, but modest. Is that correct?

It's just more complexity and more chances to screw up.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Wed, 14 Oct 2026 22:34:10 GMT, [email protected] (John Savard)
wrote:

During the design of this iteration, because I was using 48-bit
instructions to make up for having only one 32-bit instruction set -
and giving up the header complexity that led to 33-bit and 35-bit
instruction sets - the idea crossed my mind of adding a fourth header
type which allowed extra variability in instruction lengths.
In addition to 17-bit short instructions, and the 32, 48, 64, 80, and
96-bit instructions I now have, I was considering adding 24-bit and
40-bit instructions. (And possibly 56-bit, 72-bit, and 88-bit
instructions, though I doubted there would be any need for that.)

Fortunately, though, I couldn't manage to think of a block header
format which would be efficient in indicating where each instruction
began. Since adding 40-bit instructions was in the interest of having
more compact code, having a block header that was overly large would
cancel out any benefits. (My best approach was to use a bit vector
with only one bit for each 8 bits remaining in the block, _plus_ a
five-bit decode field, so no space would be allowed between
instructions before the area it reserves. Thus, since the bit vector
always indicated the lengths of instructions accurately, and there are
no 8-bit instructions, a 17-bit instruction starting with 0 could be
encoded as a 16-bit instruction, and a 17-bit instruction starting
with 1 could be encoded as a pair of 8-bit instructions! I felt doing
that in a 48-bit header would still be wasteful, but if it could fit
in a 40-bit header, this would indeed be "workable" - however, the
idea was clearly too bizarre even for me to consider attempting.)

I knew that I would need to provide an extra bit at the end of the bit
string indicating the bytes at which instructions started, so that if
the last instruction in the block was complete, it could be executed
without fetching the next block.

But what about when the bit string begins with a series of ones? Maybe
one could work backwards from the zero that ended it - if there even
is one. But the way I indicate a 17-bit instruction starting with a 1
somewhat spoils the strict parallel decoding, so it seemed to me that
it would be helpful to have another extra bit, indicating if the
string of bits was preceded, from the active area of the previous
block, with an odd or an even number of ones.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

MitchAlsup <[email protected]d> schrieb:

Stephen Fuld <[email protected]d> posted:

How costly is doing that? Clearly, it means half the maximum
displacement for control instructions, but since most targets are fairly
close, that may not be too big an issue.

It is close to being an issue with 32-bit branch boundaries and very large functions {think FPPPP which has close to 8192 instructions as straight
line code. (from SPARC V8/V9 memory). I can conceive of My 66000 16-bit branch displacement sufficient (18-bits of signed byte offset), but it starts to cramp at 14-bits (15-bits of byte offset). I do not think any single subroutine will cross the direct BR 26-bit limit (28-bit byte
offset).

One good thing about My 66000 is that it has escape hatches
for larger displacements, at least when the assembler sees the
whole code. It relaxes

BEQ R1,TARGET

into

PEQ R1,T
BR TARGET

when TARGET is too far away. (And no need for condition inversion,
either).
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Thu, 15 Oct 2026 04:23:53 GMT, [email protected] (John Savard)
wrote:

it seemed to me that
it would be helpful to have another extra bit, indicating if the
string of bits was preceded, from the active area of the previous
block, with an odd or an even number of ones.

While this is a fascinating scheme to explain in detail, and by
explicitly indicating the length of each instruction, it would vastly
increase the opcode space available for 48-bit instructions and so on,
it is wholly unnecessary as the opcode space for longer instructions
has already been expanded to cover everything that is needed.

Regrettably, I couldn't dump block structure, but the goal of this
iteration of Concertina II is not to bring any other excessive
complexities in, so that it remains at least potentially capable of
wide acceptance... however utterly unrealistic such a dream may be.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Thu, 15 Oct 2026 11:32:51 GMT, [email protected] (John Savard)
wrote:

While this is a fascinating scheme to explain in detail, and by
explicitly indicating the length of each instruction, it would vastly >increase the opcode space available for 48-bit instructions and so on,
it is wholly unnecessary as the opcode space for longer instructions
has already been expanded to cover everything that is needed.

I have realized something else that makes it even more tempting.

If 10 can indicate a 17-bit instruction starting with 0, while 11
indicates a 17-bit instruction starting with 1... then I could also
use 1000 and 1100, for example, to replace 32-bit instructions by
33-bit instructions, indicating them as starting with 0 and 1
respectively.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Thu, 15 Oct 2026 19:31:11 GMT, [email protected] (John Savard)
wrote:

I have realized something else that makes it even more tempting.

If 10 can indicate a 17-bit instruction starting with 0, while 11
indicates a 17-bit instruction starting with 1... then I could also
use 1000 and 1100, for example, to replace 32-bit instructions by
33-bit instructions, indicating them as starting with 0 and 1
respectively.

Someone once said, "I can resist anything except temptation."

Of course, the joke was that this meant that he could resist nothing.

Well, in any case, I've decided to describe this additional type of
header now, but only as a potential future addition to the
architecture, without including any instructions from the additional
opcode space which it would create.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Two very important features have been added to the instruction set!
One is a way to indicate permissible branch targets, so as to permit a
branch control feature to be added.
Another is an instruction for saving the return address.
Actually, that latter one was not missing from the architecture; the
subroutine jump instruction already had a full memory address with a
16-bit displacement, therefore it had all the addressing modes
available - including a program-relative branch. However, since the
branch target instruction included a 17-bit short instruction within
its body, having a way to save the return address that fits in that
slot tidily allows the start of a program to be both a permissible
branch target and the necessary first instruction!

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

An additional upload has been made.
Two features are added:
A modified instruction set that allows, for VLIW-style instruction
blocks, the inclusion of paired short instructions that are guaranteed
to execute in parallel, one being fixed and the other being floating,
this being inspired by the i860;
An emulation feature, which includes a complicated address mapping
feature to allow code to execute which is ignorant of the fact that it
is in code blocks with 32-bit headers.
This lets code for two other important CPU architectures run without
switching modes, but, of course, with all this capability present,
doubtless a feature will exist to permit running such code natively as
well in an alternate operation mode.
Still to come is a sixth instruction block format where it can be
indicated that data in storage is in memory of a different width -
thaat is, based on 48-bit, 36-bit, or 60-bit units rather than on the
32-bit word.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Tue, 20 Oct 2026 23:04:17 GMT, [email protected] (John Savard)
wrote:

Still to come is a sixth instruction block format where it can be
indicated that data in storage is in memory of a different width -
thaat is, based on 48-bit, 36-bit, or 60-bit units rather than on the
32-bit word.

That has now been added, but in the form of a sixth and seventh
instruction block or block header format.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Wed, 21 Oct 2026 14:16:35 GMT, [email protected] (John Savard)
wrote:

On Tue, 20 Oct 2026 23:04:17 GMT, [email protected] (John Savard)
wrote:

Still to come is a sixth instruction block format where it can be
indicated that data in storage is in memory of a different width -
thaat is, based on 48-bit, 36-bit, or 60-bit units rather than on the >>32-bit word.

That has now been added, but in the form of a sixth and seventh
instruction block or block header format.

And now I re-arranged my block headers a bit, compressing the format
of the header for the emulation of certain 32-bit architectures, so as
to add a new feature: in addition to having one format available for
embedding 48-bit or longer instructions in instruction blocks with
headers that don't include variable-length instruction support, there
is now another format, for code without block headers, to allow
embedding of 48-bit instructions only.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2