EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> Quadibloc wrote:
>> On Friday, February 11, 2022 at 4:11:16 PM UTC-7, Thomas Koenig wrote:
>>
>>> It is rather hard to do anything useful with 16 bits with full 32
>>> registers.
>>
>> What I've done in my recent designs is to specify the two registers used in
>> an instruction with only 8 bits; five specify the destination register, and the
>> source register must belong to the same group of eight registers as the
>> destination register.
>>
>> Since the idea is to allow more instructions to run in parallel by having
>> multiple interleaved threads of instructions that work with different registers,
>> this fits right in.
>>
>> John Savard
>
> The term "strands of execution" might be better than
> overloading the term thread.
>
> I don't see how these two concepts of register sets and strands connect.
> The decoder internally maps the 2 register instruction into
> the same 3 register uOp as a 3 register format would use.
> The restriction of second register being in the same 2-bit set
> only matters to the compiler register selector, not the uOp.
> If the forwarding network can execute dependent instructions
> back to back, then which strand an instruction is for doesn't matter.

A microarchitecture might be set up in a way that it has (some)
separate execution units and register files for each strand (good
term, by the way) to allow a smaller forwarding network.

One interesting question would be how to handle communication
between the different strands, possibly with a few shared registers
(there might be a need for a shared stack pointer, for example).

We discussed this some time ago, with mixed results.

The first step would probably to see how well a compiler would
handle such a split into multiple strands. Itanium appeared to
have had around 20 to 30% nops with their prescribed bundling,
but a strand-based ISA should be more flexible.

(Of course, a microarchitecture could also do a hierarchical
ordering of their execution units; for all I know, they
already do so and bin their instructions).

According to Ivan Godard <ivan@millcomputing.com>:
>In Mill the translation happens once, at install time, via a transparent
>invocation of the specializer (not a recompile, and the source code is
>not needed). In a microcoded machine (or a packing/cracking scheme) the
>translation takes place at execution time, every time. Either way, it
>gets done, and either way permits ISA extension freely. They differ in
>power, area, and time; the choice is an engineering design dimension.
>
>I assert without proof that Mill-style software translation in fact
>permits ISA extension that is *more* flexible and powerful than what can
>be achieved by hardware approaches. YMMV.

If one believes in proof by example, this approach has been wildly successful
in the IBM S/38, AS/400. and whatever it is called now, something something i.

You can take 30 year TIMI object code and run it on current hardware at full speed,
supporting their exotic object architecture with 128 bit pointers. I believe the
architecture had one significant change in the 1990s, with addresses expanding
from 48 to 64 bits but the old object code still works.

I'm kind of surprised nobody else does this. I suppose only IBM had sufficient
control over both the hardware and software to make it work.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Ivan Godard <ivan@millcomputing.com> writes:
>In Mill the translation happens once, at install time, via a transparent
>invocation of the specializer (not a recompile, and the source code is
>not needed). In a microcoded machine (or a packing/cracking scheme) the
>translation takes place at execution time, every time. Either way, it
>gets done, and either way permits ISA extension freely. They differ in
>power, area, and time; the choice is an engineering design dimension.
>
>I assert without proof that Mill-style software translation in fact
>permits ISA extension that is *more* flexible and powerful than what can
>be achieved by hardware approaches. YMMV.

My mileage is that we have RAID 1 on two SSDs with a Debian
installation on a machine with a Ryzen 5800X. When we got a machine
with a Xeon-W 1370P to work, we took one of the SSDs, put it in the
Xeon box, and the system worked. We also put empty SSDs in both
machines and told the system to use the new SSD for the RAID 1.

The way you describe the Mill way, we could not do that with two
different Mill models, even from the same company.

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

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>Ivan Godard <ivan@millcomputing.com> writes:
>>In Mill the translation happens once, at install time, via a transparent
>>invocation of the specializer ...

>The way you describe the Mill way, we could not do that with two
>different Mill models, even from the same company.

Are you sure? If it's modelled on the AS/400, the original code is still there
and when you run a program, the system retranslates the code if it doesn't have
the specialized version for the current processor.

