There is an interesging way of encoding immediates in the processor
contained in Helmut Neemann's Digital circuit simulator.

All instructions have 16 bit length, the architecture has 16
registers and a Ra = Ra op Rb scheme, and immediates allow Ra =
Ra op Imm.

The way this is encoded is interesting: All normal opcodes have
the high bit set to zero. An opcode with a leading high bit sets
the low 15 bits of the immediate operand, and the high bit
is encoded in the immediate (load, store, add, ..) instruction.

Example: ADDI R4, 0x1234 is encoded as two words, as 0x9234 0x0b40
where the first word is the constant 0x1234 or 0x8000, 0x0b is
the opcode for "add immediate", 4 is the register number and the
trailing 0 means no high bit; in other instructions, the
second register number would be there.

By comparison, ADDI R4, 0x9234 is encoded as 0x9234 0x0b41,
with the last bit indicating that the high bit on the immediate
operand is set.

In his simple RISC microarchitecture, the instructions with a
leading high bit are actually instructions which load a special
register with the payload, and the "add immediate" uses that as
an operand with the extra bit.

It was jarring at first to see the immediate data preceding the
actual instruction in the binary :-)

Variants are possible, for example extending the number of bits
in the prefix to save opcode space (four bits would be possible
here, five with a 32-register design), specifying which register
would be used as immediate, having a "load immediate data into
temporary register" instruction set a flag so a normal opcode can
be re-used, etc, but I like the general idea, especially since
it does not require a wide fetch (and I am still thinking
abot a 6502 replacement :-)

Comments? Has this been done before? I certainly haven't read
about this previously, and the documentation of the processor in
Digital as a test case is not great, I had to reverse-engineer
this from the translated assembler code.

On 8/11/2021 3:48 AM, Thomas Koenig wrote:
> There is an interesging way of encoding immediates in the processor
> contained in Helmut Neemann's Digital circuit simulator.
>
> All instructions have 16 bit length, the architecture has 16
> registers and a Ra = Ra op Rb scheme, and immediates allow Ra =
> Ra op Imm.
>
> The way this is encoded is interesting: All normal opcodes have
> the high bit set to zero. An opcode with a leading high bit sets
> the low 15 bits of the immediate operand, and the high bit
> is encoded in the immediate (load, store, add, ..) instruction.
>
> Example: ADDI R4, 0x1234 is encoded as two words, as 0x9234 0x0b40
> where the first word is the constant 0x1234 or 0x8000, 0x0b is
> the opcode for "add immediate", 4 is the register number and the
> trailing 0 means no high bit; in other instructions, the
> second register number would be there.
>
> By comparison, ADDI R4, 0x9234 is encoded as 0x9234 0x0b41,
> with the last bit indicating that the high bit on the immediate
> operand is set.
>
> In his simple RISC microarchitecture, the instructions with a
> leading high bit are actually instructions which load a special
> register with the payload, and the "add immediate" uses that as
> an operand with the extra bit.
>
> It was jarring at first to see the immediate data preceding the
> actual instruction in the binary :-)
>
> Variants are possible, for example extending the number of bits
> in the prefix to save opcode space (four bits would be possible
> here, five with a 32-register design), specifying which register
> would be used as immediate, having a "load immediate data into
> temporary register" instruction set a flag so a normal opcode can
> be re-used, etc, but I like the general idea, especially since
> it does not require a wide fetch (and I am still thinking
> abot a 6502 replacement :-)
>
> Comments? Has this been done before? I certainly haven't read
> about this previously, and the documentation of the processor in
> Digital as a test case is not great, I had to reverse-engineer
> this from the translated assembler code.
>

FWIW:
In a smaller / short lived ISA of mine (BSR1, a 32-bit direct
predecessor of BJX2), there were some encodings which split it up like:
First word contains the high 12 bits;
Second work contains the low 4 bits.

This could allow, say:
ADD 0x1234, R7
To be encoded as:
A123 4974

Which would be decoded/executed using 2 cycles.
Though, this was only for certain ops, as opposed to an in-general part
of the instruction encoding.

These encodings were not retained in BJX2, which instead went to 32-bit
ops, eg:
F827_1234

Could have, in theory, designed an ISA where Azzz/Bzzz were interpreted
more like how Jumbo prefixes work in scalar cores, say:
A123 A456 CA78 // ADD 0x12345678, R10

But, alas...

