On 9/16/23 8:47 AM, Thomas Koenig wrote:
> luke.l...@gmail.com <luke.leighton@gmail.com> schrieb:
>
>> i am always slightly dismayed by the continuous assumption that
>> an ISA's front-end *must* have a direct one-to-one relationship
>> with the back-end implementation.
>
> Many architectures have violated that assumption in the past. A few
> examples off the top of my head:
>
> The /360 series, where a 32-bit architecture was implemented in,
> for example, 8 bits on the model 30.
>
> The original Nova, which implemented its 16-bit architecture with
> a 4-bit ALU. Later models went to full 16 bits.
>
> The Z80, which hides its 4-bit ALU behind an 8-bit external
> appearance and sequencing. (How that saves chip area I'm
> not sure).
>
> The PDP 8/S had a single-bit width ALU with a 12-bit architecture.
>
> The 68000 was actually advertised as a 16-bit processor, but
> had an ISA geared towards 32 bit right from the start.

Add the CDP1802 1 bit ALU to your list.

--
http://davesrocketworks.com
David Schultz

In article <udickr$5rc3$1@dont-email.me>, cr88192@gmail.com (BGB) wrote:

> I have noted that the ability to turn the "social behaviors" on and
> off, or "do a full 180", in terms of emotional sentiment, without
> any visible delay, is not something that neurotypicals seem able to
> do. Like, even when given permission to do so, and where the most
> sensible option would be turn off the social conventions and
> speak/act using a direct/impersonal style, they will not (and are
> seemingly mostly incapable of doing so).

I'm not sure I'm entirely neurotypical, but I learned to do this
relatively easily when it became obvious that it was the best way to run
collaboration meetings between groups of software developers.

I think of it as "Turning my ego off" and gain considerable satisfaction
from getting people to do sensible things when their egos tell them to do
otherwise.

John

On 9/16/2023 6:55 AM, luke.l...@gmail.com wrote:
> On Saturday, September 9, 2023 at 7:13:51 PM UTC+1, BGB wrote:
>
>> I have noted that the ability to turn the "social behaviors" on and off,
>> or "do a full 180", in terms of emotional sentiment, without any visible
>> delay, is not something that neurotypicals seem able to do. Like, even
>> when given permission to do so, and where the most sensible option would
>> be turn off the social conventions and speak/act using a
>> direct/impersonal style, they will not (and are seemingly mostly
>> incapable of doing so).
>
> this is down to training. if you find an easy way to make
> this happen congratulations you just made a fortune in
> "Goal-orientated Team Building" for businesses... :)
>

Both myself and the female I was talking to seem capable of doing this.
But, if one does this around other people, many neurotypicals seem to
freak out.

A case came up where she did this in a public setting, going somewhat
outside the scope of neurotypical social behavior, and causing
shock/surprise to bystanders. As I saw it, what she said was justified.
Still might have been better though (partly for her sake) if in the
moment she had "kept the mask on" a little better.

Elsewhere, probably would have been fine (and most ASD behaviors are
passable), but when NTs are around, at least in my experience, better to
try to avoid challenging their expectations for how emotions and
emotional responses work.

In her case though, she does also seem to come off as likely autistic,
though some other things (like how she relates to emotions are less
obvious).

Admittedly, the one female I had once dated (very long ago) also tended
to do this (in a sometimes more overt form), but was also a lot more
consistent about never "unmasking" in this way whenever anyone else was
around (actually, she would visibly change her expression and some
aspects of her persona depending on whoever was around).

But, her abilities in this area were a fair bit more dynamic than my
own. But, she really didn't like being talked about, or having any
attention brought to this (if she would flip personas and I was around,
I was just sort of supposed to go along like this is how she always
was). This seemed to be one of these areas where, if one went against
her (even subtly), she would get particularly angry about it (not
necessarily at the moment; as she would keep the persona, but once no
one else was around; one would be hearing about it, ...).

The changes were unlike the level of variation typically seen in
neurotypicals, where the variation is more subtle and usually has a
noticeable time delay; and, they pretty much never switch to a fully
detached/impersonal style. Well, and also tend not to openly talk about
other people in terms of their usefulness, or what they want to get from
the other person, or other similar metrics.

Well, and in this case, seeming the whole relationship was based on me
"remaining useful" (with her general mindset being that it wasn't going
to go any further than this, with a set of ending criteria that were
mentioned well in advance; effectively a preset expiration date, ...).
Once this time rolled around, she ended things.

Some of this was admittedly, difficult for me to deal with at the time
in an emotional sense. I had the fault of caring for her and wishing
that things could continue or maybe go further, but this was one of
those things, that if one brought up, she would respond with anger.

....

The person I was talking to recently doesn't seem quite the same.
Seemingly less dynamic (more like myself).
Seems to have more visible signs of social anxiety.
My attempts to probe for "utility oriented thinking" in relation to
interactions with others, appear to have mostly come up negative (her
responses seem to be indifferent on this matter).
Seems to have vocal inflections more typical for people with ASD (or,
more generally, associated with "nerdy" people in general);
....

> you may find this interesting
> https://www.youtube.com/watch?v=Grrbekq-6kw
>

I don't really think a lot of this is a dietary issue.

> l.

On 9/16/2023 7:06 AM, luke.l...@gmail.com wrote:
> On Sunday, September 10, 2023 at 4:12:25 PM UTC+1, BGB wrote:
>
>> Sadly, these don't really do anything for matrix-multiply, there isn't
>> really any good way to deal with making MatMult not suck (in these
>> contexts, one usually dealing with 4x4 Binary32 matrices).
>
> 3 instructions in SVP64, any arbitrary matrix dimensions up
> to a total of 127 MACs/FMACs/GFMACs/any-scalar-op
>
> * first to set up matrix multiply REMAP
> * second to say which registers the REMAP applies to
> * third is the something-and-accumulate scalar operation
>
> real simple.
>
> it becomes the hardware's problem to then sort out the resultant
> massive-inrush of operations caused by the REMAP loop, hiding
> the end-developer from the insanity normally imposed on them
> by SIMD (and even True-Scalable) Vector ISAs.
>
> i am always slightly dismayed by the continuous assumption that
> an ISA's front-end *must* have a direct one-to-one relationship
> with the back-end implementation. "oh we have a SIMD ISA
> therefore the back-end hardware MUST have SIMD ALUs of
> exactly that width" errr no - look at the Broadcom Videocore IV
> "Virtual Vectors", the user *thinks* they are doing 16 FMACs
> in parallel whereas in reality the hardware breaks them down
> into 4 batches of 4 pipelined FMACs... *without* telling the
> user that that's what it's doing.
>

In my BJX2 core, in the original implementation of the floating-point
SIMD ops, they were implemented by multiplexing a 1-wide floating-point
unit over the 4 elements (with around a 6-cycle latency for the main FPU).

The low-precision FPU is 1:1, but this was mostly to reduce the SIMD op
latency from 10C to 3L/1T.

Or, say:
Scalar Op:
A - - - - A'
SIMD op (4-element A/B/C/D):
A - - - - A'
B - - - - B'
C - - - - C'
D - - - - D'
- - - - - - - - - {A/B/C/D}'

