Have a habit of running out of op-code space on new ISA designs.

So, added a type tag to each register. I want four types: unsigned, signed, float and Posit. That and four data sizes requires 16 distinct memory read instructions! But it ends there. Only four store instructions, one for each data size. Only one instance of ADD SUB MUL DIV ! E.g. the R or S register determines the type of operation, automatic conversions between types at the option of the implementation, either do the implied conversion, take an exception or do an unimplemented instruction trap.

If I decide to add more types, such as a saturation flag, that goes in the type tag and requires more load instructions. At which point I go to a longer load instruction with room for additional tag bits. No additional ADD SUB MUL DIV instructions needed! If one wants more than one data item per register (MMX etc) same situation.

The down side is saving and restoring registers. For 24 and 48-bit registers no problem: save into 32 or 64-bit memory. For 32 and 64-bit registers, ugh, on an FPGA just create a small amount of wider memory. Another option is to save the load type info as a load instruction with a very long immediate?

At this time a 24 and 32-bit RISC instructions with two and three operands respectively. Showing 25% remaining op-code space on a full set of op-codes. Probably will add 40 or 48-bit load instructions with lots of instruction modifiers and additional register fields.

JimBrakefield wrote:
> Have a habit of running out of op-code space on new ISA designs.
>
> So, added a type tag to each register. I want four types: unsigned,
> signed, float and Posit. That and four data sizes requires 16
> distinct memory read instructions! But it ends there. Only four
> store instructions, one for each data size. Only one instance of ADD
> SUB MUL DIV ! E.g. the R or S register determines the type of
> operation, automatic conversions between types at the option of the
> implementation, either do the implied conversion, take an exception
> or do an unimplemented instruction trap.

Please take another look at how Mill is doing this exact thing!

Ivan (and a few others) have expounded on this here in c.arch for a
number of years now.

Yes, the idea is one of those that seem obvious in hindsight. :-)

The Mill founders decided on a slightly different separation between the
load tags and the instructions needed, in particular you want separate
FP and INT opcodes just so that you can do Int/logical ops on FP bit
patterns.

Terje

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

On Friday, May 19, 2023 at 12:25:19 AM UTC-4, Terje Mathisen wrote:
> JimBrakefield wrote:
> > Have a habit of running out of op-code space on new ISA designs.
> >
> > So, added a type tag to each register. I want four types: unsigned,
> > signed, float and Posit. That and four data sizes requires 16
> > distinct memory read instructions! But it ends there. Only four
> > store instructions, one for each data size. Only one instance of ADD
> > SUB MUL DIV ! E.g. the R or S register determines the type of
> > operation, automatic conversions between types at the option of the
> > implementation, either do the implied conversion, take an exception
> > or do an unimplemented instruction trap.
> Please take another look at how Mill is doing this exact thing!
>
> Ivan (and a few others) have expounded on this here in c.arch for a
> number of years now.
>
> Yes, the idea is one of those that seem obvious in hindsight. :-)
>
> The Mill founders decided on a slightly different separation between the
> load tags and the instructions needed, in particular you want separate
> FP and INT opcodes just so that you can do Int/logical ops on FP bit
> patterns.
>
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

Been thinking about adding a tag to the register file myself to track operand
types. Thor2024 has separate float and integer files, but the float file may
contain float, decimal-float or posits. The compiler may know what type of
data is in the register, so this may be of limited use.

For Thor four different sets of instructions are used for signed, unsigned,
float and posit. It takes a lot of opcodes, but so what? Seven bits at the
root level. This allows the decoder to decide rather than having to read a
register first. Instructions could be queued before the register file is read
or valid. Immediate constants are interpreted differently by the decoder
depending on the operand type. Decode would have to wait for a register
file read if it went by the type stored with a register.

The compare-branch instruction has a two-bit field for the compare type
which is signed, unsigned, float, and posit.

Float loads and stores in Thor2024 have opcodes separate from integer
loads and stores as do posits as well. The float loads and stores convert
data to or from different data widths for storage to a fixed size for
processing.

On Friday, May 19, 2023 at 3:48:37 AM UTC+1, JimBrakefield wrote:
> Have a habit of running out of op-code space on new ISA designs.
>
> So, added a type tag to each register. I want four types: unsigned,
> signed, float and Posit. That and four data sizes requires 16
> distinct memory read instructions! But it ends there. Only
> four store instructions, one for each data size.

ridiculous, isn't it? you'd think every RISC ISA would work that way.
you can also get away with a much shorter STORE instruction
because you simply take the tag's width.

as Terje mentions, the Mill has had this solved since its inception.
the tag is carried from LOAD thru ARITH right to STORE, and copied
across to any reg-to-reg intermediates for further STORE.
there are "NARROW" and "WIDEN" instructions which change the
tag-type, there *may* be some "fp<->int" conversions that also
change the tag-type but apart from that it's all there is.

so for example as hinted above if you really want a different
STORE width you perform a NARROW or WIDEN first. this you
will find greatly reduces Hazard complexity as it fire-breaks
the STORE Dependency Hazards (3-in 1-out) from the
1-in 1-out needed for N/W.

the problems come as you already suspected on context-switch
(including function calls). there you suddenly have not only
registers to save/restore but also their tags. 8-bit tags is
now 32 bytes of extra context, and with the tags being "bits"
your ISA had better have a damn good way to save/restore
individual bytes into tags.

if you go for a separate "tag regfile" you need not poison the
ISA by reducing the bit-width of GPR/FPRs to something mad
like 24-bit instead of 32-bit. this then solves the issue of
SRAM allocation in FPGAs, they're allocated separately.

