Ivan Godard <ivan@millcomputing.com> wrote:
> On 7/7/2021 4:14 PM, Brett wrote:
>> Ivan Godard <ivan@millcomputing.com> wrote:
>>> On 7/6/2021 1:04 AM, Brett wrote:
>
> <snip>
>
>>>> You also have compiler issues, which makes handling more belts difficult.
>>>> It is easy to say that one bank should be used for globals and thus rarely
>>>> rotate, another for addressing and others for compute, but convincing a
>>>> compiler to do something intelligent is really hard.
>>>
>>> There's only one belt at present. Rather than two belts, just configure
>>> a belt twice as big.
>>>
>>>> A loop has a limited number of dependent compute chains, it should be
>>>> possible to just randomly assign opcode chains to belts. Filling belts
>>>> roughly evenly over time.
>>>
>>> Too much fanout in open code, although FP codes are better; you would
>>> wind up doing a lot of inter-belt transfers because the dataflow is
>>> tree-like rather than linear.
>>
>> Integer trees are so short they are forks. No arch can help such junk.
>> Addressing is linear and makes up a third of the ops.
>
> To simplify an example:
> source: a+b+c+d
> breadth-first: (a+b)+(c+d) 2 cycles, max belt live load 2
> depth-first: (a+(b+(c+d))) 3 cycles, max belt live load 1
>
> constraints:
> belt live load cannot exceed belt length;
> belt delta (distance in drops between producer and consumer) cannot
> exceed belt length without rescue or spill/fill
> no NP
>
> BTW, a graph-coloring register allocator is also NP.
>
>
>>>> You have some secrete sauce still I bet to get to 32 ops a cycle, how you
>>>> handle vector support spreading across units? Etc. Maybe you have lots of
>>>> belts hiding under the virtual belt, and thus are doing what I am
>>>> suggesting.
>>>
>>> Nope. Remember, the belt is a naming device, not a shift register.
>>
>> It can be hard to wrap ones brain around doing 32 ops a cycle when you have
>> 16 belt registers.
>
> Not possible, unless the op arguments were shared from 16 available and
> all had 16 or fewer drops total (neglecting phasing). As a rule of
> thumb, a Mill member is configured such that <slot count> == <belt
> length>. The larger members (Gold has 32 belt length) rarely need to
> rescue, although they may have occasional obligatory spills, while
> smaller ones (Copper has 8 belt length) are replete with rescues on the
> same code.

Thanks.

Copper is smaller than Silver and Gold due to fewer ALU’s and load/store
units etc.
But do you really have to break the API by having fewer belt entries?

A small bank of registers would enable Silver to run Gold code at mostly
half speed, occasionally it might hit a resource constraint that cost three
cycles instead of two.
But no one is going to care about a 5% loss, and if they do they can
compile for the right chip which will schedule better for that chip.

Detecting a resource oversubscription and splitting at that opcode is not
hard.
The big die use issue might be the decoder and not the belt length.

With Copper things get more difficult, but last I heard you were not going
to make that chip. And that chip is in a different market, so it can
support a different API.

I can easily see customers wanting a Silver+ that can run Gold code over
the slightly smaller real Silver. Debugging and testing code twice gives
programers hives.

>> An 8 way unroll with lots of ALU’s can pull this off.
>
> Nope.
>
>> Which means that after your virtual belt get translated to operations you
>> have lots of little independent chains which are little belts. Most call
>> this OoO, but you can order the opcodes sequentially, but doing so is not
>> belt friendly as each data step is 8 opcodes away on a 8 way unroll.
>
> Software pipelining rather than unroll, but yes: the belt must be long
> enough to hold the un-piped placement times the piping.In practical
> configs the constraint to piping limiting factor is the number of FUs
> you have of whatever is the most constraining kind. If your loop body
> has a multiply and you have two multipliers you can't pipe it into a
> single 3-pipe bundle.

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>On 7/8/2021 10:20 AM, Anton Ertl wrote:
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>> Yes, another solution to the problem. It has the advantage of not
>>> requiring the HW to have a specific hardware defined amount of dedicated
>>> memory. It's disadvantage is that you are "wasting" some amount of HW
>>> (the tags, etc. for the locked lines)
>>
>> If you want to lock lines that are not in a hardware-defined subset of
>> the address space, the tags are not wasted.
>
>I probably wasn't clear. I know that you need the tags for the locked
>lines, but if you used dedicated memory instead of a cache, then you
>don't need tags, etc. for the dedicated memory.

Yes, but that dedicated memory is in a hardware-defined subset of the
address space, and the software has to do special things to deal with
that.

If the dedicated memory is at the L1 level, it's in the virtual
address space (no time for virtual->physical translation), and
probably shared between all processes running on this core. The
additional hardware of the cache does provide a significant benefit
even if you don't evict some of the lines.

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

