No, not at all.

One thing, though, should be noted. I think that even the original Cray-I had
data forwarding - so that if a vector instruction was followed by another vector
instruction that operated on its result, and which used a different ALU that was
available, that second instruction started before the first instruction completed
working on the whole vector.

So conventional vector operations don't have to have the flaw that VVM
addresses.

In fact, in my original Concertina architecture, I believe I stole that idea. If you
look at that architecture, though, you might not see it. It has long vectors
and short vectors. Long vectors are conventional Cray-I style, and short
vectors are conventional MMX/SSE/AVX style. Neither one is anything like
VVM.

So where did I steal VVM?

Elsewhere, I have what I refer to as "dataflow instructions". *This* is
where I conceptualized something like VVM as belonging. That's where I
define a series of operations that work on one operand at a time, but are
chained together, with input arrays and output arrays defined for it.

So absolutely I recognized that since one can put multiple ALUs on a chip,
there ought to be a way to directly specify an operation that keeps them
all busy for a while. But I put that in a separate category from conventional vector instructions, which I also saw as useful.

John Savard

On Sunday, September 5, 2021 at 6:37:43 AM UTC-6, Quadibloc wrote:

> Elsewhere, I have what I refer to as "dataflow instructions".

I thought I did, but I see that, no, I hadn't gotten that far. The Extended
Translate Instructions don't quite qualify.

John Savard

> One thing, though, should be noted. I think that even the original Cray-I had
> data forwarding -

I believe the official name for it is "chaining".

Stefan

On Sunday, September 5, 2021 at 7:37:43 AM UTC-5, Quadibloc wrote:
> No, not at all.
>
> One thing, though, should be noted. I think that even the original Cray-I had
> data forwarding - so that if a vector instruction was followed by another vector
> instruction that operated on its result, and which used a different ALU that was
> available, that second instruction started before the first instruction completed
> working on the whole vector.
<
The CRAY-1 had a "chain slot" and if the subsequent instruction was ready to
"go" by the time the chain slot rolled around, the 2 instructions forwarded data
and ran "as one" until the end of the vector arrived.
<
The CRAY-1 X/MP solved this problem and could forward on/at any cycle after
the data arrived. This machine also had 3 AGEN ports to memory per cycle.
>
> So conventional vector operations don't have to have the flaw that VVM
> addresses.
>
> In fact, in my original Concertina architecture, I believe I stole that idea. If you
> look at that architecture, though, you might not see it. It has long vectors
> and short vectors. Long vectors are conventional Cray-I style, and short
> vectors are conventional MMX/SSE/AVX style. Neither one is anything like
> VVM.
>
> So where did I steal VVM?
>
> Elsewhere, I have what I refer to as "dataflow instructions". *This* is
> where I conceptualized something like VVM as belonging. That's where I
> define a series of operations that work on one operand at a time, but are
> chained together, with input arrays and output arrays defined for it.
<
You don't need to consider VVM as "dataflow" instructions, you can just
as easily consider this simply a means to perform several iterations of
a loop simultaneously.
>
> So absolutely I recognized that since one can put multiple ALUs on a chip,
> there ought to be a way to directly specify an operation that keeps them
> all busy for a while. But I put that in a separate category from conventional vector instructions, which I also saw as useful.
>
> John Savard

On Sunday, September 5, 2021 at 11:21:52 AM UTC-6, MitchAlsup wrote:

> You don't need to consider VVM as "dataflow" instructions, you can just
> as easily consider this simply a means to perform several iterations of
> a loop simultaneously.

That's true enough, but I hope I've made my point clear: while I was perfectly
satisfied with conventional vector instructions as a way to perform operations
on vectors... I do also see the value of a mechanism that somewhat resembles
VVM, where one specifies input vectors and output vectors - and then associates
with them multiple operations, linked to each other in code that doesn't look too
much different from a conventional loop.

But the value I see in such a mechanism is primarily as a tool to make use of
dataflow-style hardware, if available on the CPU. Not as a better way to do
"ordinary" vector arithmetic.

Now, I may have conceptualized this wrong, or I'm working in a direction that
really hasn't much to do with your goals with VVM.

John Savard

On 06/09/2021 03:54, Quadibloc wrote:
> On Sunday, September 5, 2021 at 11:21:52 AM UTC-6, MitchAlsup wrote:
>
>> You don't need to consider VVM as "dataflow" instructions, you can just
>> as easily consider this simply a means to perform several iterations of
>> a loop simultaneously.
>
> That's true enough, but I hope I've made my point clear: while I was perfectly
> satisfied with conventional vector instructions as a way to perform operations
> on vectors... I do also see the value of a mechanism that somewhat resembles
> VVM, where one specifies input vectors and output vectors - and then associates
> with them multiple operations, linked to each other in code that doesn't look too
> much different from a conventional loop.
>
> But the value I see in such a mechanism is primarily as a tool to make use of
> dataflow-style hardware, if available on the CPU. Not as a better way to do
> "ordinary" vector arithmetic.
>
> Now, I may have conceptualized this wrong, or I'm working in a direction that
> really hasn't much to do with your goals with VVM.

Pardon my ignorance, but what is VVM in computing?