one other nice thing to consider would be a "this register is in use"
tag-bit. if set to zero the contents of the register may be
assumed to be zero (or *actually* set to zero) and thus those bits
may be used as a Predicate Mask for Vector LOAD/STORE,
performing automatic VCOMPRESS and VEXPAND.

the bit would be automatically set the moment the register
is used as a destination. if used as a source and the bit
is not set, an Illegal Instruction Trap can be raised, which
would prevent the scenario where someone leaked data
from a different security context.

last time i heard about tags was an obscure Texas Instruments
DSP from the 90s. beyond that for some bizarre unfathomable
reason the idea went completely out of fashion.

l.

https://science.lpnu.ua/sites/default/files/journal-paper/2019/jul/17084/volum3number1text-9-16_1.pdf

Burroughs, Elbrus, the historical conclusion was
(bear in mind: no L1/L2 Caches), memory is so
damn expensive it is insane to have tags.

primary focus of that paper seems to be to take
tagged registers as a "given" and to then see if
Parallelism may be achieved on top of that.

l.

On 2023-05-22 13:44, luke.l...@gmail.com wrote:
> On Friday, May 19, 2023 at 3:48:37 AM UTC+1, JimBrakefield wrote:
>> Have a habit of running out of op-code space on new ISA designs.
>>
>> So, added a type tag to each register. I want four types: unsigned,
>> signed, float and Posit. That and four data sizes requires 16
>> distinct memory read instructions! But it ends there. Only
>> four store instructions, one for each data size.
>
> ridiculous, isn't it? you'd think every RISC ISA would work that way.
> you can also get away with a much shorter STORE instruction
> because you simply take the tag's width.
>
> as Terje mentions, the Mill has had this solved since its inception.
> the tag is carried from LOAD thru ARITH right to STORE, and copied
> across to any reg-to-reg intermediates for further STORE.
> there are "NARROW" and "WIDEN" instructions which change the
> tag-type, there *may* be some "fp<->int" conversions that also
> change the tag-type but apart from that it's all there is.

The Mill tags ("operand metadata" in Mill terms) do not indicate the
semantic type of the operand value, only its width in bits and whether
it is a single (scalar) value or a vector (SIMD). The tags also flag
various error conditions such as values that are not available for some
reason. The operations that convert integer values to floating-point
values or vice versa do not change the tag (unless the operand width
changes).

The Mill has separate instructions (opcodes) for integer (signed or
unsigned) and floating point (binary or decimal) operations. Thanks to
the tags, the same instructions/opcodes apply uniformly to operands of
all sizes and to scalars and vectors.

"luke.l...@gmail.com" <luke.leighton@gmail.com> writes:
>https://science.lpnu.ua/sites/default/files/journal-paper/2019/jul/17084/volum3number1text-9-16_1.pdf
>
>Burroughs, Elbrus, the historical conclusion was
>(bear in mind: no L1/L2 Caches), memory is so
>damn expensive it is insane to have tags.

The burroughs large systems still use tags (albeit emulated
on Intel CPUs) to define data types.

The burroughs medium systems had a slightly different mechanism
to indicate data type independent of the instruction; rather the
address syllables (instruction operands) encoded the data type
in the most significant digit as one of four possibilities:
0b00 - Unsigned Numeric
0b01 - Signed Numeric
0b10 - Unsigned Alphanumeric
0b11 - Indirect (i.e. the syllable was a pointer to an address syllable,
which could, in turn have a data type of 0b11, und so weiter).

The other two bits of the MSD encoded an optional index register
to apply to the address calculation.

Which allowed mixed operand types on an instruction:

ADD 0505 Operand1(UN), Operand2(SN), Operand3(UA)

which would add the unsigned first operand to the second
and store the sign in the zone digit of the most significant
byte of the alpha (numeric + the EBCDIC/ASCII zone digit @F@/@3@).

ARMv9 has the MTE (Memory Tagging Extension) which defines a
separate bank of memory for the tag bits (to leverage existing
DIMM widths). This is more designed around security than reducing
the instruction set.

On Monday, May 22, 2023 at 5:44:37 AM UTC-5, luke.l...@gmail.com wrote:
> On Friday, May 19, 2023 at 3:48:37 AM UTC+1, JimBrakefield wrote:
> > Have a habit of running out of op-code space on new ISA designs.
> >
> > So, added a type tag to each register. I want four types: unsigned,
> > signed, float and Posit. That and four data sizes requires 16
> > distinct memory read instructions! But it ends there. Only
> > four store instructions, one for each data size.
<
> ridiculous, isn't it? you'd think every RISC ISA would work that way.
<
What to leave in, what to leave out........
<
> you can also get away with a much shorter STORE instruction
> because you simply take the tag's width.
>
> as Terje mentions, the Mill has had this solved since its inception.
> the tag is carried from LOAD thru ARITH right to STORE, and copied
> across to any reg-to-reg intermediates for further STORE.
> there are "NARROW" and "WIDEN" instructions which change the
> tag-type, there *may* be some "fp<->int" conversions that also
> change the tag-type but apart from that it's all there is.
>
> so for example as hinted above if you really want a different
> STORE width you perform a NARROW or WIDEN first. this you
> will find greatly reduces Hazard complexity as it fire-breaks
> the STORE Dependency Hazards (3-in 1-out) from the
> 1-in 1-out needed for N/W.
>
> the problems come as you already suspected on context-switch
> (including function calls). there you suddenly have not only
> registers to save/restore but also their tags. 8-bit tags is
> now 32 bytes of extra context, and with the tags being "bits"
> your ISA had better have a damn good way to save/restore
> individual bytes into tags.
<
It is not just the context, but now you are faced with needing even
more memory reference instructions just to save and restore the
registers and associated tags--when you don't know what value
in in the tags !!??!!
>
> if you go for a separate "tag regfile" you need not poison the
> ISA by reducing the bit-width of GPR/FPRs to something mad
> like 24-bit instead of 32-bit. this then solves the issue of
> SRAM allocation in FPGAs, they're allocated separately.
>
> one other nice thing to consider would be a "this register is in use"
> tag-bit. if set to zero the contents of the register may be
> assumed to be zero (or *actually* set to zero) and thus those bits
> may be used as a Predicate Mask for Vector LOAD/STORE,
> performing automatic VCOMPRESS and VEXPAND.
<
With an 8-bit tag, you could simply define rules and just have
generic arithmetic that simply works::
<
i = f×d-f×l+u
<
Which would produce 1 multiply, and 1 mac without any conversions.
>
> the bit would be automatically set the moment the register
> is used as a destination. if used as a source and the bit
> is not set, an Illegal Instruction Trap can be raised, which
> would prevent the scenario where someone leaked data
> from a different security context.
<
When storing preserved (callee) registers you could set the tag
to empty, allowing it to be used as zero, but not allowing this
subroutine to see the value in the register it does not have
ownership of.
>
> last time i heard about tags was an obscure Texas Instruments
> DSP from the 90s. beyond that for some bizarre unfathomable
> reason the idea went completely out of fashion.
>
> l.