Perhaps Ivan can clarify.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Sunday, February 13, 2022 at 9:45:06 AM UTC-6, EricP wrote:
> Quadibloc wrote:
> > On Friday, February 11, 2022 at 4:11:16 PM UTC-7, Thomas Koenig wrote:
> >
> >> It is rather hard to do anything useful with 16 bits with full 32
> >> registers.
> >
> > What I've done in my recent designs is to specify the two registers used in
> > an instruction with only 8 bits; five specify the destination register, and the
> > source register must belong to the same group of eight registers as the
> > destination register.
> >
> > Since the idea is to allow more instructions to run in parallel by having
> > multiple interleaved threads of instructions that work with different registers,
> > this fits right in.
> >
> > John Savard
<
> The term "strands of execution" might be better than
> overloading the term thread.
<
There are more problems than that in Quadibloc's statement.
<
"Since the idea is to allow more instructions to run in parallel by having
multiple interleaved threads" Threads within a process, or Threads spanning
processes? "of instructions that work with different registers" different
blocks within a single register file or different register files themselves?
>
> I don't see how these two concepts of register sets and strands connect.
> The decoder internally maps the 2 register instruction into
> the same 3 register uOp as a 3 register format would use.
> The restriction of second register being in the same 2-bit set
> only matters to the compiler register selector, not the uOp.
<
But he has doubled the number of places register specifiers come
from (16-bit and 32-bit) while adding some bit pasting from route.
<
> If the forwarding network can execute dependent instructions
> back to back, then which strand an instruction is for doesn't matter.
<
Right: once mapped into the complete register file it's just data-flow.
>
> For something like this to matter there would have to be an
> asymmetry between accessing or forwarding between register sets.
> That seems a pretty niche implementation target for an ISA.

John Levine <johnl@taugh.com> schrieb:
> According to Ivan Godard <ivan@millcomputing.com>:
>>In Mill the translation happens once, at install time, via a transparent
>>invocation of the specializer (not a recompile, and the source code is
>>not needed). In a microcoded machine (or a packing/cracking scheme) the
>>translation takes place at execution time, every time. Either way, it
>>gets done, and either way permits ISA extension freely. They differ in
>>power, area, and time; the choice is an engineering design dimension.
>>
>>I assert without proof that Mill-style software translation in fact
>>permits ISA extension that is *more* flexible and powerful than what can
>>be achieved by hardware approaches. YMMV.
>
> If one believes in proof by example, this approach has been wildly successful
> in the IBM S/38, AS/400. and whatever it is called now, something something i.
>
> You can take 30 year TIMI object code and run it on current hardware at full speed,
> supporting their exotic object architecture with 128 bit pointers. I believe the
> architecture had one significant change in the 1990s, with addresses expanding
> from 48 to 64 bits but the old object code still works.
>
> I'm kind of surprised nobody else does this. I suppose only IBM had sufficient
> control over both the hardware and software to make it work.

That is the key, I think - IBM also controls the operating system.

Which begs the question - what is Mill going to do for operating
system support, are there any plans? Plan 9 with its multiple
binaries might actually be an option.

On Sunday, February 13, 2022 at 11:54:34 AM UTC-6, Anton Ertl wrote:
> Ivan Godard <iv...@millcomputing.com> writes:
> >In Mill the translation happens once, at install time, via a transparent
> >invocation of the specializer (not a recompile, and the source code is
> >not needed). In a microcoded machine (or a packing/cracking scheme) the
> >translation takes place at execution time, every time. Either way, it
> >gets done, and either way permits ISA extension freely. They differ in
> >power, area, and time; the choice is an engineering design dimension.
> >
> >I assert without proof that Mill-style software translation in fact
> >permits ISA extension that is *more* flexible and powerful than what can
> >be achieved by hardware approaches. YMMV.
> My mileage is that we have RAID 1 on two SSDs with a Debian
> installation on a machine with a Ryzen 5800X. When we got a machine
> with a Xeon-W 1370P to work, we took one of the SSDs, put it in the
> Xeon box, and the system worked. We also put empty SSDs in both
> machines and told the system to use the new SSD for the RAID 1.
>
> The way you describe the Mill way, we could not do that with two
> different Mill models, even from the same company.
<
A RAID accessible to a Gold and a Silver containing application *.elfs
<
How does this work?
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On 13.02.2022 19:30, MitchAlsup wrote:
> On Sunday, February 13, 2022 at 11:54:34 AM UTC-6, Anton Ertl wrote:
>> Ivan Godard <iv...@millcomputing.com> writes:
>>> In Mill the translation happens once, at install time, via a transparent
>>> invocation of the specializer (not a recompile, and the source code is
>>> not needed). In a microcoded machine (or a packing/cracking scheme) the
>>> translation takes place at execution time, every time. Either way, it
>>> gets done, and either way permits ISA extension freely. They differ in
>>> power, area, and time; the choice is an engineering design dimension.
>>>
>>> I assert without proof that Mill-style software translation in fact
>>> permits ISA extension that is *more* flexible and powerful than what can
>>> be achieved by hardware approaches. YMMV.
>> My mileage is that we have RAID 1 on two SSDs with a Debian
>> installation on a machine with a Ryzen 5800X. When we got a machine
>> with a Xeon-W 1370P to work, we took one of the SSDs, put it in the
>> Xeon box, and the system worked. We also put empty SSDs in both
>> machines and told the system to use the new SSD for the RAID 1.
>>
>> The way you describe the Mill way, we could not do that with two
>> different Mill models, even from the same company.
> <
> A RAID accessible to a Gold and a Silver containing application *.elfs
> <
> How does this work?
> <
>> - anton
>> --
>> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
>> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Perhaps something like old Mac's "fat binaries" with 68k and PowerPC
code in different forks?