On 7/8/2021 11:16 PM, Brett wrote:
> Ivan Godard <ivan@millcomputing.com> wrote:
>> On 7/7/2021 4:14 PM, Brett wrote:
>>> Ivan Godard <ivan@millcomputing.com> wrote:
>>>> On 7/6/2021 1:04 AM, Brett wrote:
>>
>> <snip>
>>
>>>>> You also have compiler issues, which makes handling more belts difficult.
>>>>> It is easy to say that one bank should be used for globals and thus rarely
>>>>> rotate, another for addressing and others for compute, but convincing a
>>>>> compiler to do something intelligent is really hard.
>>>>
>>>> There's only one belt at present. Rather than two belts, just configure
>>>> a belt twice as big.
>>>>
>>>>> A loop has a limited number of dependent compute chains, it should be
>>>>> possible to just randomly assign opcode chains to belts. Filling belts
>>>>> roughly evenly over time.
>>>>
>>>> Too much fanout in open code, although FP codes are better; you would
>>>> wind up doing a lot of inter-belt transfers because the dataflow is
>>>> tree-like rather than linear.
>>>
>>> Integer trees are so short they are forks. No arch can help such junk.
>>> Addressing is linear and makes up a third of the ops.
>>
>> To simplify an example:
>> source: a+b+c+d
>> breadth-first: (a+b)+(c+d) 2 cycles, max belt live load 2
>> depth-first: (a+(b+(c+d))) 3 cycles, max belt live load 1
>>
>> constraints:
>> belt live load cannot exceed belt length;
>> belt delta (distance in drops between producer and consumer) cannot
>> exceed belt length without rescue or spill/fill
>> no NP
>>
>> BTW, a graph-coloring register allocator is also NP.
>>
>>
>>>>> You have some secrete sauce still I bet to get to 32 ops a cycle, how you
>>>>> handle vector support spreading across units? Etc. Maybe you have lots of
>>>>> belts hiding under the virtual belt, and thus are doing what I am
>>>>> suggesting.
>>>>
>>>> Nope. Remember, the belt is a naming device, not a shift register.
>>>
>>> It can be hard to wrap ones brain around doing 32 ops a cycle when you have
>>> 16 belt registers.
>>
>> Not possible, unless the op arguments were shared from 16 available and
>> all had 16 or fewer drops total (neglecting phasing). As a rule of
>> thumb, a Mill member is configured such that <slot count> == <belt
>> length>. The larger members (Gold has 32 belt length) rarely need to
>> rescue, although they may have occasional obligatory spills, while
>> smaller ones (Copper has 8 belt length) are replete with rescues on the
>> same code.
>
> Thanks.
>
> Copper is smaller than Silver and Gold due to fewer ALU’s and load/store
> units etc.
> But do you really have to break the API by having fewer belt entries?
>
> A small bank of registers would enable Silver to run Gold code at mostly
> half speed, occasionally it might hit a resource constraint that cost three
> cycles instead of two.
> But no one is going to care about a 5% loss, and if they do they can
> compile for the right chip which will schedule better for that chip.
>
> Detecting a resource oversubscription and splitting at that opcode is not
> hard.
> The big die use issue might be the decoder and not the belt length.
>
> With Copper things get more difficult, but last I heard you were not going
> to make that chip. And that chip is in a different market, so it can
> support a different API.
>
> I can easily see customers wanting a Silver+ that can run Gold code over
> the slightly smaller real Silver. Debugging and testing code twice gives
> programers hives.
>

Mill distinguishes the "distribution binary" called genAsm from the
"execution binary" called conAsm. It is not expected that customers will
program or debug in conAsm. Language with VMs such as Java use the same
approach.

Family members cannot execute each others' conAsm; static scheduling
precludes it. This doesn't break the API - the API is genAsm, which is
member-independent.

On 2021-07-09, Ivan Godard wrote:
> On 7/8/2021 11:16 PM, Brett wrote:

[snip]

>> I can easily see customers wanting a Silver+ that can run Gold code over
>> the slightly smaller real Silver. Debugging and testing code twice gives
>> programers hives.
>>
>
> Mill distinguishes the "distribution binary" called genAsm from the
> "execution binary" called conAsm. It is not expected that customers will
> program or debug in conAsm. Language with VMs such as Java use the same
> approach.
>
> Family members cannot execute each others' conAsm; static scheduling
> precludes it. This doesn't break the API - the API is genAsm, which is
> member-independent.

Ah that's news to me, and it makes sense.

I'm curious: What is the plan regarding binary distribution? Say, if you
want to run something like Linux and have a package manager/format like
DPKG, RPM or APK (Android) to distribute pre-compiled applications:

* Would those packages contain genAsm?

* Where would the translation from genAsm->conAsm happen? At the kernel
level, as part of the dynamic linker, as part of the package
installer, or something else?

Also, how complex is the translation from genAsm to conAsm?

/Marcus