On Monday, May 22, 2023 at 1:04:05 PM UTC+1, Niklas Holsti wrote:

> The Mill tags ("operand metadata" in Mill terms) do not indicate the
> semantic type of the operand value, only its width in bits and whether
> it is a single (scalar) value or a vector (SIMD). The tags also flag
> various error conditions such as values that are not available for some
> reason.

ahh, thank you for correcting my memory-recall which is somewhat
akin to holographic storage.

On Monday, May 22, 2023 at 6:52:21 PM UTC+1, MitchAlsup wrote:

> It is not just the context, but now you are faced with needing even
> more memory reference instructions just to save and restore the
> registers and associated tags--when you don't know what value
> in in the tags !!??!!

which would tend to suggest that swapping at least one tag
of one register into context-aware state, and replacing it with
known-good state (uint/64-bit would do) would seem to be
a good idea. that one register is then in a fit state to be used
to perform bare-minimum operations such as save/restore
of other reg-tags.

in Power ISA, the two context-swapping SPRs are SRR0 and
SRR1. normally SRR0 contains the Program Counter and
SRR1 contains the MSR (Machine Status Register), so an
entire 8-bits of SRR1 have to be taken up to store the tag
of *one* general-purpose register, which is a hell of a lot.

therefore those 8-bits would have to be in MSR itself (then
copied to SRR1), which is also a hell of a lot.

l.

On Monday, May 22, 2023 at 12:52:21 PM UTC-5, MitchAlsup wrote:
> On Monday, May 22, 2023 at 5:44:37 AM UTC-5, luke.l...@gmail.com wrote:
> > On Friday, May 19, 2023 at 3:48:37 AM UTC+1, JimBrakefield wrote:
> > > Have a habit of running out of op-code space on new ISA designs.
> > >
> > > So, added a type tag to each register. I want four types: unsigned,
> > > signed, float and Posit. That and four data sizes requires 16
> > > distinct memory read instructions! But it ends there. Only
> > > four store instructions, one for each data size.
> <
> > ridiculous, isn't it? you'd think every RISC ISA would work that way.
> <
> What to leave in, what to leave out........
> <
> > you can also get away with a much shorter STORE instruction
> > because you simply take the tag's width.
> >
> > as Terje mentions, the Mill has had this solved since its inception.
> > the tag is carried from LOAD thru ARITH right to STORE, and copied
> > across to any reg-to-reg intermediates for further STORE.
> > there are "NARROW" and "WIDEN" instructions which change the
> > tag-type, there *may* be some "fp<->int" conversions that also
> > change the tag-type but apart from that it's all there is.
> >
> > so for example as hinted above if you really want a different
> > STORE width you perform a NARROW or WIDEN first. this you
> > will find greatly reduces Hazard complexity as it fire-breaks
> > the STORE Dependency Hazards (3-in 1-out) from the
> > 1-in 1-out needed for N/W.
> >
> > the problems come as you already suspected on context-switch
> > (including function calls). there you suddenly have not only
> > registers to save/restore but also their tags. 8-bit tags is
> > now 32 bytes of extra context, and with the tags being "bits"
> > your ISA had better have a damn good way to save/restore
> > individual bytes into tags.
> <
> It is not just the context, but now you are faced with needing even
> more memory reference instructions just to save and restore the
> registers and associated tags--when you don't know what value
> in in the tags !!??!!
> >
> > if you go for a separate "tag regfile" you need not poison the
> > ISA by reducing the bit-width of GPR/FPRs to something mad
> > like 24-bit instead of 32-bit. this then solves the issue of
> > SRAM allocation in FPGAs, they're allocated separately.
> >
> > one other nice thing to consider would be a "this register is in use"
> > tag-bit. if set to zero the contents of the register may be
> > assumed to be zero (or *actually* set to zero) and thus those bits
> > may be used as a Predicate Mask for Vector LOAD/STORE,
> > performing automatic VCOMPRESS and VEXPAND.
> <
> With an 8-bit tag, you could simply define rules and just have
> generic arithmetic that simply works::
> <
> i = f×d-f×l+u
> <
> Which would produce 1 multiply, and 1 mac without any conversions.
> >
> > the bit would be automatically set the moment the register
> > is used as a destination. if used as a source and the bit
> > is not set, an Illegal Instruction Trap can be raised, which
> > would prevent the scenario where someone leaked data
> > from a different security context.
> <
> When storing preserved (callee) registers you could set the tag
> to empty, allowing it to be used as zero, but not allowing this
> subroutine to see the value in the register it does not have
> ownership of.
> >
> > last time i heard about tags was an obscure Texas Instruments
> > DSP from the 90s. beyond that for some bizarre unfathomable
> > reason the idea went completely out of fashion.
> >
> > l.
|>
|>It is not just the context, but now you are faced with needing even
|>more memory reference instructions just to save and restore the
|>registers and associated tags--when you don't know what value
|>in in the tags !!??!!

