On Monday, January 30, 2023 at 11:03:36 AM UTC, Agner Fog wrote:
> I have developed ForwardCom with help and suggestions from many people. This is a project to improve not only the ISA, but the entire ecosystem of software, ABI standard, development tools, etc.
>
> ForwardCom can vectorize array loops in a new way that automatically adjusts to the maximum vector length supported by the CPU.

Agner, hi,

I found the manual (great website, very simple, gives what's needed)
https://github.com/ForwardCom/manual/raw/master/forwardcom.pdf

i have a specific interest in anything Vector-related, so i was hunting
for that and was pleased to find it straight away. Section 2.5 tells
me that you have implemented a bog-standard Cray-style-Vector
concept (exactly like Cray YMP-1 and RVV). Section 2.6 page 14
tells me that you have exactly the same flaws as RVV and SVE,
namely that if you want binary-portability you *have* to have a
loop around *all* Vector algorithms.

Cray and NEC Aurora SX (Tsubasa) both avoided this thorny
binary-compatibility problem by *only* implementing a
fixed Lane-Length for *all* iterations of their hardware.

Thus you could in fact set VL to an explicit known amount
and *still guarantee* that the binary executable would work
on future machines... *without needing a loop*.

You also have the issue that any operation involving element-rotate
and element-indexing (permute for example) is absolutely screwed
and is *in no way* binary-compatible.

Whereas on Cray and Tsubasa you *know* that the number of
Lanes is fixed (256 on Tsubasa) and therefore you *know* that
element-rotate and permute are 100% going to work on all future
hardware without a recompile and/or full algorithm redesign in
some cases.

Both RVV and SVE have made this exact same mistake so you are
not alone. They both brush it under the carpet, but it is a "quiet
secret" that programmers are waking up to.

l.

On Wednesday, September 6, 2023 at 4:40:08 PM UTC+2, luke wrote:

> if you want binary-portability you *have* to have a
> loop around *all* Vector algorithms.
>
The ForwardCom manual specifies that the CPU must support a vector length of at least 128 bits. If you want vectors longer than 128 bits, you must make a loop if you want binary compatibility.

On Thursday, September 7, 2023 at 7:17:20 AM UTC+1, Agner wrote:
> On Wednesday, September 6, 2023 at 4:40:08 PM UTC+2, luke wrote:
>
> > if you want binary-portability you *have* to have a
> > loop around *all* Vector algorithms.
> >
> The ForwardCom manual specifies that the CPU must support
> a vector length of at least 128 bits. If you want vectors longer
> than 128 bits, you must make a loop if you want binary compatibility.

[WARNING: the person that you are engaging with (me) has
severe Asperger's. i am not "an asshole". please BE PATIENT
and in no way engage with me in any verbally-abusive way
as it has recently become life-threatening to me if you do so]

ahh bless you: you've missed the point entirely. this mistake was
also made by RVV and SVE, setting a "minimum vector length".

it doesn't really help as it entirely misses a huge opportunity
(missed by pretty much every Vector ISA under the sun)

can i suggest watching this video and if you are interested
to do so, to write what you believe the point is, and i can
check it? https://www.youtube.com/watch?v=HNEm8zmkjBU

the reason i say it that way - as an offer to help you *if* you
are interested - is that this is an open internet forum, you
asked for feedback, i gave some feedback, and it's complex
enough that *if* you are interested in that feedback, you
need to make the effort to understand it, and where it comes
from.

in that way we have a nice enjoyable technical conversation,
and we both learn something. i read further for example (p26)
and found that you embed the "vector length" actually *in* the
vector register, which is something i have not encountered
before and would love to hear more about because it's new
to me (and i've studied a **LOT** of Vector ISAs, i'm the
primary recent large contributor to this page
https://en.wikipedia.org/wiki/Vector_processor)

if you do not want my help then that is perfectly fine with me:
i respect that decision 100%, and will go and find something
else to do that i will enjoy.

l.

On Thursday, September 7, 2023 at 1:37:48 PM UTC+2, luke.l wrote:

> it doesn't really help as it entirely misses a huge opportunity
> (missed by pretty much every Vector ISA under the sun)

I am not sure I understand what opportunity I am missing?

ForwardCom has no rotate vector instruction. It does have shift vector instructions.
Vector permute instructions are limited to permuting within blocks of a certain size. The reason for this limitation is that cross-wiring is quite expensive in hardware, and the amount of cross-wiring necessary for full permutation grows with the square of the vector size.

Vector length is specified per vector rather than in a global vector length register.

A vector register knows its own length. This is quite useful when saving and restoring registers on task switches, and it assures forward compatibility.

The scalability of predicate registers is obtained simply by using the same vector type for predicates. The extra bits in the predicate register are used for options such as rounding mode, exception control, etc. This is where AVX512 goes crazy with new instructions for every size of predicate registers.

On Friday, September 8, 2023 at 9:41:12 AM UTC+3, luke.l...@gmail.com wrote:
>
> 3rd time saying it: see the video.
>

1st time saying: write it down.
I don't know about Agner, but I know that I am not going to see your video
for a sole reason of it being video.

WARNING: the person that you are interacting with (me)
has ASPERGER's. due to systematic verbal abuse it is
now DANGEROUS TO MY LIFE if you use "normal"
conventionally-accepted conversational "bullying".

On Friday, September 8, 2023 at 11:39:56 AM UTC+1, Michael S wrote:

> 1st time saying: write it down.

no. sorry. not enough time, and i am recovering from
systematic verbal abuse that almost killed me a few
months ago.

if someone else would like to watch the video then
provide a summary / transcript i am happy to discuss
it.

otherwise i will have to terminate involvement in this conversation,
*especially* if you "react like i am some sort of dick" instead
of being someone with Asperger's. if you are not familiar with
it please look it up and adapt accordingly.

l.

In article <ec4fd863-d316-4a23-acee-52fb6889735dn@googlegroups.com>,
luke.l...@gmail.com <luke.leighton@gmail.com> wrote:
>WARNING: the person that you are interacting with (me)
>has ASPERGER's. due to systematic verbal abuse it is
>now DANGEROUS TO MY LIFE if you use "normal"
>conventionally-accepted conversational "bullying".

This doesn't seem reasonable. You're asking others to align
themselves to an undefined and arbitrary _tone_ of writing and
style of discourse because you say you find anything else
physically dangerous. That may be the case, but consider that
others may not view what they write the way you do; it's really
not up them to anticipate your reaction, assuming they are
acting with good intent.

Perhaps you should consider withdrawing from online interaction
until you are in a better position to be able to better
negotiate the inevitable ambiguities of online conversation.

>On Friday, September 8, 2023 at 11:39:56 AM UTC+1, Michael S wrote:
>
>> 1st time saying: write it down.
>
>no. sorry. not enough time,

Then don't be surprised if peole don't investigate whatever your
video is about in more detail.

>otherwise i will have to terminate involvement in this conversation,

That's probably for the best.

>*especially* if you "react like i am some sort of dick" instead
>of being someone with Asperger's.

I know plenty of people with Asperber's. Most learn how to
navigate normal social interactions. At MIT, they call it
"unfreezing." Perhaps you should look into it.

- Dan C.

[OFF-TOPIC ADVANCE NOTICE - i do appreciate the engagement Dan]

On Friday, September 8, 2023 at 3:11:19 PM UTC+1, Dan Cross wrote:

> others may not view what they write the way you do; it's really
> not up them to anticipate your reaction, assuming they are
> acting with good intent.

it's not the "anticipation of my reaction" that's the problem: it's the
misinterpretation of *my* good-faith intentions to engage
*despite being severely handicapped* that's the problem, because
for most people unaware of Asperger's (or, "they've heard the word"
but have no idea what it means) they think "holy fuck this guy's
a DICK! let's fire back the shit he's slinging at us, with some extra
violent verbal force behind it, because he really pissed me off".

i know how this works. Asperger's is a life-long medical condition,
and i'm 53.

> Perhaps you should consider withdrawing from online interaction
> until you are in a better position to be able to better
> negotiate the inevitable ambiguities of online conversation.

this means permanently and irrevocably terminating everything
that i earn money from. i appreciate the suggestion: on the face
of it, under "normal" circumstances, it sounds very reasonable,
but the consequences of such withdrawal are so catastrophic
for my life that for me it is simply not an option.

put another way: would you suggest to someone who is blind,
"you should quit working until you get your eyes replaced?"

> I know plenty of people with Asperber's. Most learn how to
> navigate normal social interactions.

question for you: were any of them also subjected to 15 years
of violent domestic verbal abuse?

if you investigate further you'll likely find that those people
at MIT with Asperger's came from extremely stable and loving
family backgrounds. not all, but there will be a high correlation.

l.

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

> it's not the "anticipation of my reaction" that's the problem: it's the
> misinterpretation of *my* good-faith intentions to engage
> *despite being severely handicapped* that's the problem, because
> for most people unaware of Asperger's (or, "they've heard the word"
> but have no idea what it means) they think "holy fuck this guy's
> a DICK! let's fire back the shit he's slinging at us, with some extra
> violent verbal force behind it, because he really pissed me off".