A drawback of MatMult though is that the elements in one matrix are
rotated by 90 degrees from the other matrix, so one effectively needs to
rotate one of the matrices by 90 degrees before being able to pipe it
though the other SIMD ops.

I have instructions to build new registers by pulling elements from the
other registers, but it could be better if this step were not necessary.
MOVLLD Rm, Ro, Rn // Rn = { Rm[31: 0], Ro[31: 0] }
MOVLHD Rm, Ro, Rn // Rn = { Rm[31: 0], Ro[63:32] }
MOVHLD Rm, Ro, Rn // Rn = { Rm[63:32], Ro[31: 0] }
MOVHHD Rm, Ro, Rn // Rn = { Rm[63:32], Ro[63:32] }
These ops being valid in all 3 lanes and may be co-issued in any
combination.

Though, I guess, if one had 512 bit vectors, and a 512-bit shuffle, it
could be possible handle all of this as a single instruction.

As-is though, I don't have enough register ports to get anywhere near
pulling this off.

> AMD's AVX512 implementation uses Cray-style "Vector Chaining"
> which amazingly is the first time i'd heard of it being admitted
> to be used by a mainstream CPU manufacturer (there are likely
> others that *don't* admit they copied Vector Chaining in their
> SIMD ALU implementations)
>
> Agner, you also made this assumption and I am waiting to hear back
> from you to continue the conversation on that, if you are interested?
>
> l.

On Sunday, September 17, 2023 at 3:28:42 AM UTC+1, BGB wrote:
> A drawback of MatMult though is that the elements in one matrix are
> rotated by 90 degrees from the other matrix, so one effectively needs to
> rotate one of the matrices by 90 degrees before being able to pipe it
> though the other SIMD ops.

indeed. and there are two ways to do it:
1. hard-wire the ISA to the back-end and have the developer
write instructions that perform the transform
2. have the hardware be instructed to sort out the transform itself.

you chose 1, i chose 2.

> I have instructions to build new registers by pulling elements from the
> other registers, but it could be better if this step were not necessary.

indeed.
> MOVLLD Rm, Ro, Rn // Rn = { Rm[31: 0], Ro[31: 0] }
> MOVLHD Rm, Ro, Rn // Rn = { Rm[31: 0], Ro[63:32] }
> MOVHLD Rm, Ro, Rn // Rn = { Rm[63:32], Ro[31: 0] }
> MOVHHD Rm, Ro, Rn // Rn = { Rm[63:32], Ro[63:32] }

and when you want a FP16 or INT16 MM this pattern
is no longer valid, the programmer is forced to rewrite
a new pattern of transforms.

> These ops being valid in all 3 lanes and may be co-issued in any
> combination.

if you have the hardware implemented why not separate the ISA
from that back-end hardware?

the trick of SVP64 is that it is not a Vector system at all,
but a looping system between Decode and Issue, spamming
back-end Multi-Issue with patterns that in a non-looping
system would require explicit loop-unrolled instructions.

thus if doing 4x4 32-bit matmul on a 32-bit regfile it is
*literally* as if you had 64 FMACs loop-unrolled, how hard is that?

and if you have 4-wide Multi-Issue, and the pipelines are 4 clocks
then as long as you have done an Inner Product you get 100%
throughput.

the clever bit - the silly-simple bit - is when doing 4x4 32-bit on
*64* bit regs.

well... um... all you do is, you treat the 64-bit regs as if they were a
pair of 32-bit regs. all 64-bit scalar ops are now *pair* reg ops,
but when you want to do 4x4 32-bit matmult you issue down to
the individual 32-bit regs.

it's not difficult.

> Though, I guess, if one had 512 bit vectors, and a 512-bit shuffle, it
> could be possible handle all of this as a single instruction.

and when the matrix is large enough to not fit?
> As-is though, I don't have enough register ports to get anywhere near
> pulling this off.

that's ok, you can multiplex (a PriorityPicker on the front)

l.

John Dallman wrote:
> In article <udickr$5rc3$1@dont-email.me>, cr88192@gmail.com (BGB) wrote:
>
>> I have noted that the ability to turn the "social behaviors" on and
>> off, or "do a full 180", in terms of emotional sentiment, without
>> any visible delay, is not something that neurotypicals seem able to
>> do. Like, even when given permission to do so, and where the most
>> sensible option would be turn off the social conventions and
>> speak/act using a direct/impersonal style, they will not (and are
>> seemingly mostly incapable of doing so).
>
> I'm not sure I'm entirely neurotypical, but I learned to do this
> relatively easily when it became obvious that it was the best way to run
> collaboration meetings between groups of software developers.
>
> I think of it as "Turning my ego off" and gain considerable satisfaction
> from getting people to do sensible things when their egos tell them to do
> otherwise.

The extreme version of this is something my father was a master of: He
would come into a big meeting with everyone from the shop floor unions
to division directors and know pretty well what the best solution would
be, but never, ever mention it directly. Instead he would try to look
at the alternatives, on all sides, and discuss some failure points for
each. The best outcome of this was for someone supposedly "on the other
side of the table", like a union leader, to discover/suggest the very
idea he had in mind! At that point he would do an "Oh, is that possible?
Sounds interesting..." and go on to "discover" possible
drawbacks/problems and how to handle them, ending up with praising the
union leader for finding the best solution to the current issue.

"There is no limit to what you can achieve if you are always willing to
let someone else take credit for it."

Terje

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

David Schultz wrote:
> On 9/16/23 8:47 AM, Thomas Koenig wrote:
>> luke.l...@gmail.com <luke.leighton@gmail.com> schrieb:
>>
>>> i am always slightly dismayed by the continuous assumption that
>>> an ISA's front-end *must* have a direct one-to-one relationship
>>> with the back-end implementation.
>>
>> Many architectures have violated that assumption in the past. A few
>> examples off the top of my head:
>>
>> The /360 series, where a 32-bit architecture was implemented in,
>> for example, 8 bits on the model 30.
>>
>> The original Nova, which implemented its 16-bit architecture with
>> a 4-bit ALU. Later models went to full 16 bits.
>>
>> The Z80, which hides its 4-bit ALU behind an 8-bit external
>> appearance and sequencing. (How that saves chip area I'm
>> not sure).
>>
>> The PDP 8/S had a single-bit width ALU with a 12-bit architecture.
>>
>> The 68000 was actually advertised as a 16-bit processor, but
>> had an ISA geared towards 32 bit right from the start.
>
> Add the CDP1802 1 bit ALU to your list.

Was that you who did the reverse engineering on the 1802's control
and data path logic?

I'd forgotten about that 1-bit ALU.
That was one weirdness amongst all its other weirdness.
Like no instructions for calling subroutines, and that whole approach
of the P register for choosing a program counter register.

It has an 8-bit parallel ripple carry incrementer/decrementer
but then switches to bit serial for the ALU.

Perhaps some of this came about because the original COSMAC was a
2 chip set so they had to divvy up the register set and control logic.
Then when they merged the two chips to one maybe some of the original
design decisions were carried over to the new chip.