Many/most RISC ISAs have bulk/multiple register save/restore instructions.
It is these instructions that would need to preserve register tags.
Will not claim to know how to do it for 32 & 64 bit registers?
Perhaps these instructions need to be privileged so as to prohibit tag modifications.
(particularly if "address" is a type tag?)
Unexpected type coercion traps would provide an additional protection against
mischievous actions between save and restore?

On Monday, May 22, 2023 at 11:32:48 PM UTC+1, JimBrakefield wrote:

> Many/most RISC ISAs have bulk/multiple register save/restore instructions..

hardware architects attempting to implement high-speed designs
tend to hate them. ARM retired the bulk/multiple save/restore
instructions in favour of a "save two at a time" instruction which
is way easier on Hazard Management and fits better with OoO
Micro-Architectures.

> It is these instructions that would need to preserve register tags.
> Will not claim to know how to do it for 32 & 64 bit registers?
> Perhaps these instructions need to be privileged so as to prohibit tag modifications.

no, just the "valid and in-use" bit. or, better: if userspace sets
it, the contents of the register are zero'd at the same time.

l.

On Monday, May 22, 2023 at 5:32:48 PM UTC-5, JimBrakefield wrote:
> On Monday, May 22, 2023 at 12:52:21 PM UTC-5, MitchAlsup wrote:
> > On Monday, May 22, 2023 at 5:44:37 AM UTC-5, luke.l...@gmail.com wrote:
> > > On Friday, May 19, 2023 at 3:48:37 AM UTC+1, JimBrakefield wrote:
> > > > Have a habit of running out of op-code space on new ISA designs.
> > > >
> > > > So, added a type tag to each register. I want four types: unsigned,
> > > > signed, float and Posit. That and four data sizes requires 16
> > > > distinct memory read instructions! But it ends there. Only
> > > > four store instructions, one for each data size.
> > <
> > > ridiculous, isn't it? you'd think every RISC ISA would work that way.
> > <
> > What to leave in, what to leave out........
> > <
> > > you can also get away with a much shorter STORE instruction
> > > because you simply take the tag's width.
> > >
> > > as Terje mentions, the Mill has had this solved since its inception.
> > > the tag is carried from LOAD thru ARITH right to STORE, and copied
> > > across to any reg-to-reg intermediates for further STORE.
> > > there are "NARROW" and "WIDEN" instructions which change the
> > > tag-type, there *may* be some "fp<->int" conversions that also
> > > change the tag-type but apart from that it's all there is.
> > >
> > > so for example as hinted above if you really want a different
> > > STORE width you perform a NARROW or WIDEN first. this you
> > > will find greatly reduces Hazard complexity as it fire-breaks
> > > the STORE Dependency Hazards (3-in 1-out) from the
> > > 1-in 1-out needed for N/W.
> > >
> > > the problems come as you already suspected on context-switch
> > > (including function calls). there you suddenly have not only
> > > registers to save/restore but also their tags. 8-bit tags is
> > > now 32 bytes of extra context, and with the tags being "bits"
> > > your ISA had better have a damn good way to save/restore
> > > individual bytes into tags.
> > <
> > It is not just the context, but now you are faced with needing even
> > more memory reference instructions just to save and restore the
> > registers and associated tags--when you don't know what value
> > in in the tags !!??!!
> > >
> > > if you go for a separate "tag regfile" you need not poison the
> > > ISA by reducing the bit-width of GPR/FPRs to something mad
> > > like 24-bit instead of 32-bit. this then solves the issue of
> > > SRAM allocation in FPGAs, they're allocated separately.
> > >
> > > one other nice thing to consider would be a "this register is in use"
> > > tag-bit. if set to zero the contents of the register may be
> > > assumed to be zero (or *actually* set to zero) and thus those bits
> > > may be used as a Predicate Mask for Vector LOAD/STORE,
> > > performing automatic VCOMPRESS and VEXPAND.
> > <
> > With an 8-bit tag, you could simply define rules and just have
> > generic arithmetic that simply works::
> > <
> > i = f×d-f×l+u
> > <
> > Which would produce 1 multiply, and 1 mac without any conversions.
> > >
> > > the bit would be automatically set the moment the register
> > > is used as a destination. if used as a source and the bit
> > > is not set, an Illegal Instruction Trap can be raised, which
> > > would prevent the scenario where someone leaked data
> > > from a different security context.
> > <
> > When storing preserved (callee) registers you could set the tag
> > to empty, allowing it to be used as zero, but not allowing this
> > subroutine to see the value in the register it does not have
> > ownership of.
> > >
> > > last time i heard about tags was an obscure Texas Instruments
> > > DSP from the 90s. beyond that for some bizarre unfathomable
> > > reason the idea went completely out of fashion.
> > >
> > > l.
> |>
> |>It is not just the context, but now you are faced with needing even
> |>more memory reference instructions just to save and restore the
> |>registers and associated tags--when you don't know what value
> |>in in the tags !!??!!
<
> Many/most RISC ISAs have bulk/multiple register save/restore instructions..
<
Where many/most does not include:: {MIPS, Mc 88K, SPARCV8 or V9, RISC-V}
<
> It is these instructions that would need to preserve register tags.
> Will not claim to know how to do it for 32 & 64 bit registers?
> Perhaps these instructions need to be privileged so as to prohibit tag modifications.
> (particularly if "address" is a type tag?)
> Unexpected type coercion traps would provide an additional protection against
> mischievous actions between save and restore?