I've googled and come up with the Visual Virtual Machine which appears
to be a didactic thing, and cannot possibly be what is discussed above?

gareth evans <headstone255@yahoo.com> writes:
>Pardon my ignorance, but what is VVM in computing?

Mitch Alsup's Virtual Vector M. Not sure whether M stands for method,
machine, or something else.

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

Anton Ertl [2021-09-06 13:26:32] wrote:
> gareth evans <headstone255@yahoo.com> writes:
>>Pardon my ignorance, but what is VVM in computing?
> Mitch Alsup's Virtual Vector M. Not sure whether M stands for method,
> machine, or something else.

M..itch?

Stefan

On Monday, September 6, 2021 at 5:24:28 PM UTC+3, Stefan Monnier wrote:
> Anton Ertl [2021-09-06 13:26:32] wrote:
> > gareth evans <headst...@yahoo.com> writes:
> >>Pardon my ignorance, but what is VVM in computing?
> > Mitch Alsup's Virtual Vector M. Not sure whether M stands for method,
> > machine, or something else.
> M..itch?
>
>
> Stefan

Mitch thinks that it stands for "Mode", but reality is like you said.

On Monday, September 6, 2021 at 4:49:33 AM UTC-6, gareth evans wrote:

> Pardon my ignorance, but what is VVM in computing?

Oops, must have been crossposted. Virtual Vector Method refers to
something Mitch Alsup has devised in his personal architectural
projects.

John Savard

On 9/6/2021 3:49 AM, gareth evans wrote:
> On 06/09/2021 03:54, Quadibloc wrote:
>> On Sunday, September 5, 2021 at 11:21:52 AM UTC-6, MitchAlsup wrote:
>>
>>> You don't need to consider VVM as "dataflow" instructions, you can just
>>> as easily consider this simply a means to perform several iterations of
>>> a loop simultaneously.
>>
>> That's true enough, but I hope I've made my point clear: while I was
>> perfectly
>> satisfied with conventional vector instructions as a way to perform
>> operations
>> on vectors... I do also see the value of a mechanism that somewhat
>> resembles
>> VVM, where one specifies input vectors and output vectors - and then
>> associates
>> with them multiple operations, linked to each other in code that
>> doesn't look too
>> much different from a conventional loop.
>>
>> But the value I see in such a mechanism is primarily as a tool to make
>> use of
>> dataflow-style hardware, if available on the CPU. Not as a better way
>> to do
>> "ordinary" vector arithmetic.
>>
>> Now, I may have conceptualized this wrong, or I'm working in a
>> direction that
>> really hasn't much to do with your goals with VVM.
>
> Pardon my ignorance, but what is VVM in computing?

It seems you are new around here. Welcome!

VVM is Virtual Vector Method, a feature of a CPU that frequent poster
Mitch Alsup is designing. Briefly, it is new way to implement the
functionality of vector handling without all the "mess" of SIMD
instructions. IMHO it has many very nice features.

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

On Sunday, September 5, 2021 at 9:54:16 PM UTC-5, Quadibloc wrote:
> On Sunday, September 5, 2021 at 11:21:52 AM UTC-6, MitchAlsup wrote:
>
> > You don't need to consider VVM as "dataflow" instructions, you can just
> > as easily consider this simply a means to perform several iterations of
> > a loop simultaneously.
<
> That's true enough, but I hope I've made my point clear: while I was perfectly
> satisfied with conventional vector instructions as a way to perform operations
> on vectors...
<
Only for a brief time around 1980 was I satisfied with CRAY-like vectors.
Only for a brief time around 2002 was I satisfied with SIMD-like vectors.
<
> I do also see the value of a mechanism that somewhat resembles
> VVM, where one specifies input vectors and output vectors - and then associates
> with them multiple operations, linked to each other in code that doesn't look too
> much different from a conventional loop.
>
> But the value I see in such a mechanism is primarily as a tool to make use of
> dataflow-style hardware, if available on the CPU. Not as a better way to do
> "ordinary" vector arithmetic.
<
While the tool does highly leverage the resources used to fire instructions into
execution data-flow style, it was not developed directly to utilize those. That
fell out for free.
>
> Now, I may have conceptualized this wrong, or I'm working in a direction that
> really hasn't much to do with your goals with VVM.
<
VVM started life as a means to allow a 1-wide in order machine to match the
average performance of GBOoO machines when performing small loops.
>
> John Savard

On Monday, September 6, 2021 at 8:27:58 AM UTC-5, Anton Ertl wrote:
> gareth evans <headst...@yahoo.com> writes:
> >Pardon my ignorance, but what is VVM in computing?
> Mitch Alsup's Virtual Vector M. Not sure whether M stands for method,
> machine, or something else.
<
Method.
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Monday, September 6, 2021 at 9:24:28 AM UTC-5, Stefan Monnier wrote:
> Anton Ertl [2021-09-06 13:26:32] wrote:
> > gareth evans <headst...@yahoo.com> writes:
> >>Pardon my ignorance, but what is VVM in computing?
> > Mitch Alsup's Virtual Vector M. Not sure whether M stands for method,
> > machine, or something else.
> M..itch?
<
LoL
>
>
> Stefan