On Sunday, February 13, 2022 at 3:27:31 PM UTC-6, John Dallman wrote:
> In article <subggb$2vj5$1...@gal.iecc.com>, jo...@taugh.com (John Levine)
> wrote:
> > I'm kind of surprised nobody else does this. I suppose only IBM
> > had sufficient control over both the hardware and software to make
> > it work.
<
> IBM had the credibility to introduce a hardware and OS combination that
> wasn't compatible with anything else, and get businesses to rely on it.
> That's quite rare.
<
Remembering how long people had been using whips to cause the animal
pulling their cart. The opening for someone (like IBM) to do as John indicates
comes around about that often. We remember the event by the death of the
buggy whip industry.
>
> John

> Which begs the question - what is Mill going to do for operating
> system support, are there any plans? Plan 9 with its multiple
> binaries might actually be an option.

I don't think Ivan has answered that yet here the last few times thi
discussion showed up, but in any case there are many different ways to
handle the problem:

- Ignore it (i.e. focus on segments of the market where moving
specialized code from one machine to another is not needed).

- For JIT compilers, this is a similar problem as dynamic recompilation,
which I'd expect most mature JIT compilers already do for other
reasons, so it's likely easy to solved.

- To support moving a whole OS disk to a new machine between reboots,
all it takes is to detect the different CPU and cause all the code to
be re-specialized, probably lazily (i.e. re-specialize executables at
first execution).

- Since, contrary to IBM, I believe they don't intend to hide the
low-level ISA, it's probably impossible to handle on-the-fly migration
in 100% reliable way in the general case, so they don't need to try
and handle the general case.