That is not my reaction to your comp.arch posts at all.

I find them factual, informative and as non-flame-war-provoking
as can be.

luke.l...@gmail.com <luke.leighton@gmail.com> schrieb:
> WARNING: the person that you are interacting with (me)
> has ASPERGER's. due to systematic verbal abuse it is
> now DANGEROUS TO MY LIFE if you use "normal"
> conventionally-accepted conversational "bullying".
>
> On Friday, September 8, 2023 at 11:39:56 AM UTC+1, Michael S wrote:
>
>> 1st time saying: write it down.
>
> no. sorry. not enough time, and i am recovering from
> systematic verbal abuse that almost killed me a few
> months ago.
>
> if someone else would like to watch the video then
> provide a summary / transcript i am happy to discuss
> it.

I watched it. Let me try to sum up the salient points, I think
most comp.arch readers probably are aware of them. If I got
something wrong, please feel free to correct, own remarks
in [brackets].

The two main points you consider are binary compatibility and
permute instructions, which need indices into registers.

The AVX* family of instructions suffers from having to invent
separate instructions for each extension in number of registers
and number of bits per register, resulting in a huge number of
instructions.

IBM chose another path for POWER; they kept the number of register
and bit size constant (hence ensuring binary compatibility) and
went for multi-issue of instructions. If they wanted/needed to
extend that, they would have to add additonal opcodes or prefixes
[which amount to pretty much the same thing, IMHO].