On Monday, May 22, 2023 at 8:22:09 PM UTC-5, MitchAlsup wrote:
> On Monday, May 22, 2023 at 5:32:48 PM UTC-5, JimBrakefield wrote:
> > On Monday, May 22, 2023 at 12:52:21 PM UTC-5, MitchAlsup wrote:
> > > On Monday, May 22, 2023 at 5:44:37 AM UTC-5, luke.l...@gmail.com wrote:
> > > > On Friday, May 19, 2023 at 3:48:37 AM UTC+1, JimBrakefield wrote:
> > > > > Have a habit of running out of op-code space on new ISA designs.
> > > > >
> > > > > So, added a type tag to each register. I want four types: unsigned,
> > > > > signed, float and Posit. That and four data sizes requires 16
> > > > > distinct memory read instructions! But it ends there. Only
> > > > > four store instructions, one for each data size.
> > > <
> > > > ridiculous, isn't it? you'd think every RISC ISA would work that way.
> > > <
> > > What to leave in, what to leave out........
> > > <
> > > > you can also get away with a much shorter STORE instruction
> > > > because you simply take the tag's width.
> > > >
> > > > as Terje mentions, the Mill has had this solved since its inception..
> > > > the tag is carried from LOAD thru ARITH right to STORE, and copied
> > > > across to any reg-to-reg intermediates for further STORE.
> > > > there are "NARROW" and "WIDEN" instructions which change the
> > > > tag-type, there *may* be some "fp<->int" conversions that also
> > > > change the tag-type but apart from that it's all there is.
> > > >
> > > > so for example as hinted above if you really want a different
> > > > STORE width you perform a NARROW or WIDEN first. this you
> > > > will find greatly reduces Hazard complexity as it fire-breaks
> > > > the STORE Dependency Hazards (3-in 1-out) from the
> > > > 1-in 1-out needed for N/W.
> > > >
> > > > the problems come as you already suspected on context-switch
> > > > (including function calls). there you suddenly have not only
> > > > registers to save/restore but also their tags. 8-bit tags is
> > > > now 32 bytes of extra context, and with the tags being "bits"
> > > > your ISA had better have a damn good way to save/restore
> > > > individual bytes into tags.
> > > <
> > > It is not just the context, but now you are faced with needing even
> > > more memory reference instructions just to save and restore the
> > > registers and associated tags--when you don't know what value
> > > in in the tags !!??!!
> > > >
> > > > if you go for a separate "tag regfile" you need not poison the
> > > > ISA by reducing the bit-width of GPR/FPRs to something mad
> > > > like 24-bit instead of 32-bit. this then solves the issue of
> > > > SRAM allocation in FPGAs, they're allocated separately.
> > > >
> > > > one other nice thing to consider would be a "this register is in use"
> > > > tag-bit. if set to zero the contents of the register may be
> > > > assumed to be zero (or *actually* set to zero) and thus those bits
> > > > may be used as a Predicate Mask for Vector LOAD/STORE,
> > > > performing automatic VCOMPRESS and VEXPAND.
> > > <
> > > With an 8-bit tag, you could simply define rules and just have
> > > generic arithmetic that simply works::
> > > <
> > > i = f×d-f×l+u
> > > <
> > > Which would produce 1 multiply, and 1 mac without any conversions.
> > > >
> > > > the bit would be automatically set the moment the register
> > > > is used as a destination. if used as a source and the bit
> > > > is not set, an Illegal Instruction Trap can be raised, which
> > > > would prevent the scenario where someone leaked data
> > > > from a different security context.
> > > <
> > > When storing preserved (callee) registers you could set the tag
> > > to empty, allowing it to be used as zero, but not allowing this
> > > subroutine to see the value in the register it does not have
> > > ownership of.
> > > >
> > > > last time i heard about tags was an obscure Texas Instruments
> > > > DSP from the 90s. beyond that for some bizarre unfathomable
> > > > reason the idea went completely out of fashion.
> > > >
> > > > l.
> > |>
> > |>It is not just the context, but now you are faced with needing even
> > |>more memory reference instructions just to save and restore the
> > |>registers and associated tags--when you don't know what value
> > |>in in the tags !!??!!
> <
> > Many/most RISC ISAs have bulk/multiple register save/restore instructions.
> <
> Where many/most does not include:: {MIPS, Mc 88K, SPARCV8 or V9, RISC-V}
> <
> > It is these instructions that would need to preserve register tags.
> > Will not claim to know how to do it for 32 & 64 bit registers?
> > Perhaps these instructions need to be privileged so as to prohibit tag modifications.
> > (particularly if "address" is a type tag?)
> > Unexpected type coercion traps would provide an additional protection against
> > mischievous actions between save and restore?

|>> Where many/most does not include:: {MIPS, Mc 88K, SPARCV8 or V9, RISC-V}
Does include Power PC integer registers, M68000, AMD29000, SPARC call/return (eight registers implied), VAX (four registers at a time) and MY 66000?
Context switches (thread, process) not considered in the same class as load/store multiple?
Ugh, so off the hook on "many", definitely not "most", could say move multiple is common?

MitchAlsup <MitchAlsup@aol.com> writes:
>On Monday, May 22, 2023 at 5:32:48=E2=80=AFPM UTC-5, JimBrakefield wrote:
>> On Monday, May 22, 2023 at 12:52:21=E2=80=AFPM UTC-5, MitchAlsup wrote:=