On Wednesday, August 11, 2021 at 11:12:48 AM UTC-4, BGB wrote:
> On 8/11/2021 3:48 AM, Thomas Koenig wrote:
> > There is an interesging way of encoding immediates in the processor
> > contained in Helmut Neemann's Digital circuit simulator.
> >
> > All instructions have 16 bit length, the architecture has 16
> > registers and a Ra = Ra op Rb scheme, and immediates allow Ra =
> > Ra op Imm.
> >
> > The way this is encoded is interesting: All normal opcodes have
> > the high bit set to zero. An opcode with a leading high bit sets
> > the low 15 bits of the immediate operand, and the high bit
> > is encoded in the immediate (load, store, add, ..) instruction.
> >
> > Example: ADDI R4, 0x1234 is encoded as two words, as 0x9234 0x0b40
> > where the first word is the constant 0x1234 or 0x8000, 0x0b is
> > the opcode for "add immediate", 4 is the register number and the
> > trailing 0 means no high bit; in other instructions, the
> > second register number would be there.
> >
> > By comparison, ADDI R4, 0x9234 is encoded as 0x9234 0x0b41,
> > with the last bit indicating that the high bit on the immediate
> > operand is set.
> >
> > In his simple RISC microarchitecture, the instructions with a
> > leading high bit are actually instructions which load a special
> > register with the payload, and the "add immediate" uses that as
> > an operand with the extra bit.
> >
> > It was jarring at first to see the immediate data preceding the
> > actual instruction in the binary :-)
> >
> > Variants are possible, for example extending the number of bits
> > in the prefix to save opcode space (four bits would be possible
> > here, five with a 32-register design), specifying which register
> > would be used as immediate, having a "load immediate data into
> > temporary register" instruction set a flag so a normal opcode can
> > be re-used, etc, but I like the general idea, especially since
> > it does not require a wide fetch (and I am still thinking
> > abot a 6502 replacement :-)
> >
> > Comments? Has this been done before? I certainly haven't read
> > about this previously, and the documentation of the processor in
> > Digital as a test case is not great, I had to reverse-engineer
> > this from the translated assembler code.
> >
> FWIW:
> In a smaller / short lived ISA of mine (BSR1, a 32-bit direct
> predecessor of BJX2), there were some encodings which split it up like:
> First word contains the high 12 bits;
> Second work contains the low 4 bits.
>
> This could allow, say:
> ADD 0x1234, R7
> To be encoded as:
> A123 4974
>
> Which would be decoded/executed using 2 cycles.
> Though, this was only for certain ops, as opposed to an in-general part
> of the instruction encoding.
>
> These encodings were not retained in BJX2, which instead went to 32-bit
> ops, eg:
> F827_1234
>
>
> Could have, in theory, designed an ISA where Azzz/Bzzz were interpreted
> more like how Jumbo prefixes work in scalar cores, say:
> A123 A456 CA78 // ADD 0x12345678, R10
>
> But, alas...

I believe this has been done before.
James Bowman’s J1 stack machine used a single bit to indicate immediate literals.
I believe Jan Gray’s xr16 used prefix instructions which are somewhat similar.
Rather than a single bit indicating an immediate prefix, a four-bit code was used.
Using just a single bit consumes 50% of the opcode space for immediates. On a
machine with wider instructions it is possible to use more than one bit to indicate
an immediate and still have an entire immediate coded in only two instructions.
I have used immediate prefixes for ANY1 and other designs. The EXI opcodes
(standing for extended immediate) encode higher order immediate constant bits
for the following instruction.

On 13.08.2021 14:53, robf...@gmail.com wrote:
> On Wednesday, August 11, 2021 at 11:12:48 AM UTC-4, BGB wrote:
>
> I believe this has been done before.
> James Bowman’s J1 stack machine used a single bit to indicate immediate literals.
> I believe Jan Gray’s xr16 used prefix instructions which are somewhat similar.
> Rather than a single bit indicating an immediate prefix, a four-bit code was used.
> Using just a single bit consumes 50% of the opcode space for immediates. On a
> machine with wider instructions it is possible to use more than one bit to indicate
> an immediate and still have an entire immediate coded in only two instructions.
> I have used immediate prefixes for ANY1 and other designs. The EXI opcodes
> (standing for extended immediate) encode higher order immediate constant bits
> for the following instruction.
>

That's not very different from the MIPS32 Architecture way of loading
wide immediates:

lui $a0, 0x89aa
addiu $a0, 0xcdef # -> 0x89abcdef

OR
lui $a0, 0x89ab
ori $a0, 0xcdef # -> 0x89abcdef

- MIPS assemblers provides a pseudo-opcode "li reg, imm" that chooses an
optimal instruction sequence (e.g. only loading high 16 bits,
-32768..32767, 32768..65535 etc)

- The linker only supports the addiu form, because the displacement in
load/store instructions is a sign-extended 16-bit-immediate

Admittedly, all in-order MIPS processors didn't combine those two
instructions into a single "load long immediate" operation (but that
should today easily be possible).

Regards
--
Bernd