Cray and NEC SX-Aurora have fixed-size registers, so binary
compatibility is ensured.

Where ARM SVE and RISC-V fail is the user-specifiable vector
length. It is possible to use it with loops around the vector
instructions, but permutations of vector elements are not possible
using user-specified vector length - binary compatible code has to
use the minimum size offeered, or silent data corruption will occur
when permuting.

Is that a fair summary?

On 9/8/2023 11:00 AM, luke.l...@gmail.com wrote:
> [OFF-TOPIC ADVANCE NOTICE - i do appreciate the engagement Dan]
>
> On Friday, September 8, 2023 at 3:11:19 PM UTC+1, Dan Cross wrote:
>
>> others may not view what they write the way you do; it's really
>> not up them to anticipate your reaction, assuming they are
>> acting with good intent.
>
> it's not the "anticipation of my reaction" that's the problem: it's the
> misinterpretation of *my* good-faith intentions to engage
> *despite being severely handicapped* that's the problem, because
> for most people unaware of Asperger's (or, "they've heard the word"
> but have no idea what it means) they think "holy fuck this guy's
> a DICK! let's fire back the shit he's slinging at us, with some extra
> violent verbal force behind it, because he really pissed me off".
>
> i know how this works. Asperger's is a life-long medical condition,
> and i'm 53.
>

I am at least slightly younger (early Gen Y, still "late 30s" at the
moment...).

I have noted in many contexts, it is not worthwhile to interact with
neurotypicals in any sense much beyond superficial social conventions.

Granted, I also have another condition (alexithymia), and relatively
limited perception of emotions. It seems to have settled into a state
where I can deal with (usual) social conflicts sort of OK by mostly "not
giving a crap".

So, say, if one lets themselves care about the outcome of a social
interaction, they lose.

One may find, say, that most people will only interact if they think
oneself will be in some way useful to them (in achieving something they
want); often it makes similar sense to treat them in turn (only
interacting so much as they have something useful to offer, ignoring
them otherwise). Seems to mostly minimize conflict this way.

Have noted though, if I make much attempt to explain a lot of this, they
seem to "flee in terror".

Granted, a deficiency in emotional perception, or a tendency to see most
social interactions in terms of "usefulness", does not mean I intend to
interact with them in ways that are "unfair" (as in, needlessly
detrimental to their own well-being for sake of my own).

Like, "the golden rule" is something I take seriously, and unlike some
other things, its application is not based on "some indecipherable soup
of subjective emotional experiences" (nor does it necessarily imply
needing to have any personal/subjective reason to care about them or
their well-being).

Well, and in-general, there is more benefit to trying to be on positive
terms with people, and trying to avoid treating them unfairly, than any
benefit from trying to "screw them over" (this being effectively the
social equivalent of a "foot gun"). Any potential near-term benefits
counter-balanced by a higher probability of things backfiring in the
future; ... And, most of what things I do want in life, are better
served by not acting like a selfish jerk, ...

Granted, I suspect I may be slightly atypical (even among people with
Aspergers') in these areas. Most don't seem to have the same sense of
emotional detachment.

Granted, I wasn't always this way (used to be more emotional when I was
younger), but it just sort of "fizzled out" for the most part...

My younger self had more issues with fear and anxiety, but anymore it is
seemingly mostly just an almost inescapable sense of apathy. Fleeting
emotions now and then, but nothing that one can really hold onto.

I had at times wondered if this was really alexithymia, or "something
different", but most externally visible criteria seem more in line with
alexithymia.

Ones' seeming holes in their emotional map may be concerning, but then
one may note that someone with the other condition is unlikely to care
that any such holes exist (or, if anything, more likely to see these
emotions at detrimental hinderances than for "trying to hold on to some
semblance of ones' humanity", say, in a society which seemingly judges
the value of ones' existence as a human on which emotions they may or
may not experience...).