On 7/9/2021 6:22 AM, Marcus wrote:
> On 2021-07-09, Ivan Godard wrote:
>> On 7/8/2021 11:16 PM, Brett wrote:
>
> [snip]
>
>>> I can easily see customers wanting a Silver+ that can run Gold code over
>>> the slightly smaller real Silver. Debugging and testing code twice gives
>>> programers hives.
>>>
>>
>> Mill distinguishes the "distribution binary" called genAsm from the
>> "execution binary" called conAsm. It is not expected that customers
>> will program or debug in conAsm. Language with VMs such as Java use
>> the same approach.
>>
>> Family members cannot execute each others' conAsm; static scheduling
>> precludes it. This doesn't break the API - the API is genAsm, which is
>> member-independent.
>
> Ah that's news to me, and it makes sense.
>
> I'm curious: What is the plan regarding binary distribution? Say, if you
> want to run something like Linux and have a package manager/format like
> DPKG, RPM or APK (Android) to distribute pre-compiled applications:
>
> * Would those packages contain genAsm?
>
> * Where would the translation from genAsm->conAsm happen? At the kernel
>   level, as part of the dynamic linker, as part of the package
>   installer, or something else?
>
> Also, how complex is the translation from genAsm to conAsm?
>
> /Marcus

Packages are expected to always distribute in genAsm. Boot images and
ROMs must be in conAsm and exist in multiple per-member instances;
that's common in other systems too - what you do to bring up the
hardware is not usually backwards compatible. The boot ROM contains a
minimal specializer in conAsm, hosted on and targeting to its chip. A
smarter specializer, in genAsm, is in the OS install: bringing up bare
metal replaces the ROM specializer with the result of specializing the
install specializer, and then of itself.

The object module starts out in genAsm. The specializer caches its
result into the module at install or first execute time, so subsequent
executions do not need to respeciaize for that target. The same genAsm
may be specialized, and cached, for several target members, so it
appears to the user that the one package file runs on all targets.

The tool chain produces genAsm from the source, and can go on to also
generate conAsm for the native host into that file too; that's the usual
edit-compile-codegen-link-run sequence. Cross-development works in the
obvious way. Target-independent distribution packages are expected to
specialize as part of install, but if not the loader will do it if it
doesn't find an image for the target in the cache in the load module.

Specialization is much like any compile back-end code generation step.
Command-line options determine how much work it puts into optimizing the
code. All the traditional target-independent optimization are done by
the compiler middle-end, as in regular compilation, so what's left is
just Mill-specific things like belt scheduling. Of course, register
allocation, which is the bugbear of back-ends, is not a Mill concern.

On Friday, July 9, 2021 at 2:40:16 PM UTC-6, Ivan Godard wrote:

> Packages are expected to always distribute in genAsm. Boot images and
> ROMs must be in conAsm and exist in multiple per-member instances;
> that's common in other systems too - what you do to bring up the
> hardware is not usually backwards compatible.

In that case, the fact that

> The tool chain produces genAsm from the source, and can go on to also
> generate conAsm for the native host into that file too; that's the usual
> edit-compile-codegen-link-run sequence.

is obviously a very good thing. If the tool chain could not generate - and,
indeed, _cross-compile_, conAsm, then there would be a problem producing
boot ROMs.

But I shouldn't be surprised that you've thought of, and made provision for,
something so obvious as that. Rather, the fact that I even consider this
worthy of mention is just to note that having a separate conAsm and
genAsm is... potentially dangerous. At least, you haven't succumbed to
the temptation to make conAsm secret and proprietary so that people making
Mill systems could only use the boot ROMs that you supply, or any other
stunt like that - that would discourage adoption, but just the mere _existence_
of conAsm versus genAsm may 'spook' a market that has been... traumatized...
by the past behavior of giants like Intel and Microsoft.

They're not trusting out there. "Paranoid" is closer to the right word.

John Savard

On 7/9/2021 3:26 PM, Quadibloc wrote:
> On Friday, July 9, 2021 at 2:40:16 PM UTC-6, Ivan Godard wrote:
>
>> Packages are expected to always distribute in genAsm. Boot images and
>> ROMs must be in conAsm and exist in multiple per-member instances;
>> that's common in other systems too - what you do to bring up the
>> hardware is not usually backwards compatible.
>
> In that case, the fact that
>
>> The tool chain produces genAsm from the source, and can go on to also
>> generate conAsm for the native host into that file too; that's the usual
>> edit-compile-codegen-link-run sequence.
>
> is obviously a very good thing. If the tool chain could not generate - and,
> indeed, _cross-compile_, conAsm, then there would be a problem producing
> boot ROMs.
>
> But I shouldn't be surprised that you've thought of, and made provision for,
> something so obvious as that. Rather, the fact that I even consider this
> worthy of mention is just to note that having a separate conAsm and
> genAsm is... potentially dangerous. At least, you haven't succumbed to
> the temptation to make conAsm secret and proprietary so that people making
> Mill systems could only use the boot ROMs that you supply, or any other
> stunt like that - that would discourage adoption, but just the mere _existence_
> of conAsm versus genAsm may 'spook' a market that has been... traumatized...
> by the past behavior of giants like Intel and Microsoft.
>
> They're not trusting out there. "Paranoid" is closer to the right word.
>
> John Savard
>