Bernd Linsel <bl1-removethis@gmx.com> schrieb:
> On 13.08.2021 14:53, robf...@gmail.com wrote:
>> On Wednesday, August 11, 2021 at 11:12:48 AM UTC-4, BGB wrote:
>>
>> I believe this has been done before.
>> James Bowman’s J1 stack machine used a single bit to indicate immediate literals.
>> I believe Jan Gray’s xr16 used prefix instructions which are somewhat similar.
>> Rather than a single bit indicating an immediate prefix, a four-bit code was used.
>> Using just a single bit consumes 50% of the opcode space for immediates. On a
>> machine with wider instructions it is possible to use more than one bit to indicate
>> an immediate and still have an entire immediate coded in only two instructions.
>> I have used immediate prefixes for ANY1 and other designs. The EXI opcodes
>> (standing for extended immediate) encode higher order immediate constant bits
>> for the following instruction.
>>
>
> That's not very different from the MIPS32 Architecture way of loading
> wide immediates:
>
> lui $a0, 0x89aa
> addiu $a0, 0xcdef # -> 0x89abcdef
>
> OR
> lui $a0, 0x89ab
> ori $a0, 0xcdef # -> 0x89abcdef

With the scheme I was discussing, it is also possible to use
the long constant directly in any instruction.

If one wanted to work this out for a 32-bit architecture with 32
registers (5 bits register designator), then it would make sense
to have a four-bit prefix and have the fifth bit selecting between
the first and second operand.

So,

subi $a0, $a1, 0x91234567

could be encoded by the assemmbler as

0xF91234567
subi $a0, $1, 0x09

and

subi $a0, 0x91234567, $a1

as

0xF11234567
subi $a0, 0x09, $a2

so it would save an instruction on an in-order machine.

This would also allow 32-bit branches.

On 8/13/2021 10:42 AM, Thomas Koenig wrote:
> Bernd Linsel <bl1-removethis@gmx.com> schrieb:
>> On 13.08.2021 14:53, robf...@gmail.com wrote:
>>> On Wednesday, August 11, 2021 at 11:12:48 AM UTC-4, BGB wrote:
>>>
>>> I believe this has been done before.
>>> James Bowman’s J1 stack machine used a single bit to indicate immediate literals.
>>> I believe Jan Gray’s xr16 used prefix instructions which are somewhat similar.
>>> Rather than a single bit indicating an immediate prefix, a four-bit code was used.
>>> Using just a single bit consumes 50% of the opcode space for immediates. On a
>>> machine with wider instructions it is possible to use more than one bit to indicate
>>> an immediate and still have an entire immediate coded in only two instructions.
>>> I have used immediate prefixes for ANY1 and other designs. The EXI opcodes
>>> (standing for extended immediate) encode higher order immediate constant bits
>>> for the following instruction.
>>>
>>
>> That's not very different from the MIPS32 Architecture way of loading
>> wide immediates:
>>
>> lui $a0, 0x89aa
>> addiu $a0, 0xcdef # -> 0x89abcdef
>>
>> OR
>> lui $a0, 0x89ab
>> ori $a0, 0xcdef # -> 0x89abcdef
>
> With the scheme I was discussing, it is also possible to use
> the long constant directly in any instruction.
>

This is one nice feature, though spending an entire bit to do so, in the
16-bit encoding space, is a bit steep. You effectively halve the size of
the encoding space.

It would be less steep to effectively load 12 bits at a time, then pull
4 bits from the register field of the following instruction.
One could then have immediate values of, say:
16, 28, 40, 52, 64 bits.

> If one wanted to work this out for a 32-bit architecture with 32
> registers (5 bits register designator), then it would make sense
> to have a four-bit prefix and have the fifth bit selecting between
> the first and second operand.
>

Possibly, could make sense for a 32-bit instruction format.

> So,
>
> subi $a0, $a1, 0x91234567
>
> could be encoded by the assemmbler as
>
> 0xF91234567
> subi $a0, $1, 0x09
>
> and
>
> subi $a0, 0x91234567, $a1
>
> as
>
> 0xF11234567
> subi $a0, 0x09, $a2
>

Hmm, say:
TZnm_ZeoZ //3R
TZnm_Zeii //3RI, Imm9
TZnm_ZeZZ //2R

Where, T:
0/1: Basic Instruction
2/3: Wide (?)
4/5: Pred-True
6/7: Pred-False
8/9: Pred-True, Wide (?)
A/B: Pred-False, Wide (?)
C/D: Imm28 Prefix
E/F: ?

So, say:
Ciii_iiii 0Znm_ZeiZ //3RI, Imm33s

OTOH, one could do this, and make the ISA nominally use 64 GPRs for
everything:
TZnm_eeoZ //3R

Where the 'ee' field adds 2 bits to each register (qqnnmmoo).

> so it would save an instruction on an in-order machine.
>
> This would also allow 32-bit branches.
>

My ISA has Imm33s in 64-bits, though generally by combining a prefix
with 24 payload bits, with an Imm9 instruction. Granted, the space for
Imm9 instructions is a bit smaller than for 3R instructions.

FWIW, I currently have:
20-bit branches, in a 32-bit encoding;
33-bit branches, in a 64-bit encoding.
48-bit absolute branches, in a 64-bit encoding.

I could have had 44-bit relative branches in the encoding, but... this
would have been a bit too expensive.

I don't yet have any binaries which exceed the limits of the 20-bit branch.

For most other cases where one needs a long-distance branch (such as in
a lambda or domain-transfer thunk), the Abs48 encoding actually makes
more sense.

....