>> Many/most RISC ISAs have bulk/multiple register save/restore instructions=
>.=20
><
>Where many/most does not include:: {MIPS, Mc 88K, SPARCV8 or V9, RISC-V}
><

ARMv8 only supports load pair and store pair. And when system
bus widths allow, LDP/SDP will use single-copy atomic 128-bit bus transactions
when loading or storing a pair of registers.

A new feature FEAT_LS64 provides two new instructions issue single-copy
atomic loads and stores of 64 bytes. These use 8 consecutive 64-bit
general purpose registers.

I don't believe any extant cores implement this feature yet. It's designed
to pass data to on-board coprocessors (like a hardware network stack).

MitchAlsup wrote:
> On Monday, May 22, 2023 at 5:44:37 AM UTC-5, luke.l...@gmail.com wrote:
[snip]
>> the problems come as you already suspected on context-switch
>> (including function calls). there you suddenly have not only
>> registers to save/restore but also their tags. 8-bit tags is
>> now 32 bytes of extra context, and with the tags being "bits"
>> your ISA had better have a damn good way to save/restore
>> individual bytes into tags.
>
> It is not just the context, but now you are faced with needing even
> more memory reference instructions just to save and restore the
> registers and associated tags--when you don't know what value
> in in the tags !!??!!

This assumes that the save/restore is done by instructions. For
context switching, My 66000 does this without instructions but
would still require special support for function interfaces (only
for caller-save registers? though architecting the ABI for that
case may be ill-advised).

The Mill saves the entire valid Belt on function calls without
special instructions. (The Mill requires additional instructions
for widening [and narrowing] when a traditional RISC automatically
widens on a load and truncates [possibly unsafely] on a store.)

Something like Itanium's Register Stack Engine combined with
hardware context switching might also avoid adding spill/fill
instructions that preserve the metadata.

I could also imagine a load multiple instruction that used a
register to provide the metadata and the store multiple
instruction that accumulated the metadata into a register that is
then stored (with an ordinary store instruction as its type is
known). If the ISA has a zero register, including the zero
register in the store list might save the metadata in the zero
register's spot.

Something like My 66000's ENTER/EXIT could probably be extended to
save the metadata.

I suspect there are other ways of avoiding more instructions if
that is seen as sufficiently important.

On Monday, May 22, 2023 at 9:14:43 PM UTC-5, JimBrakefield wrote:
> On Monday, May 22, 2023 at 8:22:09 PM UTC-5, MitchAlsup wrote:
> > On Monday, May 22, 2023 at 5:32:48 PM UTC-5, JimBrakefield wrote:
> > > Many/most RISC ISAs have bulk/multiple register save/restore instructions.
> > <
> > Where many/most does not include:: {MIPS, Mc 88K, SPARCV8 or V9, RISC-V}
> > <
> > > It is these instructions that would need to preserve register tags.
> > > Will not claim to know how to do it for 32 & 64 bit registers?
> > > Perhaps these instructions need to be privileged so as to prohibit tag modifications.
> > > (particularly if "address" is a type tag?)
> > > Unexpected type coercion traps would provide an additional protection against
> > > mischievous actions between save and restore?
>
> |>> Where many/most does not include:: {MIPS, Mc 88K, SPARCV8 or V9, RISC-V}
> Does include Power PC integer registers, M68000, AMD29000, SPARC call/return (eight registers implied), VAX (four registers at a time) and MY 66000?
68K is not RISC,
SPARC call/ret did not HAVE to ST/LD registers,
My 66000 is arguable as to whether it is a RISC--granted it is near RISC--but is it really--
Well in the context of actually having a Reduced ISA, it is, in what is in that ISA; maybe not.
<
> Context switches (thread, process) not considered in the same class as load/store multiple?
<
No not really, you are manipulating not only register files, but thread and system queues,
manipulating control registers in 2 states, All at once.
<
LDM/STM are purely reg<->mem.
<
> Ugh, so off the hook on "many", definitely not "most", could say move multiple is common?
<
If you count the number of RISC chips selling more than 1,000,000 per month,
then the distinction is moot anyway.

On Monday, May 22, 2023 at 9:43:22 PM UTC-5, Paul A. Clayton wrote:
> MitchAlsup wrote:
> > On Monday, May 22, 2023 at 5:44:37 AM UTC-5, luke.l...@gmail.com wrote:
> [snip]
> >> the problems come as you already suspected on context-switch
> >> (including function calls). there you suddenly have not only
> >> registers to save/restore but also their tags. 8-bit tags is
> >> now 32 bytes of extra context, and with the tags being "bits"
> >> your ISA had better have a damn good way to save/restore
> >> individual bytes into tags.
> >
> > It is not just the context, but now you are faced with needing even
> > more memory reference instructions just to save and restore the
> > registers and associated tags--when you don't know what value
> > in in the tags !!??!!
<
> This assumes that the save/restore is done by instructions. For
> context switching, My 66000 does this without instructions but
> would still require special support for function interfaces (only
> for caller-save registers? though architecting the ABI for that
> case may be ill-advised).
<
Doing it without instructions is how it gets done transparently.
Doing it without instructions is how you get shot down in flames, too.
>
> The Mill saves the entire valid Belt on function calls without
> special instructions. (The Mill requires additional instructions
> for widening [and narrowing] when a traditional RISC automatically
> widens on a load and truncates [possibly unsafely] on a store.)
>
> Something like Itanium's Register Stack Engine combined with
> hardware context switching might also avoid adding spill/fill
> instructions that preserve the metadata.
>
> I could also imagine a load multiple instruction that used a
> register to provide the metadata and the store multiple
> instruction that accumulated the metadata into a register that is
> then stored (with an ordinary store instruction as its type is
> known). If the ISA has a zero register, including the zero
> register in the store list might save the metadata in the zero
> register's spot.
>
> Something like My 66000's ENTER/EXIT could probably be extended to
> save the metadata.
<
No extension needed. ENTER and EXIT do not expose the saved
register data (locations, fomats,...) to software (when SafeStack
is in use.)
>
> I suspect there are other ways of avoiding more instructions if
> that is seen as sufficiently important.