Granted, brain scans or similar could potentially point out the
difference, but then one may wonder, "do they really want to know?"
(say, if the answer could mean that, much of the despise people often
throw their way is, in fact, merited...).

Then again, given I once did have more significant issues with fear and
social anxiety, does seem to imply that it is, in fact, alexithymia, and
not the other condition... (well, and apparently brain scans sometimes
have difficulty telling the two conditions apart even in the best case...).

Do still like nerding out about stuff though, which has at least
remained as a constant...

Well, and generally wanting the world to be a better place.

Does sort of all turn into a kind of a road-block for finding anyone
romantically compatible though; like trying to find someone who can deal
with my relative lack of emotion and general way of seeing things...

While at the same time not being hopelessly selfish (and more likely to
engage in wanton kleptomania or similar than commit to a
relationship...). Like, I wouldn't benefit from someone who is just
going to try to steal ones' crap and run off the moment things are no
longer convenient for them, that sucks...

Well, and, say, it not necessarily a good sign if one looks up pretty
much the only person that had a "semi passable" relationship with, and
all they can really find for whatever happened to them, was someone with
the same full name and DOB having apparently gone to prison for illegal
weapons trafficking or similar (well, say, in seeming contrast with her
almost Batman like views on crime, and seeming romanticism towards law
enforcement and similar). Then again, some of this is potentially a "red
flag" in itself.

>> Perhaps you should consider withdrawing from online interaction
>> until you are in a better position to be able to better
>> negotiate the inevitable ambiguities of online conversation.
>
> this means permanently and irrevocably terminating everything
> that i earn money from. i appreciate the suggestion: on the face
> of it, under "normal" circumstances, it sounds very reasonable,
> but the consequences of such withdrawal are so catastrophic
> for my life that for me it is simply not an option.
>
> put another way: would you suggest to someone who is blind,
> "you should quit working until you get your eyes replaced?"
>

Yeah.

Stuff one can't fix, one just has to deal with as it is.

One "still has to do crap" even if most people would rather just throw
crap in ones' way and try to keep them as far away as possible
(seemingly with even a glimpse into ones' own internal thoughts and
reasoning).

Would be easier to be like "just think of me like I am Mr. Spock or
something..." (like, the Vulcans in Star Trek seemingly being one of the
few positive portrayals of this sort of experience...).

>> I know plenty of people with Asperber's. Most learn how to
>> navigate normal social interactions.
>
> question for you: were any of them also subjected to 15 years
> of violent domestic verbal abuse?
>
> if you investigate further you'll likely find that those people
> at MIT with Asperger's came from extremely stable and loving
> family backgrounds. not all, but there will be a high correlation.
>
> l.

On Friday, September 8, 2023 at 5:15:56 PM UTC+1, Thomas Koenig wrote:

> I find them factual, informative and as non-flame-war-provoking
> as can be.

i'm touched and genuinely appreciate that.

On Friday, September 8, 2023 at 6:52:11 PM UTC+1, Thomas Koenig wrote:

> I watched it. Let me try to sum up the salient points, I think
> most comp.arch readers probably are aware of them.

almost certainly.

> If I got
> something wrong, please feel free to correct, own remarks
> in [brackets].
>
> The two main points you consider are binary compatibility and
> permute instructions, which need indices into registers.

permute, shuffle - anything that is *inter-element* dependent
rather than 100% paralleliseable of the form X[i] = MAP(Y[i], ....)
> The AVX* family of instructions suffers from having to invent
> separate instructions for each extension in number of registers
> and number of bits per register, resulting in a huge number of
> instructions.

and as a result retains 100% binary compatibility, as the regsizes&bits
increase, yes.
> IBM chose another path for POWER; they kept the number of register
> and bit size constant (hence ensuring binary compatibility) and
> went for multi-issue of instructions. If they wanted/needed to
> extend that, they would have to add additonal opcodes or prefixes
> [which amount to pretty much the same thing, IMHO].

correct.

> Cray and NEC SX-Aurora have fixed-size registers, so binary
> compatibility is ensured.

fixed-size registers *and* fixed-bit-width. imagine the furore
if Intel, for X86S, had proposed "oh yeah REX is going to get
*redefined* so that it now means 32 regs instead of 16",
they'd be laughed out of town.

> Where ARM SVE and RISC-V fail is the user-specifiable vector
> length.

ARM calls it "Silicon-Partner Scaling". the *implementor* (Licensee)
may choose the bit-width of the registers, yes... but
*under the same instructions*, not like the AVX* family where they
are all different instructions corresponding to different bit-widths.

> It is possible to use it with loops around the vector
> instructions, but permutations of vector elements are not possible
> using user-specified vector length - binary compatible code has to
> use the minimum size offerred, or silent data corruption will occur
> when permuting.

correct. which makes a mockery of the point of even having the
variable length.