Sometimes I play around with different 8-bit ISA designs that might have
been possible with the same 5500 CMOS transistor budget as the 1802,
and using static control logic and Johnson counter sequencer,
but with nicer programming characteristics like a Branch And Link
instruction. I would reduce the register set from 16 to 8 16-bit registers
and use the freed up gates for an 8-bit ALU and add some addressing modes.

On 9/17/2023 7:32 AM, Terje Mathisen wrote:
> John Dallman wrote:
>> In article <udickr$5rc3$1@dont-email.me>, cr88192@gmail.com (BGB) wrote:
>>
>>> I have noted that the ability to turn the "social behaviors" on and
>>> off, or "do a full 180", in terms of emotional sentiment, without
>>> any visible delay, is not something that neurotypicals seem able to
>>> do. Like, even when given permission to do so, and where the most
>>> sensible option would be turn off the social conventions and
>>> speak/act using a direct/impersonal style, they will not (and are
>>> seemingly mostly incapable of doing so).
>>
>> I'm not sure I'm entirely neurotypical, but I learned to do this
>> relatively easily when it became obvious that it was the best way to run
>> collaboration meetings between groups of software developers.
>>
>> I think of it as "Turning my ego off" and gain considerable satisfaction
>> from getting people to do sensible things when their egos tell them to do
>> otherwise.
>
> The extreme version of this is something my father was a master of: He
> would come into a big meeting with everyone from the shop floor unions
> to division directors and know pretty well what the best solution would
> be, but never, ever  mention it directly. Instead he would try to look
> at the alternatives, on all sides, and discuss some failure points for
> each. The best outcome of this was for someone supposedly "on the other
> side of the table", like a union leader, to discover/suggest the very
> idea he had in mind! At that point he would do an "Oh, is that possible?
> Sounds interesting..." and go on to "discover" possible
> drawbacks/problems and how to handle them, ending up with praising the
> union leader for finding the best solution to the current issue.
>
> "There is no limit to what you can achieve if you are always willing to
> let someone else take credit for it."
>

Interesting, though doesn't really seem like the same thing I was
thinking about here. I don't really feel inclined to go into the
specifics of the context at the moment.

More sort of like, in the case where one can switch to talking about
ones' interactions with the other person more like if they were a
disinterested 3rd party observer. Stating the situation in a "matter of
fact" style (without relying on emotional sentiment or other things).
Say, each person trying to make a case for what is most likely in the
best interest for each person involved in the interaction.

But, say, applied to scenarios like whether or not a relationship would
be sensible between two people, etc. Each person taking a role almost
as-if they were debating the pros/cons of a character-ship in a TV show.
(except, the two people just so happen to be the characters they are
debating about).

Note that one does not necessarily take a 3rd person perspective in this
case (if it were TV writing, this is usually where people would start
describing themselves in 3rd person terms; but in this case it is not
how it works in this case, as both parties still understand how pronouns
work...).

Now, say, this gets dropped in the middle of an otherwise casual
interaction in a public setting.

But, yeah, from what I can see, this sort of interaction style falls
outside the scope of normal neurotypical social interactions.

Also, I suspect a lot of people trying to write TV scripts don't
understand it either, either not using it in cases where it seemed like
it would be sensible to do so. Or, in the rare case they make an
attempt, they screw it up (either by having the person describe
themselves in the 3rd person, unnecessary levels of emotional sentiment,
or each person only arguing only from their own perspective or wants, ...).

Then again, the way TV would normally deal with these scenarios would be
to have the characters having dramatic displays of emotion and/or
yelling or similar.

Then again, the person I was interacting with shows some weaknesses in
this area (flip-flops between this and more NT-like patterns, not making
particularly effective use of this, nor making particularly effective
use of social context in the choice of interaction strategy; often
doesn't describe stuff in sufficient detail; doesn't really seem to
assume a neutral position; etc).

I suspect she has an issue with anxiety, and is possibly letting this
bleed over into her thinking (rather than, say, evaluating her position
in terms of best-interest or cost/benefit). Though, I will not fault her
for this, but it doesn't necessarily lead to an optimal outcome. Though,
in this case, has a relatively low probability of changing the answer.

Then again, can't ask for too much here.

I suspect she may be a little closer to normal than I am in these areas.

Then again, on the other side of things, someone going around and
basically using social patterns as tools to leverage what they want out
of people (*), is not ideal either, and would itself be cause for concern.

*: Say, a person that can be calm and neutral one moment, walk up to
someone on the street and put on a sad story about how something bad has
happened and they need some money to deal with it, then the person in
question gives them some money, and as soon as they leave, the person
switches back to a calm and neutral disposition (then using the money to
buy snacks at a convenience store or similar). (Well, as another person
in the mix, they need to keep quiet and play along, since if the first
persons' cover is blown, no money, no snacks, and then both people will
be angry, ...).

Where, say, one can note that this is not ideal due to being dishonest,
and it was not in the best interest of the random person on the street
to have had their money taken to buy snacks (well, along with it being
an indirect violation of the 7th commandment, etc).

....

somewhere in this thread a couple weeks back i mentioned
about the "overloading" of opcodes being disastrous for
forwards-compatibility (i mention "forwards" specifically because
ForwardCom is that), but that also there is the hobson's
choice of adding literal-duplicates of opcodes resulting in
the exact same concept behind "SIMD considered harmful"
also doing the exact same damage not just to a SIMD ISA
but to a True-Scalable Vector ISA (such as ForwardCom,
MRISC32, RVV) and it turns out *even to a Scalar ISA*.

for a Scalar ISA it is "not so bad", you may only have to add
say 20-50 duplicate integer arithmetic operations (duplicating
the 32-bit ISA, adding 64-bit equivalents), duplicating say
70 or so FP32 operations and making FP64 variants, *and*
remembering also to add converters between the same.

Scalar Power ISA made the mistake of overloading the 32-bit
integer opcodes with 64-bit meanings, in a rushed-upgrade
about 20 years ago that they weren't really ready for. they *did*
however make a fantastic decision to support FP32 format
*in the exact same form as FP64* such that you *do not* have
to do "conversion" between double and single operations.
all unused bits when storing FP32 in FP64 form are zero:
the only "conversion" needed is on non-normalised operations
when you load the FP32, and luckily that's possible to do
without needing to raise any Exceptions.

Mitch's 66000 ISA helps reduce some of the conversion
proliferation (transfer between GPR and FPR) by having
just the one 64-entry regfile. RISC-V and other RISC ISAs
have a 2-bit dedicated field for specifying the bit-width
of the FP operation (FP16 FP32 FP64 FP80/128)

but i digress, despite this being important context outlining
that the problem of opcode proliferation is not limited to
Vector ISAs.

how do you reduce that opcode proliferation? how do you
not end up dedicating 2 critical bits to the width of operations
(like RISC-V) where you are already under pressure (say with
16-bit Compressed), especially when (say) you want source
*and* destination width-specifiers?

there are a few solutions i have encountered (i would be
interested to hear of more)