Neither genAsm nor the various conAsms are secret. We expect to publish
the various conAsm development tools that we use ourselves. For example,
I have occasionally shown here our conAsm hex dump/analysis tool output.
As a chip vendor, we would be delighted to have people to use them to
(for example) do their own ROMs.

As for whether customers will be paranoid about gen/conAsm why would
they be? They seem to have no problem with (for example) Java VM code as
a distribution format, and a JIT producing binary across differing
binary ISAs. Mill is no different.

However, even those who want to do their own ROM are extremely unlikely
to need or want to do anything in conAsm. It is near impossible to
manually write anything significant in conAsm - this is not a machine
wherein you drop into writing assembler for the fun of it. About the
only people who ever deal with conAsm are the people who maintain the
specializer. Our own boot ROM will be wholly written in C++, published
in source and cross-built for the target family member. Goose it all you
want :-)

On Friday, July 9, 2021 at 6:48:53 PM UTC-5, Ivan Godard wrote:
> On 7/9/2021 3:26 PM, Quadibloc wrote:
> > On Friday, July 9, 2021 at 2:40:16 PM UTC-6, Ivan Godard wrote:
> >
> >> Packages are expected to always distribute in genAsm. Boot images and
> >> ROMs must be in conAsm and exist in multiple per-member instances;
> >> that's common in other systems too - what you do to bring up the
> >> hardware is not usually backwards compatible.
> >
> > In that case, the fact that
> >
> >> The tool chain produces genAsm from the source, and can go on to also
> >> generate conAsm for the native host into that file too; that's the usual
> >> edit-compile-codegen-link-run sequence.
> >
> > is obviously a very good thing. If the tool chain could not generate - and,
> > indeed, _cross-compile_, conAsm, then there would be a problem producing
> > boot ROMs.
> >
> > But I shouldn't be surprised that you've thought of, and made provision for,
> > something so obvious as that. Rather, the fact that I even consider this
> > worthy of mention is just to note that having a separate conAsm and
> > genAsm is... potentially dangerous. At least, you haven't succumbed to
> > the temptation to make conAsm secret and proprietary so that people making
> > Mill systems could only use the boot ROMs that you supply, or any other
> > stunt like that - that would discourage adoption, but just the mere _existence_
> > of conAsm versus genAsm may 'spook' a market that has been... traumatized...
> > by the past behavior of giants like Intel and Microsoft.
> >
> > They're not trusting out there. "Paranoid" is closer to the right word.
> >
> > John Savard
> >
> Neither genAsm nor the various conAsms are secret. We expect to publish
> the various conAsm development tools that we use ourselves. For example,
> I have occasionally shown here our conAsm hex dump/analysis tool output.
> As a chip vendor, we would be delighted to have people to use them to
> (for example) do their own ROMs.
>
> As for whether customers will be paranoid about gen/conAsm why would
> they be? They seem to have no problem with (for example) Java VM code as
> a distribution format, and a JIT producing binary across differing
> binary ISAs. Mill is no different.
>
> However, even those who want to do their own ROM are extremely unlikely
> to need or want to do anything in conAsm. It is near impossible to
> manually write anything significant in conAsm - this is not a machine
> wherein you drop into writing assembler for the fun of it.
<
My 66000 is the one to choose if you want to drop into ASM for the fun of it.......
<
> About the
> only people who ever deal with conAsm are the people who maintain the
> specializer. Our own boot ROM will be wholly written in C++, published
> in source and cross-built for the target family member. Goose it all you
> want :-)

On Friday, July 9, 2021 at 6:02:22 PM UTC-6, MitchAlsup wrote:
> On Friday, July 9, 2021 at 6:48:53 PM UTC-5, Ivan Godard wrote:

> > However, even those who want to do their own ROM are extremely unlikely
> > to need or want to do anything in conAsm. It is near impossible to
> > manually write anything significant in conAsm - this is not a machine
> > wherein you drop into writing assembler for the fun of it.

> My 66000 is the one to choose if you want to drop into ASM for the fun of it.......

I'll remember that. Of course, that also makes it clear that despite
competing with the Mill 'a little' due to the inclusion of conventional
DSP features - I don't view that as _really_ competing with the Mill,
since DSPs already exist, and that didn't make the Mill irrelevant or
unnecessary - perhaps your 66000 is what I'm "really" competing with.

Although I don't really entertain too much in the way of hope that
any Concertina architecture will get to silicon - I'm still at a very early
design stage as well - though, I do know what I really intend to compete
with.