On Tuesday, May 23, 2023 at 3:14:43 AM UTC+1, JimBrakefield wrote:

> Does include Power PC [...]

[minor niggle for future reference: "PowerPC(tm)" was a joint initiative between
IBM, Motorola, Apple and I think Sony(?), i am still learning the details but you
likely meant to use "Power ISA" here not "Power PC". the "Power PC" initiative
ended around 15 years ago. Power ISA - the instruction set *behind* the "Power PC"
initiative - is very much still active.]
> Ugh, so off the hook on "many", definitely not "most", could say move multiple is common?

even the SVP64 Extension for Power ISA can only handle up to 127 (registers)
VCOMPRESS/VEXPAND operations and only then by using CR Fields as Predicate
Masks, and that's pushing your luck. 64 would be safer then an INT can
be used as the Predicate Mask. bear in mind that there are 128 GPRs 128 FPRs
128 CR Fields all of which need context-switching so two instructions each
(1: 0-63, 2: 64-127) is still "many".

(127 is down to a limitation of 7 bits for element-offsets)

----------------------

On Tuesday, May 23, 2023 at 3:33:49 AM UTC+1, Scott Lurndal wrote:

> ARMv8 only supports load pair and store pair.

that's the ones i referred to, yes. LD/ST-multi being deprecated.

> A new feature FEAT_LS64 provides two new instructions issue single-copy
> atomic loads and stores of 64 bytes. These use 8 consecutive 64-bit
> general purpose registers.

sigh just when one Hardware Engineer says "oh god no please no
more LD/ST-Multi", another Hardware Engineer says "oh god yes,
please we need LD/ST-Multi"?

a case of left hand not knowing what the right hand did?

-----------------------

On Monday, May 22, 2023 at 6:52:21 PM UTC+1, MitchAlsup wrote:

> With an 8-bit tag, you could simply define rules and just have
> generic arithmetic that simply works::
> i = f×d-f×l+u
> Which would produce 1 multiply, and 1 mac without any conversions.

hang on hang on... this flew by so my brain is catching up. are you
suggesting that by implicit-zeroing it becomes possible to use a
single pipeline that basically does everything? "mul-add, mul-sub,
mul, add, sub" - all in one?

if like in Microwatt (which does micro-coding mentioned last week)
including Carry-in / 0 / 1 as an additional option:

c = runtime-selected Carry-in, 0 or 1
i = f×d-f×l+u + c

then that would be pretty neat. question: would it introduce latency?
how many cycles to complete, compared to a "vanilla" add pipeline?

l.

On 2023-05-23 5:14, JimBrakefield wrote:
> On Monday, May 22, 2023 at 8:22:09 PM UTC-5, MitchAlsup wrote:
>> On Monday, May 22, 2023 at 5:32:48 PM UTC-5, JimBrakefield wrote:

[...]

>>> Many/most RISC ISAs have bulk/multiple register save/restore instructions.
>> <
>> Where many/most does not include:: {MIPS, Mc 88K, SPARCV8 or V9, RISC-V}

[...]

> Does include Power PC integer registers, M68000, AMD29000, SPARC
> call/return (eight registers implied), [...]

SPARC call/return do not save multiple registers. You are probably
thinking of the SAVE and RESTORE instructions which rotate the register
ring, but do not perform any reads or writes to memory, unless the
register ring overflows or underflows in which case there is a trap to a
handler that does read or write memory, but not with multiple-register
operations.

SAVE and RESTORE in SPARC are a form of program-controlled register
renaming. They change the mapping of the ISA register numbers to the HW
registers in the register ring.

Granted, SAVE/RESTORE are often used in conjunction with call/return,
but can also be omitted in some cases (say, when calling a leaf routine
that does not need a frame pointer).

On Monday, May 22, 2023 at 10:21:00 PM UTC-5, luke.l...@gmail.com wrote:

> -----------------------
> On Monday, May 22, 2023 at 6:52:21 PM UTC+1, MitchAlsup wrote:
> > With an 8-bit tag, you could simply define rules and just have
> > generic arithmetic that simply works::
> > i = f×d-f×l+u
> > Which would produce 1 multiply, and 1 mac without any conversions.
<
> hang on hang on... this flew by so my brain is catching up. are you
> suggesting that by implicit-zeroing it becomes possible to use a
> single pipeline that basically does everything? "mul-add, mul-sub,
> mul, add, sub" - all in one?
<
I am suggesting that once you tag registers with the data-type,
you are in a position to build calculation units that can perform
cross-type calculations.
>
> if like in Microwatt (which does micro-coding mentioned last week)
> including Carry-in / 0 / 1 as an additional option:
>
> c = runtime-selected Carry-in, 0 or 1
> i = f×d-f×l+u + c
>
> then that would be pretty neat. question: would it introduce latency?
<
Probably, but not much. And you can avoid numeric problems along
the way. For example, say we have an integer with significance bigger
than 1<<52. When converted to FP64 it will get rounded, but when
auto-converted with tagged-registers it does NOT have to be rounded--
it can be used directly with more significance than fits in FP64 !!
<
> how many cycles to complete, compared to a "vanilla" add pipeline?
<
probably 1 cycle.
>
> l.