* "tagged" registers. ForwardCom actually has tags already
(the vector length of each vector register is a "tag" in the
register itself. why not also include the element width?)
* "Control Status Registers". Power ISA has "bit-accuracy"
CSR bits, already, where if you want all FP operations to
be reduced accuracy (faster speed) you are permitted to
do so. there is nothing to stop you using a couple of bits
of CSR to specify "all integer operations normally marked
as 64-bit are now actually 32-bit" (and vice-versa)
* "Prefixing". a RISC-uniform Prefix instruction (similar to
ARM SVE MOVPRFX) may specify "the following instruction's
source (and destination) registers are NN-bit wide"

there's a few more out there: they all have advantages and
disadvantages, but at least they do not poison the core of
the ISA with massive opcode proliferation.

fascinatingly, though, they *do* still impact the Decoder Phase
to some extent, i'd be interested to hear peoples' thoughts on
how to overcome some of those problems.

l.

On 9/21/2023 3:45 AM, luke.l...@gmail.com wrote:
> somewhere in this thread a couple weeks back i mentioned
> about the "overloading" of opcodes being disastrous for
> forwards-compatibility (i mention "forwards" specifically because
> ForwardCom is that), but that also there is the hobson's
> choice of adding literal-duplicates of opcodes resulting in
> the exact same concept behind "SIMD considered harmful"
> also doing the exact same damage not just to a SIMD ISA
> but to a True-Scalable Vector ISA (such as ForwardCom,
> MRISC32, RVV) and it turns out *even to a Scalar ISA*.
>
> for a Scalar ISA it is "not so bad", you may only have to add
> say 20-50 duplicate integer arithmetic operations (duplicating
> the 32-bit ISA, adding 64-bit equivalents), duplicating say
> 70 or so FP32 operations and making FP64 variants, *and*
> remembering also to add converters between the same.
>
> Scalar Power ISA made the mistake of overloading the 32-bit
> integer opcodes with 64-bit meanings, in a rushed-upgrade
> about 20 years ago that they weren't really ready for. they *did*
> however make a fantastic decision to support FP32 format
> *in the exact same form as FP64* such that you *do not* have
> to do "conversion" between double and single operations.
> all unused bits when storing FP32 in FP64 form are zero:
> the only "conversion" needed is on non-normalised operations
> when you load the FP32, and luckily that's possible to do
> without needing to raise any Exceptions.
>
> Mitch's 66000 ISA helps reduce some of the conversion
> proliferation (transfer between GPR and FPR) by having
> just the one 64-entry regfile. RISC-V and other RISC ISAs
> have a 2-bit dedicated field for specifying the bit-width
> of the FP operation (FP16 FP32 FP64 FP80/128)
>
> but i digress, despite this being important context outlining
> that the problem of opcode proliferation is not limited to
> Vector ISAs.
>
> how do you reduce that opcode proliferation? how do you
> not end up dedicating 2 critical bits to the width of operations
> (like RISC-V) where you are already under pressure (say with
> 16-bit Compressed), especially when (say) you want source
> *and* destination width-specifiers?
>
> there are a few solutions i have encountered (i would be
> interested to hear of more)
>
> * "tagged" registers. ForwardCom actually has tags already
> (the vector length of each vector register is a "tag" in the
> register itself. why not also include the element width?)
> * "Control Status Registers". Power ISA has "bit-accuracy"
> CSR bits, already, where if you want all FP operations to
> be reduced accuracy (faster speed) you are permitted to
> do so. there is nothing to stop you using a couple of bits
> of CSR to specify "all integer operations normally marked
> as 64-bit are now actually 32-bit" (and vice-versa)
> * "Prefixing". a RISC-uniform Prefix instruction (similar to
> ARM SVE MOVPRFX) may specify "the following instruction's
> source (and destination) registers are NN-bit wide"
>
> there's a few more out there: they all have advantages and
> disadvantages, but at least they do not poison the core of
> the ISA with massive opcode proliferation.
>
> fascinatingly, though, they *do* still impact the Decoder Phase
> to some extent, i'd be interested to hear peoples' thoughts on
> how to overcome some of those problems.
>

One can always go a route similar to the FPU (and "SIMD") ops in SuperH
and use some flags in a control register somewhere to effectively change
out which instructions are being encoded.

Or, going further, one could "bank switch" parts of the ISA.

Conceivably, all one really needs is:
Some dedicated control bits somewhere;
A mechanism to change these bits;
(Presumably) a way to trigger a pipeline flush so that everything is
decoded as expected.

AFAICT, in SH, the idea was that modifying one of the offending control
registers would implicitly invoke a pipeline flush (say, by implicitly
causing the CPU to do a full branch to the following instruction).

Well, this was along with some variations of the ISA using fixed-length
16-bit instructions, and some other variants using a 16/32 encoding, and
some variants having different sets of instructions in the same
locations (so, effectively, SH2/SH3/SH4 variants would necessarily
remain binary incompatible with each other, and later iterations had
diverged down different paths).

In my original form of BJX1, I had replaced a few of these cases with
explicit instructions to Set/Clear/Invert some of these bits (in the
original SH ISA, one would typically need to reload the register state
via an in-memory literal). This was along with awkwardly gluing some
parts of later SH2 derivatives onto an otherwise SH4 based design, ...
(and whole thing sort of turning into an ugly mess).

Originally, pretty much all of this was eliminated for BJX2, eliminating
all use of contextually encoded instructions.
Well, except that now XG2 can be considered a variation of this idea,
but more switches out the general encoding scheme rather than individual
groups of instructions; and is currently applied at the scale of an
entire program executable (theoretically, it is possible to jump back
and forth between them, but this is not currently done in BGBCC).

But, if one runs out of encoding space, one will find a way...

> l.

On 9/21/2023 1:45 AM, luke.l...@gmail.com wrote:
> somewhere in this thread a couple weeks back i mentioned
> about the "overloading" of opcodes being disastrous for
> forwards-compatibility (i mention "forwards" specifically because
> ForwardCom is that), but that also there is the hobson's
> choice of adding literal-duplicates of opcodes resulting in
> the exact same concept behind "SIMD considered harmful"
> also doing the exact same damage not just to a SIMD ISA
> but to a True-Scalable Vector ISA (such as ForwardCom,
> MRISC32, RVV) and it turns out *even to a Scalar ISA*.
>
> for a Scalar ISA it is "not so bad", you may only have to add
> say 20-50 duplicate integer arithmetic operations (duplicating
> the 32-bit ISA, adding 64-bit equivalents), duplicating say
> 70 or so FP32 operations and making FP64 variants, *and*
> remembering also to add converters between the same.
>
> Scalar Power ISA made the mistake of overloading the 32-bit
> integer opcodes with 64-bit meanings, in a rushed-upgrade
> about 20 years ago that they weren't really ready for. they *did*
> however make a fantastic decision to support FP32 format
> *in the exact same form as FP64* such that you *do not* have
> to do "conversion" between double and single operations.
> all unused bits when storing FP32 in FP64 form are zero:
> the only "conversion" needed is on non-normalised operations
> when you load the FP32, and luckily that's possible to do
> without needing to raise any Exceptions.
>
> Mitch's 66000 ISA helps reduce some of the conversion
> proliferation (transfer between GPR and FPR) by having
> just the one 64-entry regfile. RISC-V and other RISC ISAs
> have a 2-bit dedicated field for specifying the bit-width
> of the FP operation (FP16 FP32 FP64 FP80/128)
>
> but i digress, despite this being important context outlining
> that the problem of opcode proliferation is not limited to
> Vector ISAs.
>
> how do you reduce that opcode proliferation? how do you
> not end up dedicating 2 critical bits to the width of operations
> (like RISC-V) where you are already under pressure (say with
> 16-bit Compressed), especially when (say) you want source
> *and* destination width-specifiers?
>
> there are a few solutions i have encountered (i would be
> interested to hear of more)
>
> * "tagged" registers. ForwardCom actually has tags already
> (the vector length of each vector register is a "tag" in the
> register itself. why not also include the element width?)