> Is that a fair summary?

yes absolutely, thank you so much.

the silent data corruption is the worst offense. users of RVV have
been actively discouraged from even knowing or finding out what
the Vector bit-width actually is. SVE users are treating SVE as if
it was "a different version of NEON" (i.e. setting width to 128 and
getting on with it) only to find that performance is *worse* than
if they used NEON (this is due to immaturity of the SVE silicon,
there are typically QTY 2of NEON multi-issue whereas SVE
assumes QTY 1of and that "if you want faster you do bigger bitwidth
in silicon")

the only safe portable way to deal with shuffle/permute/index
under these circumstances is to *not* use the register-register
instructions at all, and use LD/ST.

which still does not in any way fix the problem of 100% requiring
a loop for every single damn algorithm.

making a bit-width minimum of 128 is... i throw my hands up in
the air at that one. 128-bit is 2-elements for 64-bit wide, 4-elements
for 32-bit wide, etc. etc. i mean come oooon, why the hell *do* that,
it makes life absolute hell for the programmer who naturally wants
to think in terms of "number of elements".

thank you once again Thomas.

l.

On Friday, September 8, 2023 at 2:07:17 PM UTC-5, luke.l...@gmail.com wrote:
> On Friday, September 8, 2023 at 5:15:56 PM UTC+1, Thomas Koenig wrote:
>
> > I find them factual, informative and as non-flame-war-provoking
> > as can be.
> i'm touched and genuinely appreciate that.
> On Friday, September 8, 2023 at 6:52:11 PM UTC+1, Thomas Koenig wrote:
>
> > I watched it. Let me try to sum up the salient points, I think
> > most comp.arch readers probably are aware of them.
> almost certainly.
> > If I got
> > something wrong, please feel free to correct, own remarks
> > in [brackets].
> >
> > The two main points you consider are binary compatibility and
> > permute instructions, which need indices into registers.
> permute, shuffle - anything that is *inter-element* dependent
> rather than 100% paralleliseable of the form X[i] = MAP(Y[i], ....)
> > The AVX* family of instructions suffers from having to invent
> > separate instructions for each extension in number of registers
> > and number of bits per register, resulting in a huge number of
> > instructions.
> and as a result retains 100% binary compatibility, as the regsizes&bits
> increase, yes.
> > IBM chose another path for POWER; they kept the number of register
> > and bit size constant (hence ensuring binary compatibility) and
> > went for multi-issue of instructions. If they wanted/needed to
> > extend that, they would have to add additonal opcodes or prefixes
> > [which amount to pretty much the same thing, IMHO].
> correct.
> > Cray and NEC SX-Aurora have fixed-size registers, so binary
> > compatibility is ensured.
> fixed-size registers *and* fixed-bit-width.
<
Fixed-element-count registers of fixed width each.
CRAY has 8-vector registers, of 64-elements, each register is 64-bits.
<
> imagine the furore
> if Intel, for X86S, had proposed "oh yeah REX is going to get
> *redefined* so that it now means 32 regs instead of 16",
> they'd be laughed out of town.
> > Where ARM SVE and RISC-V fail is the user-specifiable vector
> > length.
> ARM calls it "Silicon-Partner Scaling". the *implementor* (Licensee)
> may choose the bit-width of the registers, yes... but
> *under the same instructions*, not like the AVX* family where they
> are all different instructions corresponding to different bit-widths.
<
I think I shall go hide under a rock......
<
> > It is possible to use it with loops around the vector
> > instructions, but permutations of vector elements are not possible
> > using user-specified vector length - binary compatible code has to
> > use the minimum size offerred, or silent data corruption will occur
> > when permuting.
>
> correct. which makes a mockery of the point of even having the
> variable length.
> > Is that a fair summary?
> yes absolutely, thank you so much.
>
> the silent data corruption is the worst offense. users of RVV have
> been actively discouraged from even knowing or finding out what
> the Vector bit-width actually is. SVE users are treating SVE as if
> it was "a different version of NEON" (i.e. setting width to 128 and
> getting on with it) only to find that performance is *worse* than
> if they used NEON (this is due to immaturity of the SVE silicon,
> there are typically QTY 2of NEON multi-issue whereas SVE
> assumes QTY 1of and that "if you want faster you do bigger bitwidth
> in silicon")
<
Make that a big rock........
>
> the only safe portable way to deal with shuffle/permute/index
> under these circumstances is to *not* use the register-register
> instructions at all, and use LD/ST.
<
There is also VVM, which side steps all the "crap"; while remaining
upwards and backwards compatible.
>
> which still does not in any way fix the problem of 100% requiring
> a loop for every single damn algorithm.
>
> making a bit-width minimum of 128 is... i throw my hands up in
> the air at that one. 128-bit is 2-elements for 64-bit wide, 4-elements
> for 32-bit wide, etc. etc. i mean come oooon, why the hell *do* that,
> it makes life absolute hell for the programmer who naturally wants
> to think in terms of "number of elements".
>
> thank you once again Thomas.
>
> l.

In article <0d285519-3189-43f7-b0ec-695922e956ben@googlegroups.com>,
luke.leighton@gmail.com () wrote:

> > Where ARM SVE and RISC-V fail is the user-specifiable vector
> > length.
>
> ARM calls it "Silicon-Partner Scaling". the *implementor* (Licensee)
> may choose the bit-width of the registers, yes... but
> *under the same instructions*, not like the AVX* family where they
> are all different instructions corresponding to different
> bit-widths.

Presumably the instructions for getting data in and out of the vector
registers also adjust to the bit-width of the registers?

John

On Saturday, September 9, 2023 at 1:35:55 AM UTC+1, John Dallman wrote:

> Presumably the instructions for getting data in and out of the vector
> registers also adjust to the bit-width of the registers?

if you are used to predicated SIMD, RVV/Cray's "SETVL" instruction
creates a sequence of 1s of length VL, and combined with the
"settings" yes you end up with the ability to adjust in multiples.
SVE sets to a multiple of 128 up to 1024.

basically they literally *redefine* the instruction(s) to mean
totally different things on different implementations, which
ordinarily would lead to absolute chaos.

The "workaround" is to rely heavily on the "SETVL"
instruction combined with Looping (or SVE's equivalent
method), to say "uhn ok let the hardware tell us what
it's actually capable of, bit-width-wise", which sounds
great in theory but all goes to s*** when you dig deeper.

for anyone developing their own ISA, over the past 5
years i have come up with a few workarounds, if anyone's
interested (Agner?)

l.

jgd@cix.co.uk (John Dallman) writes:
>In article <0d285519-3189-43f7-b0ec-695922e956ben@googlegroups.com>,
>luke.leighton@gmail.com () wrote:
>
>> > Where ARM SVE and RISC-V fail is the user-specifiable vector
>> > length.
>>
>> ARM calls it "Silicon-Partner Scaling". the *implementor* (Licensee)
>> may choose the bit-width of the registers, yes... but
>> *under the same instructions*, not like the AVX* family where they
>> are all different instructions corresponding to different
>> bit-widths.
>
>Presumably the instructions for getting data in and out of the vector
>registers also adjust to the bit-width of the registers?
>

https://developer.arm.com/Architectures/Scalable%20Vector%20Extensions

On 9/8/2023 11:54 PM, luke.l...@gmail.com wrote:
> On Friday, September 8, 2023 at 7:16:05 PM UTC+1, BGB wrote:
>
>> Granted, I also have another condition (alexithymia), and relatively
>> limited perception of emotions. It seems to have settled into a state
>> where I can deal with (usual) social conflicts sort of OK by mostly "not
>> giving a crap".
>
> there's an area of your brain that remained plastic whilst young, for
> learning language. beyond that you end up using a *different* area,
> for foreign languages (where programming also sits, interestingly).
> point is: you *can* learn but it will always be "awkward", and i've found
> in hostile social environments they notice and think you're "faking"
> attempts to act in good faith.
>

I am not sure.

I think my coding abilities are mostly routed through a sort of
"visual-linguistic" pathway; seems to operate mostly in visual
representations and deals mostly with structure; but has almost no
concept of natural language semantics.

Natural language seems to be "routed" elsewhere, in a "slower" path that
partly aliases with auditory processing (text will have an auditory
echo, and things that are heard will gain subtitles).

The natural language pathway seems to be less reliable sometimes, and in
some cases (mostly during high stress when I was younger) it would start
acting up in a way where my ability to understand spoken language (or
speak) was hindered. This issue has mostly resolved itself.

> i had to look up alexithymia - very interesting that people in prison
> tend to suffer from it. and people in the military with PTSD.
> https://www.medicalnewstoday.com/articles/326451
>

It seems like the likely explanation in my case, and is fairly common
with ASD.

In terms of criteria, what I seem to have falls well more in line with
alexithymia.

At some points, I had worried that it might have potentially overlapped
to some extent with "high-functioning psychopathy".

It is seemingly partly a factor of "where one draws the lines in the
sand", and generally features seem to be more consistent with those
described for alexithymia than for psychopathy.

Like, I am well aware what it is like to experience fear and anxiety...
Even if potentially there are holes in some other parts of the emotional
map.

Granted, it is difficult enough to try to explain to many people what
ASD is exactly, so trying to explain the differences between alexithymia
and "high-functioning psychopathy" is likely a moot point.

Well, more so when it seems typical response from neurotypicals is to
express fear and distrust of anyone that doesn't have the same
psychology/worldview/emotional map as themselves. Potentially, trying to
categorize the differences is likely a moot point in this case.

And, I am not particularly inclined to fake normality mostly, as I see
it, this would be dishonest.

Particularly when interacting with females:
Anyone for whom the need to fake normality is necessary, would not be
compatible anyways (and in the end, any relationship which could result
would be effectively doomed);
What I want would not be served by trying to mimic normality.

Trying to keep up a partial facade of normality does make sense for
general social contexts (at least, enough to not scare people away, but
not so much as to be misleading; it is kind of a balance...).

>> One "still has to do crap" even if most people would rather just throw
>> crap in ones' way
>
> i am... so grateful you shared that this resonates with you.
>

My life has a lot of this...

>> Would be easier to be like "just think of me like I am Mr. Spock or
>> something..." (like, the Vulcans in Star Trek seemingly being one of the
>> few positive portrayals of this sort of experience...).
>
> Mr Data. except you can't have the Borg Queen control your emotion chip...
>

I suspect I have more in common with the Vulcans than with Mr. Data in
these areas.

But, yeah, it also works: Data did not need emotions to not act like a
jerk, whereas Lore did have emotions, and acted like a jerk as a result...

But, then again, I think the story was that the persona of Mr. Spock was
originally inspired by someone that Roddenberry knew, but was later
expanded to the whole society.

But, I guess one thing I had heard from people is the idea that people
need emotions as a "restraint" to not harm others or to not act selfishly.

Like, there isn't really an idea that a person might choose to do so for
more pragmatic reasons.
Granted... Without any "restraint", a person would be more able to
"change their mind" later and decide to act in a more hostile manner.

Granted, if one assumes that a person acts solely in terms with
maximizing their own self-interest, there are a number of scenarios
where "not good" behavior would be the expected result. Applying variant
cases of "the golden rule" do mostly address a lot of these, but one can
argue, there isn't any "purely pragmatic" reason why a person would
choose to impose the golden rule on themselves.

Optimizing for self-interest would not naturally lead to violent
behavior (which in most contexts has a higher probability of being
detrimental to ones' self-interest than to maximizing it), but would
often lead to scenarios where exploitative behavior and abandoning
people once they are no longer useful, would be expected.

Applying golden-rule style constraints does at least improve this, since
it would not be in ones' best interest to be on the receiving end of
exploitation or abandonment; so by extension, one should not do so to
others. At least, not without the consensus of both parties; otherwise
this can lead to various "deadlock scenarios", which are also not ideal.
Though, one can reduce this issue by adding "timeouts" or "fallback
criteria" to limit the number of deadlocks.

But, then one may find a need to adjust the rules as situations develop
to try to minimize problem cases, ...

For social interactions, trying to keep emotions mostly out of it does
have the benefit that one can more dynamically adjust to situations as
they develop (allowing one to minimize conflict and drama, which are
undesirable as I see it; particularly in situations where negative
outcomes are the most likely outcome).

Though, I have noted that the ability to "turn on a dime" in the case of
a social interaction is sometimes off-putting to some people (and can
apparently be shocking/surprising to bystanders as well, *). So, in some
contexts, even if the situation has already been updated, one needs to
fake an "emotional lag period" of, say, 30 seconds or so.

*: Say, even if talking to someone for which maintaining a facade of
emotionality is unnecessary, abrupt turns in sentiment or in contexts
where an emotionally-driven response are expected, can lead to "shock"
from other people who happen to be anywhere in the same general area.

Though, in the most recent example, the other person did so first (in a
way that fell well outside of neurotypical behavioral patterns), in
which case maintaining such a facade can be temporarily suspended. This
was when talking to someone who (I suspect) may be vaguely similar to
myself in some of these areas. Though, she hasn't said enough to really
know the specifics; but does seem to have the ability to "switch off"
neurotypical social behaviors whenever it is useful to do so (and talk
about things in a much more direct and impersonal style).

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).

....

But, I guess the other extreme is when one does get "invested" in
something, but then things get "casually thrown off". Say... When
someone steals ones' chair... Then the situation becoming the need to
maintain the flexibility needed to dynamically pick somewhere else to
sit (but, many NTs don't seem to get the idea that people with ASD don't
really appreciate when someone else sits in their usual spot).

Dealing with this sort of thing takes "actual effort" on my part...

....

In article <i50LM.1449504$GMN3.428754@fx16.iad>, scott@slp53.sl.home
(Scott Lurndal) wrote:
> jgd@cix.co.uk (John Dallman) writes:
> >Presumably the instructions for getting data in and out of the
> >vector registers also adjust to the bit-width of the registers?
> <https://developer.arm.com/Architectures/Scalable%20Vector%20Extensions>

Thanks, that makes sense now.

luke.leighton@gmail.com wrote:
> permute, shuffle - anything that is *inter-element* dependent
> rather than 100% paralleliseable of the form X[i] = MAP(Y[i], ....)

With you now. I wonder how they managed to design SVE without considering
this?

John

On Sunday, September 10, 2023 at 1:21:24 PM UTC+1, John Dallman wrote:

> luke.l...@gmail.com wrote:
> > permute, shuffle - anything that is *inter-element* dependent
> > rather than 100% paralleliseable of the form X[i] = MAP(Y[i], ....)
> With you now. I wonder how they managed to design SVE without considering
> this?

context: ARM is a Fabless Semi Design House that sells architectural licenses (the ISA) and implementation (HDL) licenses. they *don't* interface directly with end-users through Merchant Chips (unlike Intel and AMD). ARM's last ASIC i remember publicly was actually a collaboration with NEC (i think): a Dual-Core Cortex A9.

the majority of ARM's big paying Licensees are smartphone android / chromebook chromeos.

that in turn means that the *only thing of importance* to those big paying Licensees (AMlogic Allwinner TI RockChip) is, "does the Android port work"

therefore: if they deliver a Board Support Package that "just works", using SVE to accelerate Android's Java Runtime Interpreter, why the hell would they care what the SVE register width is within that *specific delivery* to their direct customer (their Licensee).

Native binary apps under Android are seriously discouraged: Platform-independent Java bytecode *is* the order-of-the-day. calling assember is possible but even less encouraged than native binary apps.

bottom line there is a massive disconnect that means they genuinely don't care, because binary interoperability is an *end-developer* problem typically exclusively on linux and BSD systems. and those end-developers have *no* contractual relationship with ARM in any way. not even close.

Agner this is a key insight to appreciate when developing these "Silicon-Partner-Scalable" Vector ISAs. the decision you made means that if you port Android and get the Java Runtime operational then the binary-interoperability is solved.

but as it stands the "Forwards-Compatibility" promise of ForwardCom is not true: it's "ony true if all current implementors promise never to create SMALLER regfile bitwidth implementations than any other prior implementor".

l.

On 9/10/2023 7:21 AM, John Dallman wrote:
> In article <i50LM.1449504$GMN3.428754@fx16.iad>, scott@slp53.sl.home
> (Scott Lurndal) wrote:
>> jgd@cix.co.uk (John Dallman) writes:
>>> Presumably the instructions for getting data in and out of the
>>> vector registers also adjust to the bit-width of the registers?
>> <https://developer.arm.com/Architectures/Scalable%20Vector%20Extensions>
>
>
> Thanks, that makes sense now.
>
> luke.leighton@gmail.com wrote:
>> permute, shuffle - anything that is *inter-element* dependent
>> rather than 100% paralleliseable of the form X[i] = MAP(Y[i], ....)
>
> With you now. I wonder how they managed to design SVE without considering
> this?
>

SVE (along with vector ISAs in general), seem like a notably poor fit
for a lot of my workloads, so not entirely sure how they are justified.

At least with an SSE/AVX or NEON, it is easier to figure out how it
could be usefully applied (which, admittedly, in my case is usually in
terms of using them to implement geometric vectors or similar).

Then sometimes one can be annoyed because, say:
SSE didn't add a Dot-Product operator until later on;
Pretty much none of these have a built-in cross-product or quaternion
multiply operator.

But... yeah, these ones are understandable (would be a pain to pull off
in hardware...).

In my case, it could possible to use a few more specialized combined
shuffle-op ops:
PMULSHX.F Xm, Xo, Imm11u, Xn
PADDSHX.F Xm, Xo, Imm11u, Xn

Which can reduce dot-product to a 2-op sequence (3 op if one includes a
final Binary32->Binary64 conversion), and cut-down on the number of
operations needed for a cross-product or quaternion multiply (these
exist as 64-bit encodings).

But, one could argue that dot and cross product aren't really common
enough to make these cases a high priority.

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).

Decided to leave out a bunch of stuff about the performance of math
related to the Blinn-Phong lighting model, and considerations for trying
to make stencil-based lighting/shadowing practical (at least in a
limited form) in my GL implementation (I am at present near the limits
of what is practical with a 16-bit color-buffer and Z-buffer, but going
32-bit here will roughly halve rasterizer performance, as clock-cycles
here are mostly dominated by memory-access to the color-buffer and
Z-buffer; whereas in this case, the textures can usually "mostly" fit
in-cache).

> John

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... :)

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

l.

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.

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.

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.

On Saturday, September 16, 2023 at 7:06:28 AM UTC-5, 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 -
<
VVM does SIMD without SIMD instructions; thus breaking that
1:1 relationship, and saving shiploads of instructions.
<
> 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.
>
> 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 Saturday, September 16, 2023 at 8:47:19 AM UTC-5, Thomas Koenig wrote:
> luke.l...@gmail.com <luke.l...@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.
<
But Luke's point is well taken--modern architectures (post RISC
generation 1) have not followed suit and new computer architects
rarely get into a position where they can exploit those kinds of things
without massive push back.