"luke.l...@gmail.com" <luke.leighton@gmail.com> writes:
>On Tuesday, May 23, 2023 at 3:14:43=E2=80=AFAM UTC+1, JimBrakefield wrote:
>
>> Does include Power PC [...]
>

>> A new feature FEAT_LS64 provides two new instructions issue single-copy=
>=20
>> atomic loads and stores of 64 bytes. These use 8 consecutive 64-bit=20
>> general purpose registers.=20
>
>sigh just when one Hardware Engineer says "oh god no please no
>more LD/ST-Multi", another Hardware Engineer says "oh god yes,
>please we need LD/ST-Multi"?
>
>a case of left hand not knowing what the right hand did?

In this case, the assumption is that an implementation of FEAT_LS64 will have
a 512-bit-wide bus from the processor to the coprocessor
and the transfer will be a single bus transaction.

On Tuesday, May 23, 2023 at 9:31:25 AM UTC-5, Scott Lurndal wrote:
> "luke.l...@gmail.com" <luke.l...@gmail.com> writes:
> >On Tuesday, May 23, 2023 at 3:14:43=E2=80=AFAM UTC+1, JimBrakefield wrote:
> >
> >> Does include Power PC [...]
> >
> >> A new feature FEAT_LS64 provides two new instructions issue single-copy=
> >=20
> >> atomic loads and stores of 64 bytes. These use 8 consecutive 64-bit=20
> >> general purpose registers.=20
> >
> >sigh just when one Hardware Engineer says "oh god no please no
> >more LD/ST-Multi", another Hardware Engineer says "oh god yes,
> >please we need LD/ST-Multi"?
> >
> >a case of left hand not knowing what the right hand did?
<
> In this case, the assumption is that an implementation of FEAT_LS64 will have
> a 512-bit-wide bus from the processor to the coprocessor
> and the transfer will be a single bus transaction.
<
Technology is at the point where 512-bit wide bus (line size) should be standard.
Then bus transactions are single beat--which makes the protocol(s) easier.
<
As to the assertion that LDM/STM are "hard" on the renamer--I found that a
simple mask addition at the renamer is adequate for dealing with all the
standard call/return interlocking.

MitchAlsup <MitchAlsup@aol.com> schrieb:

> Probably, but not much. And you can avoid numeric problems along
> the way. For example, say we have an integer with significance bigger
> than 1<<52. When converted to FP64 it will get rounded, but when
> auto-converted with tagged-registers it does NOT have to be rounded--
> it can be used directly with more significance than fits in FP64 !!

While true, this would go against the rules of many, if not all
programming langues. These prescribe conversion of integer to
floating point before doing a calculation with a floating point.

On Sunday, May 28, 2023 at 3:35:20 PM UTC+1, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > Probably, but not much. And you can avoid numeric problems along
> > the way. For example, say we have an integer with significance bigger
> > than 1<<52. When converted to FP64 it will get rounded, but when
> > auto-converted with tagged-registers it does NOT have to be rounded--
> > it can be used directly with more significance than fits in FP64 !!
> While true, this would go against the rules of many, if not all
> programming langues. These prescribe conversion of integer to
> floating point before doing a calculation with a floating point.

also stops you from being able to service an Interrupt during
the time that the instruction is issued until there is no longer
a time it could be used. as that could be tens of millions of
instructions later, you are hosed.

* reg1: 9999<<52 (int)
* instruction issued reg2 = BIGINT_to_FP64(reg1)
* instruction(s) issued: reg3 = reg2 * 2.5
* ...
* ...
* millions more instructions none overwritign reg2
* another use of reg2: reg4 = reg2 + 0.0000001

if reg2 is *NOT* exactly the same accuracy as what
went into reg3 and reg4, where are the extraneous bits
stored during the millions of instructions executed?

the only possibility would be an overwrite macro-op
fusion:

reg2 = BIGINT_to_FP64(reg1)
reg2 = reg2 * 2.5

and then it becomes vital to not allow interrupts
between those two instructions, you also just made
a mess of Multi-Issue Decode (because that's now
a double-normal-length *ACTUAL* instruction and
you just unintentionally introduced Variable-Length
Encoding by the back door), and generally gotten
into ISA hell from that point onward.

sounds as Mitch suggests much better to do what
everyone else does.

l.

On 5/28/2023 9:33 AM, Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>
>> Probably, but not much. And you can avoid numeric problems along
>> the way. For example, say we have an integer with significance bigger
>> than 1<<52. When converted to FP64 it will get rounded, but when
>> auto-converted with tagged-registers it does NOT have to be rounded--
>> it can be used directly with more significance than fits in FP64 !!
>
> While true, this would go against the rules of many, if not all
> programming langues. These prescribe conversion of integer to
> floating point before doing a calculation with a floating point.

Agreed.

Also it seems like it could lead to problems.

What if an interrupt happens, does the precision of the calculation
depend on the presence or absence of an interrupt?... Or, does the ISR
now need to save and restore, say, 96-bit registers? ...

For many problems, it seems more like repeatability matters more than
absolute precision. Say, that the same calculation with the same inputs
always produces the same result, even if this answer is "wrong" in a
more strict interpretation.

Say, with the amount of "implicit" architectural state being kept to a
minimum.

Ironically, in my case this led to things like emulator fun of needing
to fake my CPU's arguably "bad" handling of floating-point in some
cases, rather than using the "better" native FPU operations, since this
led to behavioral divergence in some cases.

Kinda similar ends up applying to things like RGB555 or block-texture
decoding, where the "bad" definitions often end up being preferable to
the "better" definitions for one reason or another.

....