At the moment, ARM and RISC-V are the biggest challengers to x86-64.

I feel that they're... missing stuff... and so while if either of them did
come to prominence, it would be an improvement on the x86, but some
problems would remain. Unfortunately, IBM has declined to aggressively
promote z/Architecture as the computing platform of the future, choosing
instead the dead-end strategy of milking the few legacy customers who
need it.

So I'm trying to create a better replacement for x86 that isn't missing stuff.

I can understand that you might disapprove, as many will feel that the
stuff I regard as 'missing' is in fact useless wretched excess.

John Savard

> But I shouldn't be surprised that you've thought of, and made provision for,
> something so obvious as that. Rather, the fact that I even consider this
> worthy of mention is just to note that having a separate conAsm and
> genAsm is... potentially dangerous. At least, you haven't succumbed to
> the temptation to make conAsm secret and proprietary so that people making
> Mill systems could only use the boot ROMs that you supply, or any other
> stunt like that - that would discourage adoption, but just the mere _existence_

I don't think that's a serious issue, to be honest (e.g. I don't think
it was a serious issue for Transmeta, for example).

The more problematic case is when you want to migrate a task to another
host, in which case copper/silver/gold will probably have to be
considered as being different ISAs.

For the same reason, you're probably going to have trouble making a Mill
with a "BIG.little" kind of setup since moving a process from/to a BIG
to/from a little core will be difficult.

[ Whether such BIG.little setup are really important is of course
another question. ]

Stefan

On 7/9/2021 7:45 PM, Stefan Monnier wrote:
>> But I shouldn't be surprised that you've thought of, and made provision for,
>> something so obvious as that. Rather, the fact that I even consider this
>> worthy of mention is just to note that having a separate conAsm and
>> genAsm is... potentially dangerous. At least, you haven't succumbed to
>> the temptation to make conAsm secret and proprietary so that people making
>> Mill systems could only use the boot ROMs that you supply, or any other
>> stunt like that - that would discourage adoption, but just the mere _existence_
>
> I don't think that's a serious issue, to be honest (e.g. I don't think
> it was a serious issue for Transmeta, for example).
>
> The more problematic case is when you want to migrate a task to another
> host, in which case copper/silver/gold will probably have to be
> considered as being different ISAs.
>
> For the same reason, you're probably going to have trouble making a Mill
> with a "BIG.little" kind of setup since moving a process from/to a BIG
> to/from a little core will be difficult.
>
> [ Whether such BIG.little setup are really important is of course
> another question. ]
>
>
> Stefan
>

That's been a question for us, too. There's no problem if the bigs and
littles serve different function: a little as a control processor say,
with bigs as workers. Chips doing that use mixed ISA cores commonly now.

But you are right that actual migration is an issue. Conceivably one
could checkpoint and then do a resume on a different core; the app data
would go fine, and I can see resuming from a known code point that was
specialized to not have anything in flight. But interpreting the control
stack and spiller state would not be easy and and would require software
IMO.

On Friday, July 9, 2021 at 7:29:22 PM UTC-5, Quadibloc wrote:
> On Friday, July 9, 2021 at 6:02:22 PM UTC-6, MitchAlsup wrote:
> > On Friday, July 9, 2021 at 6:48:53 PM UTC-5, Ivan Godard wrote:
>
> > > However, even those who want to do their own ROM are extremely unlikely
> > > to need or want to do anything in conAsm. It is near impossible to
> > > manually write anything significant in conAsm - this is not a machine
> > > wherein you drop into writing assembler for the fun of it.
>
> > My 66000 is the one to choose if you want to drop into ASM for the fun of it.......
> I'll remember that. Of course, that also makes it clear that despite
> competing with the Mill 'a little' due to the inclusion of conventional
> DSP features - I don't view that as _really_ competing with the Mill,
> since DSPs already exist, and that didn't make the Mill irrelevant or
> unnecessary - perhaps your 66000 is what I'm "really" competing with.
>
> Although I don't really entertain too much in the way of hope that
> any Concertina architecture will get to silicon - I'm still at a very early
> design stage as well - though, I do know what I really intend to compete
> with.
>
> At the moment, ARM and RISC-V are the biggest challengers to x86-64.
>
> I feel that they're... missing stuff... and so while if either of them did
> come to prominence, it would be an improvement on the x86, but some
> problems would remain. Unfortunately, IBM has declined to aggressively
> promote z/Architecture as the computing platform of the future, choosing
> instead the dead-end strategy of milking the few legacy customers who
> need it.
>
> So I'm trying to create a better replacement for x86 that isn't missing stuff.
<
The SIMD stuff is the stuff that should be missing, VVM covers it and much
much more.
>
> I can understand that you might disapprove, as many will feel that the
> stuff I regard as 'missing' is in fact useless wretched excess.
<
Not useless, misguided, model dependent, ever growing, leading to an ASM
that is NOT FUN to program in.
>
> John Savard