- IIUC, the Mill's stack is very well protected, so that probably makes
it easier to find reliably all the return addresses in order to update
them after recompiling the code. That still leaves the question of
how to handle the code pointers stored in the heap (you can overwrite
the old code with dummy proxies/trampolines but you would still want
to have some way to find&redirect the pointers themselves so the
proxies aren't needed eternally).

Stefan

On 2/13/2022 6:53 AM, Quadibloc wrote:
> On Sunday, February 13, 2022 at 4:51:26 AM UTC-7, Thomas Koenig wrote:
>> if you basically get to rewrite your ISA for each
>> specific processor,
>
> My understanding is that while the native code of different Mill processors
> is different, the form of code that compilers generate which is publicly
> specified is constant.
>
> This is still a constraint - think of the IBM 360, where different models used
> their own microcode language.
>
> John Savard

Generally but not completely true. GenAsm, the distribution medium, is
expected to be mostly constant. However, even that can change so long as
the genasm version is one recognized by the specializer version. To
continue the analogy with microcode, upgrading the specializer on an
existing chip is analogous to reflashing the microcode ROM, or, on the
360, loading in a different microcode floppy.

On 2/13/2022 7:46 AM, Stefan Monnier wrote:
>> In Mill the translation happens once, at install time, via a transparent
>> invocation of the specializer (not a recompile, and the source code is not
>> needed).
>
> Of course, for JIT compilers, "install time" is also run time, making it
> important to have a fast(ish?) way to specialize for the target CPU.
>
> It can also make it harder to do things like migrate a VM from one CPU
> to another (or for things like big.LITTLE).
>
>
> Stefan

Yes, big.LITTLE is a known issue with our approach.

It is straightforward to migrate at an encoding barrier, which in our
present software is the function body. It is more difficult to migrate
if the data representation differs, but the only case we have at present
is between cores that do and do not support quad (128-bit) arithmetic
natively. And we have some ideas on how to migrate in the middle of open
code, but haven't done anything more than mumble about it.

On 2/13/2022 9:41 AM, Anton Ertl wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
>> In Mill the translation happens once, at install time, via a transparent
>> invocation of the specializer (not a recompile, and the source code is
>> not needed). In a microcoded machine (or a packing/cracking scheme) the
>> translation takes place at execution time, every time. Either way, it
>> gets done, and either way permits ISA extension freely. They differ in
>> power, area, and time; the choice is an engineering design dimension.
>>
>> I assert without proof that Mill-style software translation in fact
>> permits ISA extension that is *more* flexible and powerful than what can
>> be achieved by hardware approaches. YMMV.
>
> My mileage is that we have RAID 1 on two SSDs with a Debian
> installation on a machine with a Ryzen 5800X. When we got a machine
> with a Xeon-W 1370P to work, we took one of the SSDs, put it in the
> Xeon box, and the system worked. We also put empty SSDs in both
> machines and told the system to use the new SSD for the RAID 1.
>
> The way you describe the Mill way, we could not do that with two
> different Mill models, even from the same company.
>
> - anton

With the caution that Mill is a core ISA, not a board architecture, you
should be able to do as you describe on Mill cores.

Each load module in a Mill system identifies its target member and
carries a reference to (or copy of) the genAsm from which it was made.
The LM is actually a pruneable cache of the conAsms (member machine
codes) that have been made from that genAsm. If you try to run a LM on a
core that does not have a conAsm version in the cache then the system
invokes the current specializer and builds, and caches, a new conAsm
that will run on the new host.

This handles both migrating SSDs and also downloading (genAsm) binaries.
If SSD space is constrained, an option on a strip tool lets you discard
unnecessary conAsms that are no longer relevant.

This dynamic recreation requires that the chip be able to specialize to
the current host, and specializers are target specific. The bottom
turtle is a boot specializer in ROM on the chip itself. This is little
more than a genAsm interpreter, but is sufficient to build and run a
real specializer from the SSD, which in turn (after specializing itself
in a more optimal way) can migrate the rest of the system and
application code.

Specializers in general carry knowledge of the peculiarities of their
target. The intent is that you can use (after bootstrapping as above) a
generic specializer that works from tables obtained from that same ROM,
but if you want more bang you can download and install a target specific
specializer from the chip vendor's site. That particularized specializer
can make use of ISA-specific algorithms that the generic specializer
doesn't know, but the resulting code gets cached in the LMs like any
other. The The same approach will handle bug fixes of the specializer
itself, or x86-like hardware bugs.

Truth of advertising: we don't have the generic specialize cascade
working yet, and our current software is built using conventional
cross-compiling methods.

On 2/13/2022 10:30 AM, Thomas Koenig wrote:
> John Levine <johnl@taugh.com> schrieb:
>> According to Ivan Godard <ivan@millcomputing.com>:
>>> In Mill the translation happens once, at install time, via a transparent
>>> invocation of the specializer (not a recompile, and the source code is
>>> not needed). In a microcoded machine (or a packing/cracking scheme) the
>>> translation takes place at execution time, every time. Either way, it
>>> gets done, and either way permits ISA extension freely. They differ in
>>> power, area, and time; the choice is an engineering design dimension.
>>>
>>> I assert without proof that Mill-style software translation in fact
>>> permits ISA extension that is *more* flexible and powerful than what can
>>> be achieved by hardware approaches. YMMV.
>>
>> If one believes in proof by example, this approach has been wildly successful
>> in the IBM S/38, AS/400. and whatever it is called now, something something i.
>>
>> You can take 30 year TIMI object code and run it on current hardware at full speed,
>> supporting their exotic object architecture with 128 bit pointers. I believe the
>> architecture had one significant change in the 1990s, with addresses expanding
>> from 48 to 64 bits but the old object code still works.
>>
>> I'm kind of surprised nobody else does this. I suppose only IBM had sufficient
>> control over both the hardware and software to make it work.
>
> That is the key, I think - IBM also controls the operating system.
>
> Which begs the question - what is Mill going to do for operating
> system support, are there any plans? Plan 9 with its multiple
> binaries might actually be an option.

In progress, albeit slowly. We will provide a microkernel, essentially
at or slightly above the HAL level - this is furthest along. On that
will be a basic Linux port sufficient to provide a standard syscall
interface. The real issue comes from existing software that embeds
hardware or structural assumptions - /proc, drivers, etc. The CHERI
project suffers from the same problem.

On 2/13/2022 2:47 PM, Stefan Monnier wrote:
>> Which begs the question - what is Mill going to do for operating
>> system support, are there any plans? Plan 9 with its multiple
>> binaries might actually be an option.
>
> I don't think Ivan has answered that yet here the last few times thi
> discussion showed up, but in any case there are many different ways to
> handle the problem:
>
> - Ignore it (i.e. focus on segments of the market where moving
> specialized code from one machine to another is not needed).
>
> - For JIT compilers, this is a similar problem as dynamic recompilation,
> which I'd expect most mature JIT compilers already do for other
> reasons, so it's likely easy to solved.
>
> - To support moving a whole OS disk to a new machine between reboots,
> all it takes is to detect the different CPU and cause all the code to
> be re-specialized, probably lazily (i.e. re-specialize executables at
> first execution).
>
> - Since, contrary to IBM, I believe they don't intend to hide the
> low-level ISA, it's probably impossible to handle on-the-fly migration
> in 100% reliable way in the general case, so they don't need to try
> and handle the general case.
>
> - IIUC, the Mill's stack is very well protected, so that probably makes
> it easier to find reliably all the return addresses in order to update
> them after recompiling the code. That still leaves the question of
> how to handle the code pointers stored in the heap (you can overwrite
> the old code with dummy proxies/trampolines but you would still want
> to have some way to find&redirect the pointers themselves so the
> proxies aren't needed eternally).
>
>
> Stefan

+1

On Sunday, February 13, 2022 at 8:32:51 AM UTC-7, MitchAlsup wrote:
> On Sunday, February 13, 2022 at 8:57:24 AM UTC-6, Quadibloc wrote:
> > On Friday, February 11, 2022 at 4:11:16 PM UTC-7, Thomas Koenig wrote:
> >
> > > It is rather hard to do anything useful with 16 bits with full 32
> > > registers.
> > What I've done in my recent designs is to specify the two registers used in
> > an instruction with only 8 bits; five specify the destination register, and the
> > source register must belong to the same group of eight registers as the
> > destination register.
> <
> I think you may find this negatively impacts your code when running your
> ABI.
> <
> For example, My 66000 ABI passes arguments to functions in R1-R9, returns
> results in R1-R9, and preserves R16-R31 across function calls, with Rlow-R15
> freely available as temp registers.
> <
> Let us postulate a subroutine that allocates a dynamically sized array which
> arrives as a parameter, but ultimately wants to get subtracted from the stack
> pointer R31 to allocate the array.

It's not as if I don't also have 32-bit register-to-register instructions in the
ISA. So the 16-bit instructions are just there to be used when they can be,
they don't make it awkward to do more general register-to-register operations.

So I'm not sure if I understand the nature of execution.

John Savard

On Sunday, February 13, 2022 at 8:45:06 AM UTC-7, EricP wrote:

> The term "strands of execution" might be better than
> overloading the term thread.

I'm certainly willing to accept that.

> I don't see how these two concepts of register sets and strands connect.
> The decoder internally maps the 2 register instruction into
> the same 3 register uOp as a 3 register format would use.
> The restriction of second register being in the same 2-bit set
> only matters to the compiler register selector, not the uOp.
> If the forwarding network can execute dependent instructions
> back to back, then which strand an instruction is for doesn't matter.

I'll certainly also agree that this sort of thing doesn't matter at all
once you get down to the level of micro-ops.

> For something like this to matter there would have to be an
> asymmetry between accessing or forwarding between register sets.
> That seems a pretty niche implementation target for an ISA.

A pre-existing asymmetry?

The reason I'm having multiple strands of execution is so that
the ISA can work within the kind of modest-performance
implementation which

- is in-order,

- but which tries to obtain some of the performance benefits
of an out-of-order implementation by having 32 registers
instead of 8.

So I'm aiming at this:

If the compiler can take those concurrent strands of
execution, and keep the registers they use within one
of the partitions of the 32 registers into four sets of 8,
then the compiler can use 16-bit instructions more
often.

So I'm _creating_ an asymmetry between accessing or
forwarding between register sets...

but a *mild* one, which only applies to the _extra_
16-bit instructions that typical RISC architectures
_don't_ have, and not to the 32-bit registers that they
have and I also do...

to allow significantly more compact code to be
generated.

I don't see what's bad about that.

John Savard

On Sunday, February 13, 2022 at 8:34:46 PM UTC-7, Quadibloc wrote:
> On Sunday, February 13, 2022 at 8:32:51 AM UTC-7, MitchAlsup wrote:
> > On Sunday, February 13, 2022 at 8:57:24 AM UTC-6, Quadibloc wrote:
> > > On Friday, February 11, 2022 at 4:11:16 PM UTC-7, Thomas Koenig wrote:
> > >
> > > > It is rather hard to do anything useful with 16 bits with full 32
> > > > registers.
> > > What I've done in my recent designs is to specify the two registers used in
> > > an instruction with only 8 bits; five specify the destination register, and the
> > > source register must belong to the same group of eight registers as the
> > > destination register.
> > <
> > I think you may find this negatively impacts your code when running your
> > ABI.
> > <
> > For example, My 66000 ABI passes arguments to functions in R1-R9, returns
> > results in R1-R9, and preserves R16-R31 across function calls, with Rlow-R15
> > freely available as temp registers.
> > <
> > Let us postulate a subroutine that allocates a dynamically sized array which
> > arrives as a parameter, but ultimately wants to get subtracted from the stack
> > pointer R31 to allocate the array.
> It's not as if I don't also have 32-bit register-to-register instructions in the
> ISA. So the 16-bit instructions are just there to be used when they can be,
> they don't make it awkward to do more general register-to-register operations.
>
> So I'm not sure if I understand the nature of

the objectiion

(how on Earth did that typo get in? Freudian slip?)
> John Savard

On 2/13/2022 7:42 PM, Quadibloc wrote:
> On Sunday, February 13, 2022 at 8:45:06 AM UTC-7, EricP wrote:
>
>> The term "strands of execution" might be better than
>> overloading the term thread.
>
> I'm certainly willing to accept that.
>
>> I don't see how these two concepts of register sets and strands connect.
>> The decoder internally maps the 2 register instruction into
>> the same 3 register uOp as a 3 register format would use.
>> The restriction of second register being in the same 2-bit set
>> only matters to the compiler register selector, not the uOp.
>> If the forwarding network can execute dependent instructions
>> back to back, then which strand an instruction is for doesn't matter.
>
> I'll certainly also agree that this sort of thing doesn't matter at all
> once you get down to the level of micro-ops.
>
>> For something like this to matter there would have to be an
>> asymmetry between accessing or forwarding between register sets.
>> That seems a pretty niche implementation target for an ISA.
>
> A pre-existing asymmetry?
>
> The reason I'm having multiple strands of execution is so that
> the ISA can work within the kind of modest-performance
> implementation which
>
> - is in-order,
>
> - but which tries to obtain some of the performance benefits
> of an out-of-order implementation by having 32 registers
> instead of 8.
>
> So I'm aiming at this:
>
> If the compiler can take those concurrent strands of
> execution, and keep the registers they use within one
> of the partitions of the 32 registers into four sets of 8,
> then the compiler can use 16-bit instructions more
> often.
>
> So I'm _creating_ an asymmetry between accessing or
> forwarding between register sets...
>
> but a *mild* one, which only applies to the _extra_
> 16-bit instructions that typical RISC architectures
> _don't_ have, and not to the 32-bit registers that they
> have and I also do...
>
> to allow significantly more compact code to be
> generated.
>
> I don't see what's bad about that.
>
> John Savard

Clever. I don't see what's wrong about that either, although register
assignment in the compiler might be "interesting"

Ivan Godard <ivan@millcomputing.com> schrieb:
> On 2/13/2022 10:30 AM, Thomas Koenig wrote:

>> Which begs the question - what is Mill going to do for operating
>> system support, are there any plans? Plan 9 with its multiple
>> binaries might actually be an option.
>
> In progress, albeit slowly. We will provide a microkernel, essentially
> at or slightly above the HAL level - this is furthest along. On that
> will be a basic Linux port sufficient to provide a standard syscall
> interface.

I was just about to write that Linux is pretty much tied to gcc, but
it seems that clang is also supported now:
https://www.kernel.org/doc/html/latest/kbuild/llvm.html

so your clang-only compiler infrastructure should not be a problem.

>The real issue comes from existing software that embeds
> hardware or structural assumptions - /proc, drivers, etc. The CHERI
> project suffers from the same problem.

There is also the problem of which surrounding hardware to use.
Hm... are pin layouts for CPUs protected, or could you (for example)
lay out the connections on your CPU to be compatible with one of
the existing AMD or ARM chips?

On 2/13/2022 11:20 PM, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>> On 2/13/2022 10:30 AM, Thomas Koenig wrote:
>
>>> Which begs the question - what is Mill going to do for operating
>>> system support, are there any plans? Plan 9 with its multiple
>>> binaries might actually be an option.
>>
>> In progress, albeit slowly. We will provide a microkernel, essentially
>> at or slightly above the HAL level - this is furthest along. On that
>> will be a basic Linux port sufficient to provide a standard syscall
>> interface.
>
> I was just about to write that Linux is pretty much tied to gcc, but
> it seems that clang is also supported now:
> https://www.kernel.org/doc/html/latest/kbuild/llvm.html
>
> so your clang-only compiler infrastructure should not be a problem.

We are compiler-independent, although we have only done clang/LLVM so
far. Everything past genAsm is our own code, and any compiler can emit
genAsm.

>> The real issue comes from existing software that embeds
>> hardware or structural assumptions - /proc, drivers, etc. The CHERI
>> project suffers from the same problem.
>
> There is also the problem of which surrounding hardware to use.
> Hm... are pin layouts for CPUs protected, or could you (for example)
> lay out the connections on your CPU to be compatible with one of
> the existing AMD or ARM chips?

I understand that HW expects to adopt existing industry standards for
such things, but IANAHWG and don't know the details, which won't be
settled anyway until we reach the point of advancing from FPGA to a real
chip.

John Levine <johnl@taugh.com> writes:
>According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>Ivan Godard <ivan@millcomputing.com> writes:
>>>In Mill the translation happens once, at install time, via a transparent
>>>invocation of the specializer ...
>
>>The way you describe the Mill way, we could not do that with two
>>different Mill models, even from the same company.
>
>Are you sure?

That's what he described above.

>If it's modelled on the AS/400, the original code is still there
>and when you run a program, the system retranslates the code if it doesn't have
>the specialized version for the current processor.

That's a more flexible approach.

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

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>- For JIT compilers, this is a similar problem as dynamic recompilation,
> which I'd expect most mature JIT compilers already do for other
> reasons, so it's likely easy to solved.

What do you mean with "dynamic recompilation", and why do you expect
mature JIT compilers to do it?

Concerning JIT compilation, my impression is that Ivan Godard has not
put much thought into it. As far as I understand, all the software
should generate generic Mill code, and the specializer should then
translate that to native code. With a specializer based on LLVM, that
is going to be very slow. Even with a specializer designed for
specialization speed (or a JIT compiler directly generating native
code), features like the compressed instruction encoding will cause
slowness in native-code generation. Doing it as a two-stage process
(JIT+specializer) is also going to slow JIT translation down, while a
one-stage approach means that m JIT compilers combined with n Mill
native hardware implementations cause m*n effort (ideally, you just
need to change parameters, but someone certainly would have to invest
more effort in the JITs to make them parameterizable in that way).

>- Since, contrary to IBM, I believe they don't intend to hide the
> low-level ISA, it's probably impossible to handle on-the-fly migration
> in 100% reliable way in the general case, so they don't need to try
> and handle the general case.

Yes, moving an existing process is certainly another feature that the
classic architecture/microarchitecture division supports, and where
Mill needs to provide an answer, especially if the claim is that Mill
is more flexible. The single address space is also a problem in that
context.

My provisional verdict: Mill has been designed with the supercomputer
mindset, and suffers from the usual problems of such designs.

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

On 2/14/2022 12:49 AM, Anton Ertl wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> - For JIT compilers, this is a similar problem as dynamic recompilation,
>> which I'd expect most mature JIT compilers already do for other
>> reasons, so it's likely easy to solved.
>
> What do you mean with "dynamic recompilation", and why do you expect
> mature JIT compilers to do it?
>
> Concerning JIT compilation, my impression is that Ivan Godard has not
> put much thought into it. As far as I understand, all the software
> should generate generic Mill code, and the specializer should then
> translate that to native code. With a specializer based on LLVM, that
> is going to be very slow.

The specializer and all the tool chain after genAsm is our own code
(50k+ lines), and contains no 3rd party (e.g. LLVM) code. The
specializer does quite extensive optimization - bundle-packing,
scheduling, CFG collapse, software pipelining, in- and out-lining, etc.
- which is too expensive for a JIT, but the passes that do the
optimizations are optionally bypassed.

As it seems unlikely that you would want to JIT for multiple targets
simultaneously, we expect that most JITs will generate machine code,
which is no more difficult to do than for any conventional-ISA machine
code target. Standard JIT methods - gluing code snippets together, for
example - will in effect emulate an in-order one-wide machine just as
they do on any ISA, and at no greater effort.

Alternatively, for better code quality you could JIT genAsm and run the
full specializer on that, assuming you JIT whole functions. Or both,
with JITed machine code for immediate execution and whole functions
being specialized in background.

Even with a specializer designed for
> specialization speed (or a JIT compiler directly generating native
> code), features like the compressed instruction encoding will cause
> slowness in native-code generation.

Why? It's just an encoding. Every code generator does bit stuffing. You
pull the bits from a table and copy them over.

> Doing it as a two-stage process
> (JIT+specializer) is also going to slow JIT translation down, while a
> one-stage approach means that m JIT compilers combined with n Mill
> native hardware implementations cause m*n effort (ideally, you just
> need to change parameters, but someone certainly would have to invest
> more effort in the JITs to make them parameterizable in that way).

Every JIT for a new target binary has to deal with the vagaries of that
binary, so a Mill JIT is as much work as a foobar JIT. However, it seems
you are thinking that a Mill member is as different from some other
member as (say) x86 is from ARM. That is flat false.

All Mill members are Mills; they have exactly the same architecture and
exactly the same abstract ISA and instruction set. They only differ in
the binary encoding used to represent that ISA. A JIT, like the
specializer, will deal with the generic Mill operations; only when the
program has been generated in internal form are the actual bit patterns
for the operations selected and stuffed into bundles.

The specializer puts a *lot* of work into stuffing as many instructions
as possible into the bundle format - Mill is a (very) wide architecture.
But for quick and dirty, i.e. JIT, code you can just put one instruction
in each bundle and be done with it, and ignore the fact that you are
wasting all that parallelism. The result will be no worse than code for
any other one-instruction-at-a-time code.

>> - Since, contrary to IBM, I believe they don't intend to hide the
>> low-level ISA, it's probably impossible to handle on-the-fly migration
>> in 100% reliable way in the general case, so they don't need to try
>> and handle the general case.
>
> Yes, moving an existing process is certainly another feature that the
> classic architecture/microarchitecture division supports, and where
> Mill needs to provide an answer, especially if the claim is that Mill
> is more flexible.

Inter-binary migration is possible at the function granularity; it is
not clear we will choose to support it. After all, there doesn't seem to
be much call for migrating a running x86 process to an ARM. Intra-binary
migration is like any other multicore.

BIG.little migration is straightforward, so long as both BIG and little
accept the same binary format. We expect to make "little" configurations
that are half- or quarter-size one of our large configurations,
accepting the same binary, and double- or quad-pumping the FUs. After
all, all our configs have the same instructions set. The differ in
parallelism and binary format, but they all use the same FUs.

> The single address space is also a problem in that
> context.

It seems adequate for anything you would want to do on a single chip,
and is expandable if that turns out to be short-sighted. We made the
deliberate business decision to not support off-chip shared address
spaces; the box/room/building scales will have to do message passing,
which seems to be the trend in supercomputers anyway.

> My provisional verdict: Mill has been designed with the supercomputer
> mindset, and suffers from the usual problems of such designs.

There are answers; perhaps asking for them before verdict would be useful?

On Monday, February 14, 2022 at 2:15:21 AM UTC-7, Anton Ertl wrote:

> My provisional verdict: Mill has been designed with the supercomputer
> mindset, and suffers from the usual problems of such designs.

Hmm. While I suspect _my_ designs have that flaw, my perception was
that the focus in Mill was low power consumption rather than maximum
performance.

Of course, a focus on throughput, rather than single-thread performance,
may be exactly what you are referring to.

John Savard