From Newsgroup: comp.arch

After leaving Concertina IV alone for a couple of days, I finally came up
with an idea to add a feature to it.
Not just any feature, though. If anything, this new feature might well be viewed by many as just about the silliest and craziest idea anyone could
have had for a feature to add to the architecture!
Which probably means I shouldn't have done it. But that hasn't stopped me before.
A while back, after making Concertina IV an architecture with a
conventional variable-length instruction set, I added 48-bit, 80-bit,
112-bit and 144-bit instructions which allowed me to include VLIW features. Well, the 80-bit and 144-bit instructions had some extra bits available,
so I've now used one of those bits to modify the form of the regular 32-
bit instructions.
If it is set, the load/store memory-reference instructions in the normal 32-bit instruction set change to memory-reference _operate_ instructions
that only work with the first eight registers.

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

From Newsgroup: comp.arch

Another addition has been made in connection with the instructions
providing VLIW features with embedded 32-bit instructions.
Instead of only the 48-bit instruction of this kind offering
predication, now a 160-bit instruction with four embedded 32-bit
instructions is added that also offers predication. While this means
32 bits of overhead, at least it's now 16 bits per pair of 32-bit
embedded instructions, as for the 80-bit instruction, and not 16 bits
for just one 32-bit instruction, as for the 48-bit instruction, so it
still offers a more efficient way of having predication.

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

From Newsgroup: comp.arch

On Wed, 10 Jun 2026 13:36:51 GMT, [email protected] (John Savard)
wrote:

now a 160-bit instruction with four embedded 32-bit
instructions is added that also offers predication.

It hadn't been drawn quite right; I've fixed that in addition to
adding 288-bit instructions which allow immediate instructions for
256-bit constants, thus rounding out the instruction set.

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

From Newsgroup: comp.arch

In article <1107gai$3igkf$[email protected]>, [email protected]d (quadi)
wrote:

Well, the 80-bit and 144-bit instructions had some extra bits
available, so I've now used one of those bits to modify the form of
the regular 32-bit instructions.

If it is set, the load/store memory-reference instructions in the
normal 32-bit instruction set change to memory-reference _operate_ instructions that only work with the first eight registers.

Is there a way for the instruction decoder to tell that a jump has
arrived in the middle of one of these blocks? If not, compiler bugs that
do that will be unusually arcane, since instructions will behave
differently.

John
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sat, 13 Jun 2026 14:07 +0100 (BST), [email protected] (John Dallman)
wrote:

Is there a way for the instruction decoder to tell that a jump has
arrived in the middle of one of these blocks? If not, compiler bugs that
do that will be unusually arcane, since instructions will behave
differently.

No, there is not, because Concertina IV doesn't have the block
structure of Concertina II.

On an IBM System/360, you can branch in the middle of an instruction
too, so this _in itself_ is not a fatal flaw. However, an assembler
programmer might be *tempted* to branch to an instruction embedded in
another instruction, so I've carefully explained the conditions under
which this is not to be done, as it will cause erroneous operation due
to instructions behaving differently.

The idea of someone writing a compiler that did this, rather than just
a naive assembler programmer making this mistake, did not occur to me.
I expected compiler writers to know what they were doing.

Of course, though, on further reflection, I am able to think of at
least one case where this could arise other than through sheer
stupidity: if instructions were changed to being embedded in a
separate pass of the compiler from the one that originally generated
them. Given, however, the reasons for embedding an instruction, I
didn't really think a compiler could work this way.

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

From Newsgroup: comp.arch


[email protected] (John Dallman) posted:

In article <1107gai$3igkf$[email protected]>, [email protected]d (quadi) wrote:

Well, the 80-bit and 144-bit instructions had some extra bits
available, so I've now used one of those bits to modify the form of
the regular 32-bit instructions.

If it is set, the load/store memory-reference instructions in the
normal 32-bit instruction set change to memory-reference _operate_ instructions that only work with the first eight registers.

Is there a way for the instruction decoder to tell that a jump has
arrived in the middle of one of these blocks? If not, compiler bugs that
do that will be unusually arcane, since instructions will behave
differently.

In general, no. 68000 assembly writers would code a else-clause as a
constant that could be consumed by the last instruction of then-clause
to avoid a <second> branch.

John

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


[email protected] (John Savard) posted:

On Sat, 13 Jun 2026 14:07 +0100 (BST), [email protected] (John Dallman)
wrote:

Is there a way for the instruction decoder to tell that a jump has
arrived in the middle of one of these blocks? If not, compiler bugs that
do that will be unusually arcane, since instructions will behave >differently.

No, there is not, because Concertina IV doesn't have the block
structure of Concertina II.

On an IBM System/360, you can branch in the middle of an instruction
too, so this _in itself_ is not a fatal flaw. However, an assembler programmer might be *tempted* to branch to an instruction embedded in
another instruction, so I've carefully explained the conditions under
which this is not to be done, as it will cause erroneous operation due
to instructions behaving differently.

These are normal issues with a variable length instruction set--and
one of the reasons My 66000 ISA is encoded such that the 6 HOBs are
the major OpCode (unlike RISC-V)--and one of the reason 6 major OpCodes
are reserved in perpetuity. Integer constants with 000000 and 111111
are illegal, FP opcodes between ±{1/128 to 32} are illegal. Jumping
into code-space constants is likely to raise ILLEGAL OpCode.

The idea of someone writing a compiler that did this, rather than just
a naive assembler programmer making this mistake, did not occur to me.
I expected compiler writers to know what they were doing.

Of course, though, on further reflection, I am able to think of at
least one case where this could arise other than through sheer
stupidity: if instructions were changed to being embedded in a
separate pass of the compiler from the one that originally generated
them. Given, however, the reasons for embedding an instruction, I
didn't really think a compiler could work this way.

John Savard

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

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

The idea of someone writing a compiler that did this, rather than
just a naive assembler programmer making this mistake, did not occur
to me. I expected compiler writers to know what they were doing.

Usually, they have some idea of what they are doing, but compilers are software, and software has flaws. Here are a few of the most silly
compiler bugs I have dealt with in the last 30 years:

* Doing pointer comparisons with signed arithmetic, in an x86-32 Windows compiler. This was fine for application code that ran in the lower half
of the 32-bit virtual address space. However, when Microsoft introduced
3GB mode, which let an application use the lower three-quarters of the
address space, it failed messily.

* Using the x86 scaled index register addressing modes with the LEA
instruction to do integer arithmetic with the address units. It's a good
idea provided you respect the commutativity laws of arithmetic. When you
don't ... my bug report was a short program that only used integer
arithmetic and produced different answers with /O1 and /O2.

* Bizarre behaviour with a doubly-linked list of structs that contained
next and previous pointers. It compiled

struct_pointer p;
. . .
*p = *(p->next);

This is an odd thing to do, but it was needed.

The generated code, started with p, offset it and fetched p->next, then
read 4 bytes from *(p->next), and stored it at *p.

Then it did the same thing again, adding 4 to each address, then the same
again adding 8, and so on.

Because it fetched p->next each time, once it had copied the "next"
element, it started fetching from the struct that had originally been p-> next->next.

John
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

MitchAlsup wrote:

[email protected] (John Dallman) posted:

In article <1107gai$3igkf$[email protected]>, [email protected]d (quadi)
wrote:

Well, the 80-bit and 144-bit instructions had some extra bits
available, so I've now used one of those bits to modify the form of
the regular 32-bit instructions.

If it is set, the load/store memory-reference instructions in the
normal 32-bit instruction set change to memory-reference _operate_
instructions that only work with the first eight registers.

Is there a way for the instruction decoder to tell that a jump has
arrived in the middle of one of these blocks? If not, compiler bugs that
do that will be unusually arcane, since instructions will behave
differently.

In general, no. 68000 assembly writers would code a else-clause as a
constant that could be consumed by the last instruction of then-clause
to avoid a <second> branch.

I have written code like several times, even shipped it.

After the 486, it was a bad choice performance-wise instead of a win.

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

In article <[email protected]>,
[email protected]d (MitchAlsup) wrote:

These are normal issues with a variable length instruction set--and
one of the reasons My 66000 ISA is encoded such that the 6 HOBs are
the major OpCode (unlike RISC-V)--and one of the reason 6 major
OpCodes are reserved in perpetuity. Integer constants with 000000
and 111111 are illegal, FP opcodes between �{1/128 to 32} are
illegal. Jumping into code-space constants is likely to raise
ILLEGAL OpCode.

That's a particularly pragmatic feature of My 66000, and I admire it.

John
--- Synchronet 3.22a-Linux NewsLink 1.2