On Saturday, July 10, 2021 at 10:07:39 AM UTC-6, MitchAlsup wrote:
> The SIMD stuff is the stuff that should be missing, VVM covers it and much
> much more.

Oh, the SIMD stuff, not the VLIW stuff?

The VLIW stuff, I knew, was a bit extraneous - it would only get used on
certain specialized implementations.

There is also SIMD stuff that looks like AltiVec or AVX - and a whole other
set of SIMD stuff that looks like a Cray-I.

Maybe that too should be missing, but I am thinking in terms of a simplistic
architecture in which instructions are executed individually and directly.
So if one has code that _looks_ like it's just a loop, it will be executed as a
loop, not something faster. That is, I definitely do not think that I could put
vectorizing compiler functionality in hardware.

So even the simpler functionality of merging successive instructions to
enrich the instruction set is something I view as too advanced to consider.

> Not useless, misguided, model dependent, ever growing, leading to an ASM
> that is NOT FUN to program in.

Well, by "useless" I was thinking of other stuff, packed decimal, IBM/360
floating point, and so on.

It's true that MMX went to SSE which went to AVX. I had kind of figured that
vector arithmetic on 256 bit vectors could just be left as is, because if one wants
more, there's the Cray-I like stuff. And I went beyond the Cray-I, with 64 vector
registers.

But the Cray-I was succeeded by the Cray X-MP and the Cray Y-MP, and so those
kinds of vectors also *do* grow.

IBM, of course, had a vector instruction set with special associated loop instructions
so that one could perform an operation on long vectors without worrying about
whether the hardware was splitting them into 64-element vectors or 128-element
vectors or something else. So there is an option for avoiding the growth spiral that is
still more conventional than your Virtual Vector Method.

John Savard

On 2021-07-10, Quadibloc wrote:
> On Saturday, July 10, 2021 at 10:07:39 AM UTC-6, MitchAlsup wrote:
>> The SIMD stuff is the stuff that should be missing, VVM covers it and much
>> much more.
>
> Oh, the SIMD stuff, not the VLIW stuff?
>
> The VLIW stuff, I knew, was a bit extraneous - it would only get used on
> certain specialized implementations.
>
> There is also SIMD stuff that looks like AltiVec or AVX - and a whole other
> set of SIMD stuff that looks like a Cray-I.
>
> Maybe that too should be missing, but I am thinking in terms of a simplistic
> architecture in which instructions are executed individually and directly.
> So if one has code that _looks_ like it's just a loop, it will be executed as a
> loop, not something faster. That is, I definitely do not think that I could put
> vectorizing compiler functionality in hardware.
>
> So even the simpler functionality of merging successive instructions to
> enrich the instruction set is something I view as too advanced to consider.
>
>> Not useless, misguided, model dependent, ever growing, leading to an ASM
>> that is NOT FUN to program in.
>
> Well, by "useless" I was thinking of other stuff, packed decimal, IBM/360
> floating point, and so on.
>
> It's true that MMX went to SSE which went to AVX. I had kind of figured that
> vector arithmetic on 256 bit vectors could just be left as is, because if one wants
> more, there's the Cray-I like stuff. And I went beyond the Cray-I, with 64 vector
> registers.
>
> But the Cray-I was succeeded by the Cray X-MP and the Cray Y-MP, and so those
> kinds of vectors also *do* grow.

That's why I made the MRISC32 ISA vector register size agnostic. It's
not very hard, but you need to keep it in mind. For instance, the 64-bit
VM register of the Cray 1 sets a hard limit to the vector register size,
so I did not do it that way.

Another thing is that you need to have a fast and easy way to adjust
your loop increments (how many elements to process in a single loop
iteration), based on the implementation defined register length (I have
a "max vector length" status register and a MIN instruction that can be
used in tandem quite efficiently).

A third issue is to efficiently create vector constants on the form
[0, 1, 2, ..., N-1] (or similar), which is quite common in vectorized
code. In SIMD architectures you usually load the constant from data
memory. With variable vector lengths that's a bad fit, so I re-used the
address generation unit for that purpose, so e.g:

LDEA V3, [Z, #1] ; V3 = [0, 1, 2, 3, ...]
LDEA V4, [R2, R3] ; V4 = [R2, R2+R3, R2+2*R3, R2+3*R3, ...]

>
> IBM, of course, had a vector instruction set with special associated loop instructions
> so that one could perform an operation on long vectors without worrying about
> whether the hardware was splitting them into 64-element vectors or 128-element
> vectors or something else. So there is an option for avoiding the growth spiral that is
> still more conventional than your Virtual Vector Method.
>
> John Savard
>

On Sunday, July 11, 2021 at 2:46:28 AM UTC-6, Marcus wrote:

> That's why I made the MRISC32 ISA vector register size agnostic. It's
> not very hard, but you need to keep it in mind.

True. Basically, one designs vector memory-reference instructions that
are indexed, and you have the last of those in a loop increment the index
by the vector length, whatever it is. And a vector counter is also needed,
which gets decremented by the vector length on each iteration, and
when it goes less than the vector length, causes all the instructions to work
on partial vectors.

What concerns me about this model, though, is that it does seem to limit
what you can do with vectors; it seems to impose one particular model of
vector calculations.

While Mitch Alsup's VVM doesn't restrict what you can do with vectors, it
seems to keep the vectors in memory.

Having the length of vectors known to the programmer, and having vector
registers, seems to me to allow the most flexibility and the highest performance,
even if it creates a serious issue of future-proofing. My current inclination is
simply to include *all three approaches* in the description of the hardware, until
I learn more about these issues, and can be confident that one approach is the
best. Performance is a particular emphasis that I have here, since this is really
what vectors are _for_.

John Savard

On Saturday, July 10, 2021 at 10:07:39 AM UTC-6, MitchAlsup wrote:

> The SIMD stuff is the stuff that should be missing, VVM covers it and much
> much more.

I think I see now that I have been missing the chief excellency of the VVM.

No, it isn't just a sort of REPEAT instruction.

Instead, no doubt what it is doing is converting a stretch of ordinary-looking
code into a *dataflow* program, where references to registers are turned into
simply the numbers of node points linking pipelined ALUs together.

In my original Concertina architecture, along with everything else but the
kitchen sink, I did have a dataflow-building instruction. Here, using register
banks of 32 and 128 registers instead of just 8, I could use ordinary instructions
within a pair of delimiting instructions, and yet make things explicit: the
convention I'd likely use is that the first 1/4 of registers are real registers,
used for constants or as accumulators for running totals, and the rest are
node points.

John Savard

On Saturday, July 10, 2021 at 1:29:22 AM UTC+1, Quadibloc wrote:

> At the moment, ARM and RISC-V are the biggest challengers to x86-64.

ARM maybe. RISC-V? flat-out no chance. anyone that tries
it for anything beyond the most basic embedded tasks is going
to regret it. here's why:

https://news.ycombinator.com/item?id=24459314

> I feel that they're... missing stuff...

fascinatingly, the only thing needed to turn SVE2 into Cray-style Vectors
would be the addition of a setvl instruction that created a hidden
predicate mask. i think i mentioned this in an earlier post.

l.

On Sunday, July 11, 2021 at 9:31:38 AM UTC-6, luke.l...@gmail.com wrote:
> On Saturday, July 10, 2021 at 1:29:22 AM UTC+1, Quadibloc wrote:
>
> > At the moment, ARM and RISC-V are the biggest challengers to x86-64.

> ARM maybe. RISC-V? flat-out no chance. anyone that tries
> it for anything beyond the most basic embedded tasks is going
> to regret it. here's why:
>
> https://news.ycombinator.com/item?id=24459314

Ah. I know that in my designs, I don't even consider instruction fusion as
a possibility.

John Savard

On Sunday, July 11, 2021 at 11:46:21 AM UTC-5, Quadibloc wrote:
> On Sunday, July 11, 2021 at 9:31:38 AM UTC-6, luke.l...@gmail.com wrote:
> > On Saturday, July 10, 2021 at 1:29:22 AM UTC+1, Quadibloc wrote:
> >
> > > At the moment, ARM and RISC-V are the biggest challengers to x86-64.
>
> > ARM maybe. RISC-V? flat-out no chance. anyone that tries
> > it for anything beyond the most basic embedded tasks is going
> > to regret it. here's why:
> >
> > https://news.ycombinator.com/item?id=24459314
<
> Ah. I know that in my designs, I don't even consider instruction fusion as
> a possibility.
<
I do; for purely HW reasons--it takes less total storage in reservation stations
than holding them in separate stations.
>
> John Savard

Quadibloc wrote:
> On Saturday, July 10, 2021 at 10:07:39 AM UTC-6, MitchAlsup wrote:
>
>> The SIMD stuff is the stuff that should be missing, VVM covers it and much
>> much more.
>
> I think I see now that I have been missing the chief excellency of the VVM.
>
> No, it isn't just a sort of REPEAT instruction.
>
> Instead, no doubt what it is doing is converting a stretch of ordinary-looking
> code into a *dataflow* program, where references to registers are turned into
> simply the numbers of node points linking pipelined ALUs together.

VVM needs to also take care of any memory aliasing issues,
which to me look much more complicated than the forwarding.

for (i = 0; i < N; i++)
a[i+1] = a[i] + b[i];

In SIMD the programmer takes care of such issues,
in that SIMD doesn't know about any memory locations that
map to multiple register operands, so by using SIMD
they effectively guarantee there are no such issues.

Similarly for vector operations it is the programmer who guarantees
that the program has no alias updates in that machines' prefetch window,
however big the prefetch window is.

VVM has to work that out on the fly.

On Sunday, July 11, 2021 at 12:50:36 PM UTC-5, EricP wrote:
> Quadibloc wrote:
> > On Saturday, July 10, 2021 at 10:07:39 AM UTC-6, MitchAlsup wrote:
> >
> >> The SIMD stuff is the stuff that should be missing, VVM covers it and much
> >> much more.
> >
> > I think I see now that I have been missing the chief excellency of the VVM.
> >
> > No, it isn't just a sort of REPEAT instruction.
> >
> > Instead, no doubt what it is doing is converting a stretch of ordinary-looking
> > code into a *dataflow* program, where references to registers are turned into
> > simply the numbers of node points linking pipelined ALUs together.
<
> VVM needs to also take care of any memory aliasing issues,
<
Agreed
<
> which to me look much more complicated than the forwarding.
>
> for (i = 0; i < N; i++)
> a[i+1] = a[i] + b[i];
<
VVM watches the AGEN calculations on the insertion into the execution window,
and when necessary, restricts the AGENs from spanning loop iterations.
>
> In SIMD the programmer takes care of such issues,
> in that SIMD doesn't know about any memory locations that
> map to multiple register operands, so by using SIMD
> they effectively guarantee there are no such issues.
>
> Similarly for vector operations it is the programmer who guarantees
> that the program has no alias updates in that machines' prefetch window,
> however big the prefetch window is.
<
More often, the compiler went though memory aliasing contortions in order to
decide if the loop can be vectorized (or not--often not). The VVM compiler is
relieved of having to perform this analysis and can vectorize loops with such
shenanigans--it is just that these loops do not run as fast as the ones devoid
of shenanigans. {As it should be}
<
>
> VVM has to work that out on the fly.
<
Agreed.

luke.l...@gmail.com <luke.leighton@gmail.com> schrieb:
> On Saturday, July 10, 2021 at 1:29:22 AM UTC+1, Quadibloc wrote:
>
>> At the moment, ARM and RISC-V are the biggest challengers to x86-64.
>
> ARM maybe. RISC-V? flat-out no chance. anyone that tries
> it for anything beyond the most basic embedded tasks is going
> to regret it. here's why:
>
> https://news.ycombinator.com/item?id=24459314

https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68

is also quite well-founded (don't know if you knew this).

On Sunday, July 11, 2021 at 11:47:28 AM UTC-6, MitchAlsup wrote:
> On Sunday, July 11, 2021 at 11:46:21 AM UTC-5, Quadibloc wrote:

> > Ah. I know that in my designs, I don't even consider instruction fusion as
> > a possibility.

> I do; for purely HW reasons--it takes less total storage in reservation stations
> than holding them in separate stations.

My concern isn't that instruction fusion is 'bad', but that it's a good thing that's
too difficult to attain - so I try to design an ISA so that there are no instructions
that need to be fused.

Now that I've seen how I can take inspiration from your VVM, though, I see a
potential conflict with the Concertina II design philosophy. I've got it fetching,
decoding, and maybe even executing up to eight instructions in a block in
parallel.

If an instruction is part of a VVM section, though, *what it does has been changed*.

So I have to warn this VLIW-ish design about that. Essentially, I think I will do it
by adding block header formats in which some instruction slots can be marked
as 'prefixed', to allow use of this and similar features.

John Savard

On Sunday, July 11, 2021 at 3:19:20 PM UTC-6, Quadibloc wrote:

> So I have to warn this VLIW-ish design about that. Essentially, I think I will do it
> by adding block header formats in which some instruction slots can be marked
> as 'prefixed', to allow use of this and similar features.

Good thing I did that - in reviewing the block header formats, I found I had made
some serious mistakes, and there were some formats with codes that would have
overlapped with other prefixes, or with codes used for instructions and not available
for prefixes.

John Savard

On Sunday, July 11, 2021 at 1:07:27 PM UTC-6, Thomas Koenig wrote:

> https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68

> is also quite well-founded (don't know if you knew this).

In addition to its noting the absence of condition codes as a flaw,
which gladdens my heart (I recognize that condition codes _can_
cause problems, which is why ARM, Alpha, and Mips didn't have them
either, but I've found it easier to take actions to remedy the problems
condition codes can cause than to compensate for the problems
caused by not having them) I found this:

"How FP values are represented in the FP register file is unspecified but observable (by load/store)"

Ouch! Yes, "emulator writers will hate you", among other things. I have decided that
I want added efficiency from storing FP values in the FP register file (but _not_ the
short vector - that is, AVX-like SIMD - register files) in a modified format, but the format
is documented and specified as part of the architecture.

I do the same with decimal floating point.

In both cases, though, my internal format involves only the *obvious* changes for
improving performance - getting rid of the hidden first bit for FP, unpacking densely
packed decimal to plain packed decimal for decimal FP - so that there is no reason
to make the internal format implementation-dependent or model-dependent.

John Savard