There are several "variants" of tagging. It is a question of where to
put the bits indicating operand data type/width. For reference, as you
indicate, most ISAs put them in the op-codes. The Burroughs large scale
system put them in each memory location (SIMD wasn't a thing back then).
The Mill is in-between Burroughs and most current ISAs in that it puts
them in the load instructions, then keeps them along with the
"registers" (Mill's belt slots). Each solution has plusses and minuses.

> * "Control Status Registers". Power ISA has "bit-accuracy"
> CSR bits, already, where if you want all FP operations to
> be reduced accuracy (faster speed) you are permitted to
> do so. there is nothing to stop you using a couple of bits
> of CSR to specify "all integer operations normally marked
> as 64-bit are now actually 32-bit" (and vice-versa)
> * "Prefixing". a RISC-uniform Prefix instruction (similar to
> ARM SVE MOVPRFX) may specify "the following instruction's
> source (and destination) registers are NN-bit wide"
>
> there's a few more out there: they all have advantages and
> disadvantages, but at least they do not poison the core of
> the ISA with massive opcode proliferation.
>
> fascinatingly, though, they *do* still impact the Decoder Phase
> to some extent, i'd be interested to hear peoples' thoughts on
> how to overcome some of those problems.

Interesting topic. It is directly related to how to "future proof" an
ISA and prevent, or at least minimize the mess that most long lived ISAs
have become.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Thursday, September 21, 2023 at 3:45:10 AM UTC-5, luke.l...@gmail.com wrote:
> somewhere in this thread a couple weeks back i mentioned
> about the "overloading" of opcodes being disastrous for
> forwards-compatibility (i mention "forwards" specifically because
> ForwardCom is that), but that also there is the hobson's
> choice of adding literal-duplicates of opcodes resulting in
> the exact same concept behind "SIMD considered harmful"
> also doing the exact same damage not just to a SIMD ISA
> but to a True-Scalable Vector ISA (such as ForwardCom,
> MRISC32, RVV) and it turns out *even to a Scalar ISA*.
>
> for a Scalar ISA it is "not so bad", you may only have to add
> say 20-50 duplicate integer arithmetic operations (duplicating
> the 32-bit ISA, adding 64-bit equivalents), duplicating say
> 70 or so FP32 operations and making FP64 variants, *and*
> remembering also to add converters between the same.
>
> Scalar Power ISA made the mistake of overloading the 32-bit
> integer opcodes with 64-bit meanings, in a rushed-upgrade
> about 20 years ago that they weren't really ready for. they *did*
> however make a fantastic decision to support FP32 format
> *in the exact same form as FP64* such that you *do not* have
> to do "conversion" between double and single operations.
> all unused bits when storing FP32 in FP64 form are zero:
> the only "conversion" needed is on non-normalised operations
> when you load the FP32, and luckily that's possible to do
> without needing to raise any Exceptions.
>
> Mitch's 66000 ISA helps reduce some of the conversion
> proliferation (transfer between GPR and FPR) by having
> just the one 64-entry regfile. RISC-V and other RISC ISAs
> have a 2-bit dedicated field for specifying the bit-width
> of the FP operation (FP16 FP32 FP64 FP80/128)
>
> but i digress, despite this being important context outlining
> that the problem of opcode proliferation is not limited to
> Vector ISAs.
>
> how do you reduce that opcode proliferation? how do you
> not end up dedicating 2 critical bits to the width of operations
> (like RISC-V) where you are already under pressure (say with
> 16-bit Compressed), especially when (say) you want source
> *and* destination width-specifiers?
>
> there are a few solutions i have encountered (i would be
> interested to hear of more)
>
> * "tagged" registers. ForwardCom actually has tags already
> (the vector length of each vector register is a "tag" in the
> register itself. why not also include the element width?)
> * "Control Status Registers". Power ISA has "bit-accuracy"
> CSR bits, already, where if you want all FP operations to
> be reduced accuracy (faster speed) you are permitted to
> do so. there is nothing to stop you using a couple of bits
> of CSR to specify "all integer operations normally marked
> as 64-bit are now actually 32-bit" (and vice-versa)
> * "Prefixing". a RISC-uniform Prefix instruction (similar to
> ARM SVE MOVPRFX) may specify "the following instruction's
> source (and destination) registers are NN-bit wide"
<
* "Bookends". A pair of RISC instructions, one at the beginning
of a Loop and the other at the end of the Loop. The instructions
"in" the loop can be performed in SIMD-fashion, the LDs give
the widths of the inbound containers, the STs give the width
of the outbound containers. The VEC instruction contains the
registers that are live-out of the Loop, and the LOOP instruction
performs the Loop repetition.
<
You get all of the SIMDification and Vectorization from 2
total instructions instead of 1300, or 400.......
>
> there's a few more out there: they all have advantages and
> disadvantages, but at least they do not poison the core of
> the ISA with massive opcode proliferation.
>
> fascinatingly, though, they *do* still impact the Decoder Phase
> to some extent, i'd be interested to hear peoples' thoughts on
> how to overcome some of those problems.
>
> l.

> there are a few solutions i have encountered (i would be
> interested to hear of more)
> * "tagged" registers. ForwardCom actually has tags already
[...]
> * "Control Status Registers". Power ISA has "bit-accuracy"
[...]
> * "Prefixing". a RISC-uniform Prefix instruction (similar to
[...]
> fascinatingly, though, they *do* still impact the Decoder Phase
> to some extent, i'd be interested to hear peoples' thoughts on
> how to overcome some of those problems.

I think you can't get a good answer before clarifying what it is that
you consider as the problem in "opcode proliferation" (after all,
"prefixing" is just another name for variable-length instructions, and
what is considered as "opcode" vs "immediate operand" within an
instruction is largely philosophical).

As you point out, part of the complexity doesn't come from
instruction encoding, really, but from the actual desired semantics.

So in terms of instruction encoding, the main issues would be:

A. Code size.
B. Not preventing the core from working at full speed.
C. The cost of decoding.

(C) can only bite when backward compatibility forces inconvenient
encodings, but even the amd64 architecture seems to do fine, so it
doesn't seem to be a serious issue.

I think (B) is never an unsolvable problem. E.g. CSR-based solutions
sometimes require pipeline drainage, but that's usually solvable
without changing the encoding by passing the CSR through the pipeline.
But maybe tagged registers could be problematic because you end up
getting this info too late, in the execution rather than in the decode?

So I'd guess it's really mostly a code-size issue (beside the semantic
issues when you want to make it so old code can work with new sizes, of
course, but IIUC you were talking about the scalar case where this seems
to be too problematic to even contemplate).

My gut tells me that in terms of code size, tagged registers should be
the better choice. But I don't know of any actual efforts to try and
confirm it experimentally.

Stefan

On Monday, September 25, 2023 at 11:25:30 AM UTC-5, Stefan Monnier wrote:
> > there are a few solutions i have encountered (i would be
> > interested to hear of more)
> > * "tagged" registers. ForwardCom actually has tags already
> [...]
> > * "Control Status Registers". Power ISA has "bit-accuracy"
> [...]
> > * "Prefixing". a RISC-uniform Prefix instruction (similar to
> [...]
> > fascinatingly, though, they *do* still impact the Decoder Phase
> > to some extent, i'd be interested to hear peoples' thoughts on
> > how to overcome some of those problems.
<
> I think you can't get a good answer before clarifying what it is that
> you consider as the problem in "opcode proliferation" (after all,
<
The problem is that the Cartesian-product associated with SIMD
causes thousands of microscopic instructions to be needed (for
example ARM has at least 1,300 SIMD instructions, others worse.)
<
It is my contention that sooner or later one needs to respect the R
as the first letter in RISC and make it stand for REDUCED !!
<
It is also my contention that nobody with more than <wave hands>
200 instructions can be called RISC.
<
> "prefixing" is just another name for variable-length instructions, and
> what is considered as "opcode" vs "immediate operand" within an
> instruction is largely philosophical).
>
> As you point out, part of the complexity doesn't come from
> instruction encoding, really, but from the actual desired semantics.
>
> So in terms of instruction encoding, the main issues would be:
>

MitchAlsup <MitchAlsup@aol.com> writes:
>On Monday, September 25, 2023 at 11:25:30=E2=80=AFAM UTC-5, Stefan Monnier =
>wrote:
>> > there are a few solutions i have encountered (i would be=20
>> > interested to hear of more)=20
>> > * "tagged" registers. ForwardCom actually has tags already
>> [...]
>> > * "Control Status Registers". Power ISA has "bit-accuracy"
>> [...]
>> > * "Prefixing". a RISC-uniform Prefix instruction (similar to
>> [...]
>> > fascinatingly, though, they *do* still impact the Decoder Phase=20
>> > to some extent, i'd be interested to hear peoples' thoughts on=20
>> > how to overcome some of those problems.
><
>> I think you can't get a good answer before clarifying what it is that=20
>> you consider as the problem in "opcode proliferation" (after all,=20
><
>The problem is that the Cartesian-product associated with SIMD
>causes thousands of microscopic instructions to be needed (for
>example ARM has at least 1,300 SIMD instructions, others worse.)

That's a bit misleading, as you're counting individual instruction
words (opcode + all variations of source and destination register(s)).

On Friday, September 29, 2023 at 7:37:30 PM UTC-5, Scott Lurndal wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >On Monday, September 25, 2023 at 11:25:30=E2=80=AFAM UTC-5, Stefan Monnier =
> >wrote:
> >> > there are a few solutions i have encountered (i would be=20
> >> > interested to hear of more)=20
> >> > * "tagged" registers. ForwardCom actually has tags already
> >> [...]
> >> > * "Control Status Registers". Power ISA has "bit-accuracy"
> >> [...]
> >> > * "Prefixing". a RISC-uniform Prefix instruction (similar to
> >> [...]
> >> > fascinatingly, though, they *do* still impact the Decoder Phase=20
> >> > to some extent, i'd be interested to hear peoples' thoughts on=20
> >> > how to overcome some of those problems.
> ><
> >> I think you can't get a good answer before clarifying what it is that=20
> >> you consider as the problem in "opcode proliferation" (after all,=20
> ><
> >The problem is that the Cartesian-product associated with SIMD
> >causes thousands of microscopic instructions to be needed (for
> >example ARM has at least 1,300 SIMD instructions, others worse.)
<
> That's a bit misleading, as you're counting individual instruction
> words (opcode + all variations of source and destination register(s)).
<
Not source and destination--but operand size and register size.
<
Register sizes {64, 128, 256, 512}
Operand size {8, 16, 32, 64}
Calculation {int{+, -, ×, /, &, |, ^,}, FP{+, -, ×, /,}, swizzles, gather, scatter, ...}
......
Sooner or later it all adds up to shiploads of instructions. And the instructions
are not backwards compatible,...
<
And in comparison:: I got almost all of that capability with 2 instructions
that guarantees forward and backwards compatibility, and scales with
machine resources.
<
2 versus 1300 :: Which one is really RISC ??

On Friday, September 29, 2023 at 9:01:18 PM UTC-4, MitchAlsup wrote:
> On Friday, September 29, 2023 at 7:37:30 PM UTC-5, Scott Lurndal wrote:
> > MitchAlsup <Mitch...@aol.com> writes:
> > >On Monday, September 25, 2023 at 11:25:30=E2=80=AFAM UTC-5, Stefan Monnier =
> > >wrote:
> > >> > there are a few solutions i have encountered (i would be=20
> > >> > interested to hear of more)=20
> > >> > * "tagged" registers. ForwardCom actually has tags already
> > >> [...]
> > >> > * "Control Status Registers". Power ISA has "bit-accuracy"
> > >> [...]
> > >> > * "Prefixing". a RISC-uniform Prefix instruction (similar to
> > >> [...]
> > >> > fascinatingly, though, they *do* still impact the Decoder Phase=20
> > >> > to some extent, i'd be interested to hear peoples' thoughts on=20
> > >> > how to overcome some of those problems.
> > ><
> > >> I think you can't get a good answer before clarifying what it is that=20
> > >> you consider as the problem in "opcode proliferation" (after all,=20
> > ><
> > >The problem is that the Cartesian-product associated with SIMD
> > >causes thousands of microscopic instructions to be needed (for
> > >example ARM has at least 1,300 SIMD instructions, others worse.)
> <
> > That's a bit misleading, as you're counting individual instruction
> > words (opcode + all variations of source and destination register(s)).
> <
> Not source and destination--but operand size and register size.
> <
> Register sizes {64, 128, 256, 512}
> Operand size {8, 16, 32, 64}
> Calculation {int{+, -, ×, /, &, |, ^,}, FP{+, -, ×, /,}, swizzles, gather, scatter, ...}
> .....
> Sooner or later it all adds up to shiploads of instructions. And the instructions
> are not backwards compatible,...
> <
> And in comparison:: I got almost all of that capability with 2 instructions
> that guarantees forward and backwards compatibility, and scales with
> machine resources.
> <
> 2 versus 1300 :: Which one is really RISC ??

Those shiploads of instructions also require more bits to encode. Using the idea
there would be shiploads of instructions leads to wide instructions - 40-bits.
Otherwise, one ends up with piles of instruction prefixes. Operands could be
128-bits too and register size might not stop at 512 bits, so there are potentially even
more instructions on the way. It requires a good nomenclature to represent all the
instructions. Is there a nomenclature project somewhere?

I keep musing over the idea of using a register file tagged with the data type to try
and reduce the instructions, but have discarded it a couple of times. I get bogged
down implementing the rules for the target data type. For example, if an address is
added to an integer the result should be an address. Subtract two addresses and
the result should be an integer. Compare-and-branch causes an exception if the two
data types compared are not the same. Using tagged registers has its own set of
complexities and I am not sure the extra logic would be worth it. I think it may be
easier and less logic (faster) to have the compiler manage all the instructions.
These days most things are done in HLL so how valuable is having a compact
assembler language instruction set?

MitchAlsup <MitchAlsup@aol.com> writes:
>And in comparison:: I got almost all of that capability with 2 instructions
>that guarantees forward and backwards compatibility, and scales with
>machine resources.
><
>2 versus 1300 :: Which one is really RISC ??

There has been the argument that RISC is not about reduced numbers of
instructions, but about reduced complexity. The Cartesian product
does not make the instructions more complex, only more.

The complexity of your two additional instructions is, from an
architectural POV, the same as two nops, correct? That's good!

OTOH, it leads to the question why we need these instructions at all.
Can you virtual vectors not be implemented as a pure
microarchitectural mechanism without any additional instructions?
What do the additional instructions buy?

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Saturday, September 30, 2023 at 2:34:08 AM UTC-5, Anton Ertl wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >And in comparison:: I got almost all of that capability with 2 instructions
> >that guarantees forward and backwards compatibility, and scales with
> >machine resources.
> ><
> >2 versus 1300 :: Which one is really RISC ??
> There has been the argument that RISC is not about reduced numbers of
> instructions, but about reduced complexity. The Cartesian product
> does not make the instructions more complex, only more.
>
> The complexity of your two additional instructions is, from an
> architectural POV, the same as two nops, correct? That's good!
<
Not quite NoOps:: the leading one provides a bit vector of registers that
are live-out from the loop; the trailing one does the ADD-CMP-BC part
of the loop.
>
> OTOH, it leads to the question why we need these instructions at all.
> Can you virtual vectors not be implemented as a pure
> microarchitectural mechanism without any additional instructions?
<
It might be possible to recognize a loop as something special that can
be performed with non-standard HW mechanisms--it is just easier when
the loop self-identifies.
<
> What do the additional instructions buy?
<
Sequencing semantics--mainly in what does NOT need to be performed
(the live-outs for example minimizes the work of exiting the loop).
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

luke.l...@gmail.com <luke.leighton@gmail.com> schrieb:

> as Mitch notes in a later post (today), the "Cartesian Product" turns out
> in say Audio DSPs doing SWAR (SIMD Within A Register) such as AndesStar
> to be an O(N^6) clusterpoop. these DSPs, they are under enormous cost
> and power budget pressure (think "C-Media sub-$1 USB Audio PHYs with
> built-in volume control", they potentially only run at 8-12 mhz and are likely
> in 130 or even 180 nm! USB1.1 and/or have a PLL that slaves to the host
> USB bus, the STM32F072 does this: really neat trick)
>
> take even just an ADD, you would think there
> would only ever be one add instruction in a RISC ISA? ehhhhm no
>
> * 8/16 bit source selection doubles that
> * 8/16 bit destination selection doubles it again

Assuming that these processors are indeed RISC (so, a load-
store architecture), then this could be handled by having

- 8-bit sign-extending load
- 8-bit zero-extending load
- 16 bit load
- 8-bit store
- 16-bit store

and always doing 16-bit arithmetic.

Hm, that's five loads and stores so far, still some room :-)

(Or is it a "RISC" in the sense of the MSP430, which is about as
much a RISC as the PDP-11? Then the above does not apply).

> * hi/lo half on source 1 doubles it again
> * hi/lo half on source 2 doubles it again

I'm not quite sure what the functionality is. Is it possible
to effectively treat each half of a register as a sub-register in
the ISA? Then, you need the bits for it.

> * signed and unsigned saturation triples the number of ADD operations
> (clipping in audio is important rather than getting wrapping distortion)

Yes, then you also need separate eight-bit additions.

> * "average-add" (x+y+1)>>1 (for Audio this is crucial) doubles again
> (if you only have 16 bit audio and a low-speed DSP you cannot afford
> to do that kind of calculation in 3 instructions, and you need 32-bit regs)

So, another addition...

> we are up to 6 dimensions and a whopping NINETY SIX *commercially necessary*
> variants on what is supposed to be one simple ADD operation!

On Saturday, September 30, 2023 at 4:41:16 PM UTC-5, Thomas Koenig wrote:
> luke.l...@gmail.com <luke.l...@gmail.com> schrieb:
> > as Mitch notes in a later post (today), the "Cartesian Product" turns out
> > in say Audio DSPs doing SWAR (SIMD Within A Register) such as AndesStar
> > to be an O(N^6) clusterpoop. these DSPs, they are under enormous cost
> > and power budget pressure (think "C-Media sub-$1 USB Audio PHYs with
> > built-in volume control", they potentially only run at 8-12 mhz and are likely
> > in 130 or even 180 nm! USB1.1 and/or have a PLL that slaves to the host
> > USB bus, the STM32F072 does this: really neat trick)
> >
> > take even just an ADD, you would think there
> > would only ever be one add instruction in a RISC ISA? ehhhhm no
> >
> > * 8/16 bit source selection doubles that
> > * 8/16 bit destination selection doubles it again
> Assuming that these processors are indeed RISC (so, a load-
> store architecture), then this could be handled by having
>
> - 8-bit sign-extending load
> - 8-bit zero-extending load
> - 16 bit load
> - 8-bit store
> - 16-bit store
<
7 LDs, 4 STs:: the LDs need sign/zero extension (except for the largest).
<
But we started off with SIMD and there registers go up to 512-bits (so far)..
At 512-bits, one needs {8, 16, 32, 64, 128, 256}×{s, u}+{512} for Loading data
>
> and always doing 16-bit arithmetic.
>
> Hm, that's five loads and stores so far, still some room :-)
<
Yes, exactly; isolating data width to LD and ST instructions saves instruction
count big time--UNTIL--you need multiple calculations within a single register
width. So, a real RISC machine has 1 (or 2) ADDs, whereas a SIMD machine
has {widths}×{signs}×{formats} (and more as EricP illustrated above.)
>
> (Or is it a "RISC" in the sense of the MSP430, which is about as
> much a RISC as the PDP-11? Then the above does not apply).
<
RISC means::
LD/ST architecture (no LD-OPs or LD-OP-STs)
Lots of GPRs (you might get away with 16 but 32 is general min)
Hardwired sequencing
Instruction pipelining
Driven primarily by compiler (with just a dabbling of ASM)
<
> > * hi/lo half on source 1 doubles it again
> > * hi/lo half on source 2 doubles it again
> I'm not quite sure what the functionality is. Is it possible
> to effectively treat each half of a register as a sub-register in
> the ISA? Then, you need the bits for it.
<
EricP is talking about a 512-bit register having {64,32,16,8,{4,2,1}}
values in that 1 register. And, yes, you need bits to specify each
nuance.
<
> > * signed and unsigned saturation triples the number of ADD operations
> > (clipping in audio is important rather than getting wrapping distortion)
> Yes, then you also need separate eight-bit additions.
> > * "average-add" (x+y+1)>>1 (for Audio this is crucial) doubles again
> > (if you only have 16 bit audio and a low-speed DSP you cannot afford
> > to do that kind of calculation in 3 instructions, and you need 32-bit regs)
> So, another addition...
> > we are up to 6 dimensions and a whopping NINETY SIX *commercially necessary*
> > variants on what is supposed to be one simple ADD operation!
<
Now take a look at what happens when the very vast majority of code
does not need any of "that" and you specify variants with prefixes (or
postfixes), you end up back in RISC land being able to specify each of
those variants but you have a sum of prefixing bits not a Cartesian product
of instructions. Here, when you double the width of a SIMD register, you
add 1 prefix (instead of 60+ each) and you have access to all its functionality.
<
......

On Saturday, September 30, 2023 at 10:41:16 PM UTC+1, Thomas Koenig wrote:
> luke.l...@gmail.com <luke.l...@gmail.com> schrieb:

> > * 8/16 bit source selection doubles that
> > * 8/16 bit destination selection doubles it again
> Assuming that these processors are indeed RISC (so, a load-
> store architecture), then this could be handled by having
>
> - 8-bit sign-extending load
> - 8-bit zero-extending load
> - 16 bit load
> - 8-bit store
> - 16-bit store
>
> and always doing 16-bit arithmetic.

at which point the processor clock rate must be doubled
(making it commercially unviable due to power consumption,
e.g. outside of USB2 bus ampage) or the amount of silicon
doubled (same result).

the example I gave (AndesStar Audio DSP) is at the 8051 level
so 16 bit registers, 2 channel audio, $0.25 or less, 8 MHz clock.
doubling to 16 MHz in 180 nm because the opportunity is lost to use
the other 8 bits for doing left-right audio in the same clock rather
than needing 2x the time, this is the whole reason why the
seduction of SIMD even exists.

> > * hi/lo half on source 1 doubles it again
> > * hi/lo half on source 2 doubles it again
> I'm not quite sure what the functionality is.

Left channel audio in lower half, right channel in upper,
you want to balance the left channel against the right
and yet detect clipping. But then you want to do the
opposite way as well.

> So, another addition...

to which you then still need all the other options,
Hilo lohi 8/16 saturate etc and you might as well just consider
it to be another dimension of the Cartesian Product of options
on "add"

On Saturday, September 30, 2023 at 10:59:56 PM UTC+1, MitchAlsup wrote:

> Now take a look at what happens when the very vast majority of code
> does not need any of "that" and you specify variants with prefixes (or
> postfixes), you end up back in RISC land being able to specify each of
> those variants but you have a sum of prefixing bits not a Cartesian product
> of instructions. Here, when you double the width of a SIMD register, you
> add 1 prefix (instead of 60+ each) and you have access to all its functionality.

and if you do not need a particular augmentation you do not
add the prefix to request it. thus the ISA stream remains both
RISC and compact for the majority of programs.

One scheme I came up with 4 years ago was a *third* L1 cache,
containing highly compact "augmentations" rather than polluting
the main L1 I-Cache with "prefixing". where the main ISA might
be 32-bit the "augmentation" L1 cache might only be 16 bit.
Whereas if the prefixes had to be embedded in the 32 bit ISA
itself they take up valuable 32-bit RISC opcode space and you
are back to square one.

It is a trade-off basically.

L.

On Saturday, September 30, 2023, 'MitchAlsup' via comp.arch <comp.arch@googlegroups.com> wrote:
> On Saturday, September 30, 2023 at 2:34:08 AM UTC-5, Anton Ertl wrote:

>> What do the additional instructions buy?

> Sequencing semantics--mainly in what does NOT need to be performed
> (the live-outs for example minimizes the work of exiting the loop).

and i remember mmm 4 years back you said that it is less
hardware to have *one* looped LD/ST than to have hardware
make the attempt to spot that say 12 scalar LD/STs are
sequential/contiguous.

i designed some hardware to do that and for 12 LD/ST Reservation
Stations it has something mad like 10,000 wires incoming/outgoing
but only 4,000 actual gates.

l.

On Saturday, September 30, 2023 at 6:13:16 PM UTC-5, luke.l...@gmail.com wrote:
> On Saturday, September 30, 2023, 'MitchAlsup' via comp.arch <comp...@googlegroups.com> wrote:
> > On Saturday, September 30, 2023 at 2:34:08 AM UTC-5, Anton Ertl wrote:
>
> >> What do the additional instructions buy?
>
> > Sequencing semantics--mainly in what does NOT need to be performed
> > (the live-outs for example minimizes the work of exiting the loop).
<
> and i remember mmm 4 years back you said that it is less
> hardware to have *one* looped LD/ST than to have hardware
> make the attempt to spot that say 12 scalar LD/STs are
> sequential/contiguous.
<
Given one can see a LD or ST instruction and knowing that it is between
VEC and LOOP instructions, one can determine if the memory sequence
is "dense" or not. Dense memory instructions can be processed at cache
line width, and this allows the calculation instructions to be processed
SIMD-style, otherwise one can always resort to GBOoO execution styles.
<
Were it not for the VEC and LOOP instructions, the problem is way harder.
>
> i designed some hardware to do that and for 12 LD/ST Reservation
> Stations it has something mad like 10,000 wires incoming/outgoing
> but only 4,000 actual gates.
<
That is the classical trade off between Scoreboards and Reservation
Stations. {Imagine a 6-wide machine} The number of wires in the RS is
proportional to the number of busses and the namespace of the values
traversing that bus. Let us postulate that there are 6 FUs and a 128 register
value namespace. So, every cycle 6 FUs send a 7-bit tag {42 wires move
per cycle}. Each of those 7-bit items must be compared to the desired value
{CAM} and CAMs eat power in order to make register data flow decisions.
<
Consider the SB alternative, 6 FUs and 128-wires each {768 total}. But here,
only 6 wires move per cycle. Each of these 768 wires is compared to a
single value (AND gate) in order to make register data flow conditions.
>
> l.

On Sunday, October 1, 2023 at 12:39:34 AM UTC+1, MitchAlsup wrote:
> On Saturday, September 30, 2023 at 6:13:16 PM UTC-5, luke.l...@gmail.com wrote:
> > i designed some hardware to do that and for 12 LD/ST Reservation
> > Stations it has something mad like 10,000 wires incoming/outgoing
> > but only 4,000 actual gates.
> <
> That is the classical trade off between Scoreboards and Reservation
> Stations.

ah no sorry i wasn't clear: this was based on the EA-matching that is in
your Scoreboard Mechanics book chapters (or perhaps the 88100 ones),
where you take 10-12 bits and perform a triangular match to find conflicts.
it's O(N^2) so by the time you get up to (say) 12 LD/STs a full crossbar
on address/data/tag where data is 128-bit by that point (because 64-bit @
up to 8 bytes shifted) it gets pretty hairy.

l.