The following assumes enough bits to encode it (which are always
rare), but I'd still like to float the idea.

Consider a "valid" bit associated with each register, which would
be set by loads and calculations using this as a target register,
and which could optionally be cleared by operations where its
value is used, or by a store. It should also be possible to
unset the valid bit on a register, for example on return from
a supervisor call or possibly from a function.

Accessing a register with unset valid bit could result in
an exception, or (less preferable) in a arbitrary value such
as 0xdeadbeef of IBM fame.

Advantages: There would be no need to write back the value
to the physical register file, saving effort (and possibly
making analysis easer).

Saving registers on function entry could be restricted on those
which are actually valid, the same would hold for a context switch.

Disadvantages: Extra bits needed in the instruction space
(obviously), added complexity.

Any thoughts on why this would be a good/bad idea? Been tried
in the past and didn't catch because... ?

On Saturday, June 12, 2021 at 3:28:17 PM UTC-5, Thomas Koenig wrote:
> The following assumes enough bits to encode it (which are always
> rare), but I'd still like to float the idea.
>
> Consider a "valid" bit associated with each register, which would
> be set by loads and calculations using this as a target register,
> and which could optionally be cleared by operations where its
> value is used, or by a store. It should also be possible to
> unset the valid bit on a register, for example on return from
> a supervisor call or possibly from a function.
<
As long as the associated bit(s) are not visible in ISA, there is no
problem. Athlon used 4-bits on the floating point registers to help
keep track of what was in the register {x87, MMX, SSE,...}
>
> Accessing a register with unset valid bit could result in
> an exception, or (less preferable) in a arbitrary value such
> as 0xdeadbeef of IBM fame.
<
How do you differentiate "value has not arrived" from "value will
never arrive"
>
> Advantages: There would be no need to write back the value
> to the physical register file, saving effort (and possibly
> making analysis easer).
<
HW write elision is pretty easy.
>
> Saving registers on function entry could be restricted on those
> which are actually valid, the same would hold for a context switch.
<
Mostly small potatoes.
>
> Disadvantages: Extra bits needed in the instruction space
> (obviously), added complexity.
>
> Any thoughts on why this would be a good/bad idea? Been tried
> in the past and didn't catch because... ?

Thomas Koenig wrote:
> The following assumes enough bits to encode it (which are always
> rare), but I'd still like to float the idea.
>
> Consider a "valid" bit associated with each register, which would
> be set by loads and calculations using this as a target register,
> and which could optionally be cleared by operations where its
> value is used, or by a store. It should also be possible to
> unset the valid bit on a register, for example on return from
> a supervisor call or possibly from a function.
>
> Accessing a register with unset valid bit could result in
> an exception, or (less preferable) in a arbitrary value such
> as 0xdeadbeef of IBM fame.
>
> Advantages: There would be no need to write back the value
> to the physical register file, saving effort (and possibly
> making analysis easer).
>
> Saving registers on function entry could be restricted on those
> which are actually valid, the same would hold for a context switch.
>
> Disadvantages: Extra bits needed in the instruction space
> (obviously), added complexity.
>
> Any thoughts on why this would be a good/bad idea? Been tried
> in the past and didn't catch because... ?
>
You have looked at Mill I assume/hope?

A belt location has several metadata bits associated with it, including
both None (i.e. similar to a DB NULL) and NaR (which is a generalized NaN).

Terje

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

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Thomas Koenig wrote:
>> The following assumes enough bits to encode it (which are always
>> rare), but I'd still like to float the idea.
>>
>> Consider a "valid" bit associated with each register, which would
>> be set by loads and calculations using this as a target register,
>> and which could optionally be cleared by operations where its
>> value is used, or by a store. It should also be possible to
>> unset the valid bit on a register, for example on return from
>> a supervisor call or possibly from a function.
>>
>> Accessing a register with unset valid bit could result in
>> an exception, or (less preferable) in a arbitrary value such
>> as 0xdeadbeef of IBM fame.
>>
>> Advantages: There would be no need to write back the value
>> to the physical register file, saving effort (and possibly
>> making analysis easer).
>>
>> Saving registers on function entry could be restricted on those
>> which are actually valid, the same would hold for a context switch.
>>
>> Disadvantages: Extra bits needed in the instruction space
>> (obviously), added complexity.
>>
>> Any thoughts on why this would be a good/bad idea? Been tried
>> in the past and didn't catch because... ?
>>
> You have looked at Mill I assume/hope?

I would have liked to, but the documents I have been able to find
were very sparse - a humungous instruction list and some very
general remarks was all I found.

Is there more info in a readily available format? (And I don't
consider an hour-long talk on Youtube to be "readily available" :-)

On Saturday, June 12, 2021 at 3:18:53 PM UTC-6, MitchAlsup wrote:

> How do you differentiate "value has not arrived" from "value will
> never arrive"

This of course depends on what the valid bits are used for.

But assuming a conventional architecture, the valid bits add no
new problem. A valid bit is meant to tell the user that 'you are
accessing an uninitialized register'.

In an architecture without valid bits, which is pipelined, interlocks
prevent an instruction using a value in a register that is the result of
a calculation... using the wrong value, because the calculation isn't
finished yet. If the 'valid bit' is meant strictly as a way of dealing with
uninitialized values, its presence won't mean that interlocks are in
any way dispensed with.

John Savard

On Saturday, June 12, 2021 at 2:28:17 PM UTC-6, Thomas Koenig wrote:

> and which could optionally be cleared by operations where its
> value is used, or by a store.

And why on Earth would anyone want to do _that_, since these things
wouldn't make the value in the register invalid, or the register
uninitialized?

John Savard

On Monday, June 14, 2021 at 12:09:02 AM UTC-6, Thomas Koenig wrote:

> Is there more info in a readily available format? (And I don't
> consider an hour-long talk on Youtube to be "readily available" :-)

Ah. I was going to say there were a bunch of videos in which the
intent of the architecture was explained, but I see you've heard of
them.

However, those videos were discussed in this group, but of course,
*now* those discussions aren't that easily accessible.

John Savard

On 6/13/2021 11:09 PM, Thomas Koenig wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>> Thomas Koenig wrote:
>>> The following assumes enough bits to encode it (which are always
>>> rare), but I'd still like to float the idea.
>>>
>>> Consider a "valid" bit associated with each register, which would
>>> be set by loads and calculations using this as a target register,
>>> and which could optionally be cleared by operations where its
>>> value is used, or by a store. It should also be possible to
>>> unset the valid bit on a register, for example on return from
>>> a supervisor call or possibly from a function.
>>>
>>> Accessing a register with unset valid bit could result in
>>> an exception, or (less preferable) in a arbitrary value such
>>> as 0xdeadbeef of IBM fame.
>>>
>>> Advantages: There would be no need to write back the value
>>> to the physical register file, saving effort (and possibly
>>> making analysis easer).
>>>
>>> Saving registers on function entry could be restricted on those
>>> which are actually valid, the same would hold for a context switch.
>>>
>>> Disadvantages: Extra bits needed in the instruction space
>>> (obviously), added complexity.
>>>
>>> Any thoughts on why this would be a good/bad idea? Been tried
>>> in the past and didn't catch because... ?
>>>
>> You have looked at Mill I assume/hope?
>
> I would have liked to, but the documents I have been able to find
> were very sparse - a humungous instruction list and some very
> general remarks was all I found.
>
> Is there more info in a readily available format? (And I don't
> consider an hour-long talk on Youtube to be "readily available" :-)
>

I share your distaste for videos that amount to someone reading the
slides that you could read yourself only faster. However, video permits
animation that text does not, and for some things (such as the Mill)
seeing it actually work gives much more insight than reading a
description of how it works. YMMV.

Well BTAIM, you have human doc available. What kind of presentation
would you consider "readily available"?

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Saturday, June 12, 2021 at 3:18:53 PM UTC-6, MitchAlsup wrote:
>
>> How do you differentiate "value has not arrived" from "value will
>> never arrive"
>
> This of course depends on what the valid bits are used for.
>
> But assuming a conventional architecture, the valid bits add no
> new problem. A valid bit is meant to tell the user that 'you are
> accessing an uninitialized register'.

Or accessing a register that has been used by a called
function.

Another thought is that there that the value can be eliminated
from the register value.

Ivan Godard <ivan@millcomputing.com> schrieb:

> Well BTAIM, you have human doc available. What kind of presentation
> would you consider "readily available"?

First, thanks for the offer.

Some sort of document that it is possible to browse through without
having to go through more than 20 hours of videos would be
great - some sort of introductory text (or presentation) about the
principles, what instructions look like, how they are processed,
what serves as registers, what metadata there is and many other
points that you and others have alluded to on this group.

Something like Mitch's document about the My 66000 operations
(which really explained the special points about his architecture
well) or even the overview chapters in the POWER ISA, for
example, would be great.

I come at ISAs from a compiler perspective - I like to see how
code (preferably for my personal favorite, modern Fortran) is and
should be translated, and how well this works. I would also like
to be able to read assembler code, and see how well this works,
or where the compiler should be improved. For this, I need some
kind of mental model of what happens in a CPU. And, of course,
I am all in favor of ISAs which allow efficient operation.

So... anything shorter than the vidos available? I don't know
how self-explanatory the slides from your talks are, maybe
these could be published?

On 6/14/2021 10:02 AM, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>
>> Well BTAIM, you have human doc available. What kind of presentation
>> would you consider "readily available"?
>
> First, thanks for the offer.
>
> Some sort of document that it is possible to browse through without
> having to go through more than 20 hours of videos would be
> great - some sort of introductory text (or presentation) about the
> principles, what instructions look like, how they are processed,
> what serves as registers, what metadata there is and many other
> points that you and others have alluded to on this group.
>
> Something like Mitch's document about the My 66000 operations
> (which really explained the special points about his architecture
> well) or even the overview chapters in the POWER ISA, for
> example, would be great.
>
> I come at ISAs from a compiler perspective - I like to see how
> code (preferably for my personal favorite, modern Fortran) is and
> should be translated, and how well this works. I would also like
> to be able to read assembler code, and see how well this works,
> or where the compiler should be improved. For this, I need some
> kind of mental model of what happens in a CPU. And, of course,
> I am all in favor of ISAs which allow efficient operation.
>
> So... anything shorter than the vidos available? I don't know
> how self-explanatory the slides from your talks are, maybe
> these could be published?
>

The slides are and have always been published; you will find them next
to the videos on millcomputing.com. You need real Powerpoint; the clones
choke on animations (or at least they used to; try and see if you want).

An introductory Mill book would be very valuable I agree. There is a
great dearth of tech writers though, especially those who will work
sweat equity. If you would like to help fix this problem please send me
a note to ivan at the millcomputing site and describe your prior
experience writing such books.

For Fortran, you compile with flang into LLVM. The resulting IR is the
same as you get from C or C++. As a practical matter, to understand the
code gen you must learn to read LLVM IR; it's well documented and you
can run all the tests you want. The Mill itself is an ISA, and doesn't
care about the source language used so long as LLVM will eat it. The
Mill tool chain has made no front-end or middle-end modifications to
standard LLVM. We do not yet support gcc or MS.

Not much I can do about the plenitude of instructions; there are over a
thousand models, because we use an attributed definition where most
other docs just define the major opcodes and leave the attributes to the
fine print. Still, it is true that the Mill is far more orthogonal than
most, which leads to more instructions but simpler hardware.

For example, all operations that can cause integer overflow come in four
flavors of overflow handling behavior. Perhaps you would prefer to see
one integer add page that mentions a two bit overflow field in passing.
Our doc uses four pages, one for each, because they are intended for use
by people looking up a hex pattern from a code dump, not for casual
browsers. Yes, this gets out of hand for you what with all the FP
instructions that come in every rounding mode, but you are not the
target audience.

However, it's not the instruction set that distinguishes a Mill;
although there are lots of changes rung on the basics, there are very
few instructions that you wouldn't recognize in the next RISC off a bus.
What is different is the macro architecture. We have found that
explaining temporal addressing, split-stream encoding, virtual zero,
phasing... the list is not short - requires pictures, and specifically
animations. So look at the slides. My benign commentary in the videos
may be helpful if you need more. If that fails too then I'm here for
concrete questions.

Ivan

Ivan Godard <ivan@millcomputing.com> schrieb:
> On 6/14/2021 10:02 AM, Thomas Koenig wrote:
>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>
>>> Well BTAIM, you have human doc available. What kind of presentation
>>> would you consider "readily available"?
>>
>> First, thanks for the offer.
>>
>> Some sort of document that it is possible to browse through without
>> having to go through more than 20 hours of videos would be
>> great - some sort of introductory text (or presentation) about the
>> principles, what instructions look like, how they are processed,
>> what serves as registers, what metadata there is and many other
>> points that you and others have alluded to on this group.
>>
>> Something like Mitch's document about the My 66000 operations
>> (which really explained the special points about his architecture
>> well) or even the overview chapters in the POWER ISA, for
>> example, would be great.
>>
>> I come at ISAs from a compiler perspective - I like to see how
>> code (preferably for my personal favorite, modern Fortran) is and
>> should be translated, and how well this works. I would also like
>> to be able to read assembler code, and see how well this works,
>> or where the compiler should be improved. For this, I need some
>> kind of mental model of what happens in a CPU. And, of course,
>> I am all in favor of ISAs which allow efficient operation.
>>
>> So... anything shorter than the vidos available? I don't know
>> how self-explanatory the slides from your talks are, maybe
>> these could be published?
>>
>
> The slides are and have always been published; you will find them next
> to the videos on millcomputing.com. You need real Powerpoint; the clones
> choke on animations (or at least they used to; try and see if you want).
>
> An introductory Mill book would be very valuable I agree.

I don't think it would have to be a whole book; some sort of
technical report or white paper would be quite helpful already.

>There is a
> great dearth of tech writers though, especially those who will work
> sweat equity. If you would like to help fix this problem please send me
> a note to ivan at the millcomputing site and describe your prior
> experience writing such books.

Thanks, but I am a technical writer (I wrote a couple of chapters
for a couple of books, and some patents, where the focus far less on
legibility). I also don't really have a lot of time due to a
full-time day job :-)

> For Fortran, you compile with flang into LLVM. The resulting IR is the
> same as you get from C or C++.

Sure.

The interesting question is how well the IR matches the semantics
of the language in question, and the semantics of the machine language.

For example, Fortran has array expressions which need to be
translated into the IR. If the IR does not have arrays as
first-class citizens, this requires scalarization, i.e. translation
into scalar loops, which is a) hairy and b) prone to add additional
restrictions which Fortran language definition does not have: it
needs to chose an iteration order or loop ordering, which may not
be optimum and which the middle end (which is usually based on
some sort of C-like model) would need to figure out and correct.

This is the reason, for example, why I added loop interchange to
FORALL and DO CONCURRENT in gortran, because the gcc middle end
didn't get it right.

>As a practical matter, to understand the
> code gen you must learn to read LLVM IR; it's well documented and you
> can run all the tests you want. The Mill itself is an ISA, and doesn't
> care about the source language used so long as LLVM will eat it. The
> Mill tool chain has made no front-end or middle-end modifications to
> standard LLVM.

And the question then is... how information much is lost along that way?

My usual way is to look at source code and assembly output,
and see what goes wrong. If the assembler is readable
(and I have a mental model of what the processor does) then
misoptimizations (or wrong code) can be blindingly obvious,
such as in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622
(which we discussed here a bit ago, and which has been fixed in
the meantime on gcc trunk by deletion of code, always the best way).

There are also things where an ISA matches very well to language
construct. For example, for My 66000, I would stronlgy expect

WHERE (a>0)
a = a + 3
ELSEWHERE
a = a + b
END WHERE

to be translated into a VEC / LOOP pair with a predicate inside.
If not, I would open a missed-optimization bug report.

> Not much I can do about the plenitude of instructions; there are over a
> thousand models, because we use an attributed definition where most
> other docs just define the major opcodes and leave the attributes to the
> fine print. Still, it is true that the Mill is far more orthogonal than
> most, which leads to more instructions but simpler hardware.

I don't mind many instructions (or I would never look at POWER in my
life :-)

> For example, all operations that can cause integer overflow come in four
> flavors of overflow handling behavior. Perhaps you would prefer to see
> one integer add page that mentions a two bit overflow field in passing.
> Our doc uses four pages, one for each, because they are intended for use
> by people looking up a hex pattern from a code dump, not for casual
> browsers.

Is that information available somewhere? What I have found so far is
http://millcomputing.com/wiki/Instruction_Set but that is not enough
to get a grip on what happens, and nothing I found specifically
mentions encodings.

[...]

> However, it's not the instruction set that distinguishes a Mill;
> although there are lots of changes rung on the basics, there are very
> few instructions that you wouldn't recognize in the next RISC off a bus.
> What is different is the macro architecture. We have found that
> explaining temporal addressing, split-stream encoding, virtual zero,
> phasing... the list is not short - requires pictures, and specifically
> animations. So look at the slides. My benign commentary in the videos
> may be helpful if you need more. If that fails too then I'm here for
> concrete questions.

I'll look at it, and see if it is enough to form that mental
picture. Thanks!

On 6/15/2021 2:49 AM, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>> On 6/14/2021 10:02 AM, Thomas Koenig wrote:
>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>
>>>> Well BTAIM, you have human doc available. What kind of presentation
>>>> would you consider "readily available"?
>>>
>>> First, thanks for the offer.
>>>
>>> Some sort of document that it is possible to browse through without
>>> having to go through more than 20 hours of videos would be
>>> great - some sort of introductory text (or presentation) about the
>>> principles, what instructions look like, how they are processed,
>>> what serves as registers, what metadata there is and many other
>>> points that you and others have alluded to on this group.
>>>
>>> Something like Mitch's document about the My 66000 operations
>>> (which really explained the special points about his architecture
>>> well) or even the overview chapters in the POWER ISA, for
>>> example, would be great.
>>>
>>> I come at ISAs from a compiler perspective - I like to see how
>>> code (preferably for my personal favorite, modern Fortran) is and
>>> should be translated, and how well this works. I would also like
>>> to be able to read assembler code, and see how well this works,
>>> or where the compiler should be improved. For this, I need some
>>> kind of mental model of what happens in a CPU. And, of course,
>>> I am all in favor of ISAs which allow efficient operation.
>>>
>>> So... anything shorter than the vidos available? I don't know
>>> how self-explanatory the slides from your talks are, maybe
>>> these could be published?
>>>
>>
>> The slides are and have always been published; you will find them next
>> to the videos on millcomputing.com. You need real Powerpoint; the clones
>> choke on animations (or at least they used to; try and see if you want).
>>
>> An introductory Mill book would be very valuable I agree.
>
> I don't think it would have to be a whole book; some sort of
> technical report or white paper would be quite helpful already.
>
>> There is a
>> great dearth of tech writers though, especially those who will work
>> sweat equity. If you would like to help fix this problem please send me
>> a note to ivan at the millcomputing site and describe your prior
>> experience writing such books.
>
> Thanks, but I am a technical writer (I wrote a couple of chapters
> for a couple of books, and some patents, where the focus far less on
> legibility). I also don't really have a lot of time due to a
> full-time day job :-)
>
>> For Fortran, you compile with flang into LLVM. The resulting IR is the
>> same as you get from C or C++.
>
> Sure.
>
> The interesting question is how well the IR matches the semantics
> of the language in question, and the semantics of the machine language.
>
> For example, Fortran has array expressions which need to be
> translated into the IR. If the IR does not have arrays as
> first-class citizens, this requires scalarization, i.e. translation
> into scalar loops, which is a) hairy and b) prone to add additional
> restrictions which Fortran language definition does not have: it
> needs to chose an iteration order or loop ordering, which may not
> be optimum and which the middle end (which is usually based on
> some sort of C-like model) would need to figure out and correct.
>
> This is the reason, for example, why I added loop interchange to
> FORALL and DO CONCURRENT in gortran, because the gcc middle end
> didn't get it right.

And I'm sure your changes were beneficial, but they are all above the
ISA level. We take what LLVM gives us; if the user isn't satisfied with
LLVM then it's not for us to fix. If they persuade LLVM to fix their
issue, and the fix forces a change to the IR, then our software will
track that change.

>> As a practical matter, to understand the
>> code gen you must learn to read LLVM IR; it's well documented and you
>> can run all the tests you want. The Mill itself is an ISA, and doesn't
>> care about the source language used so long as LLVM will eat it. The
>> Mill tool chain has made no front-end or middle-end modifications to
>> standard LLVM.
>
> And the question then is... how information much is lost along that way?
>
> My usual way is to look at source code and assembly output,
> and see what goes wrong. If the assembler is readable
> (and I have a mental model of what the processor does) then
> misoptimizations (or wrong code) can be blindingly obvious,
> such as in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622
> (which we discussed here a bit ago, and which has been fixed in
> the meantime on gcc trunk by deletion of code, always the best way).

The report you cite is for QOI, not architecture. In our pre-alpha state
we don't need QOI reports; we generate more than enough ourselves :-)

> There are also things where an ISA matches very well to language
> construct. For example, for My 66000, I would stronlgy expect
>
> WHERE (a>0)
> a = a + 3
> ELSEWHERE
> a = a + b
> END WHERE
>
> to be translated into a VEC / LOOP pair with a predicate inside.
> If not, I would open a missed-optimization bug report.
>
>> Not much I can do about the plenitude of instructions; there are over a
>> thousand models, because we use an attributed definition where most
>> other docs just define the major opcodes and leave the attributes to the
>> fine print. Still, it is true that the Mill is far more orthogonal than
>> most, which leads to more instructions but simpler hardware.
>
> I don't mind many instructions (or I would never look at POWER in my
> life :-)
>
>> For example, all operations that can cause integer overflow come in four
>> flavors of overflow handling behavior. Perhaps you would prefer to see
>> one integer add page that mentions a two bit overflow field in passing.
>> Our doc uses four pages, one for each, because they are intended for use
>> by people looking up a hex pattern from a code dump, not for casual
>> browsers.
>
> Is that information available somewhere? What I have found so far is
> http://millcomputing.com/wiki/Instruction_Set but that is not enough
> to get a grip on what happens, and nothing I found specifically
> mentions encodings.
>
> [...]

Encodings are mechanically generated and differ for each slot of each
family member. During development the member configurations change
frequently, which can completely alter the encoding. This makes a
traditional ISA book possible but unwieldy. Rather than explode the page
count by a factor of a hundred or so, the pages you looked at omit the
(immediately out of date) binary encoding and show only the attributes.

The mutability will of course drop off as we get closer to physical
fabrication, but the context dependency of the binary encoding will
persist; to interpret a bit pattern you will have to know where the
instruction came from.

The whole approach is currently being reworked to improve the human
factors involved; this may result in an interactive tool instead of a
static book, but that's not settled. As a consequence of the way our
development process works, I have no idea when that rework will be done
and made available. Please be patient.

>> However, it's not the instruction set that distinguishes a Mill;
>> although there are lots of changes rung on the basics, there are very
>> few instructions that you wouldn't recognize in the next RISC off a bus.
>> What is different is the macro architecture. We have found that
>> explaining temporal addressing, split-stream encoding, virtual zero,
>> phasing... the list is not short - requires pictures, and specifically
>> animations. So look at the slides. My benign commentary in the videos
>> may be helpful if you need more. If that fails too then I'm here for
>> concrete questions.
>
> I'll look at it, and see if it is enough to form that mental
> picture. Thanks!
>

On 6/15/2021 5:29 AM, Ivan Godard wrote:
> On 6/15/2021 2:49 AM, Thomas Koenig wrote:
>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>> On 6/14/2021 10:02 AM, Thomas Koenig wrote:
>>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>>
>>>>> Well BTAIM, you have human doc available. What kind of presentation
>>>>> would you consider "readily available"?
>>>>
>>>> First, thanks for the offer.
>>>>
>>>> Some sort of document that it is possible to browse through without
>>>> having to go through more than 20 hours of videos would be
>>>> great - some sort of introductory text (or presentation) about the
>>>> principles, what instructions look like, how they are processed,
>>>> what serves as registers, what metadata there is and many other
>>>> points that you and others have alluded to on this group.
>>>>
>>>> Something like Mitch's document about the My 66000 operations
>>>> (which really explained the special points about his architecture
>>>> well) or even the overview chapters in the POWER ISA, for
>>>> example, would be great.
>>>>
>>>> I come at ISAs from a compiler perspective - I like to see how
>>>> code (preferably for my personal favorite, modern Fortran) is and
>>>> should be translated, and how well this works.  I would also like
>>>> to be able to read assembler code, and see how well this works,
>>>> or where the compiler should be improved.  For this, I need some
>>>> kind of mental model of what happens in a CPU.  And, of course,
>>>> I am all in favor of ISAs which allow efficient operation.
>>>>
>>>> So... anything shorter than the vidos available?  I don't know
>>>> how self-explanatory the slides from your talks are, maybe
>>>> these could be published?
>>>>
>>>
>>> The slides are and have always been published; you will find them next
>>> to the videos on millcomputing.com. You need real Powerpoint; the clones
>>> choke on animations (or at least they used to; try and see if you want).
>>>
>>> An introductory Mill book would be very valuable I agree.
>>
>> I don't think it would have to be a whole book; some sort of
>> technical report or white paper would be quite helpful already.
>>
>>> There is a
>>> great dearth of tech writers though, especially those who will work
>>> sweat equity. If you would like to help fix this problem please send me
>>> a note to ivan at the millcomputing site and describe your prior
>>> experience writing such books.
>>
>> Thanks, but I am a technical writer (I wrote a couple of chapters
>> for a couple of books, and some patents, where the focus far less on
>> legibility).  I also don't really have a lot of time due to a
>> full-time day job :-)
>>
>>> For Fortran, you compile with flang into LLVM. The resulting IR is the
>>> same as you get from C or C++.
>>
>> Sure.
>>
>> The interesting question is how well the IR matches the semantics
>> of the language in question, and the semantics of the machine language.
>>
>> For example, Fortran has array expressions which need to be
>> translated into the IR.  If the IR does not have arrays as
>> first-class citizens, this requires scalarization, i.e. translation
>> into scalar loops, which is a) hairy and b) prone to add additional
>> restrictions which Fortran language definition does not have: it
>> needs to chose an iteration order or loop ordering, which may not
>> be optimum and which the middle end (which is usually based on
>> some sort of C-like model) would need to figure out and correct.
>>
>> This is the reason, for example, why I added loop interchange to
>> FORALL and DO CONCURRENT in gortran, because the gcc middle end
>> didn't get it right.
>
> And I'm sure your changes were beneficial, but they are all above the
> ISA level. We take what LLVM gives us; if the user isn't satisfied with
> LLVM then it's not for us to fix. If they persuade LLVM to fix their
> issue, and the fix forces a change to the IR, then our software will
> track that change.
>
>>> As a practical matter, to understand the
>>> code gen you must learn to read LLVM IR; it's well documented and you
>>> can run all the tests you want. The Mill itself is an ISA, and doesn't
>>> care about the source language used so long as LLVM will eat it. The
>>> Mill tool chain has made no front-end or middle-end modifications to
>>> standard LLVM.
>>
>> And the question then is... how information much is lost along that way?
>>
>> My usual way is to look at source code and assembly output,
>> and see what goes wrong.  If the assembler is readable
>> (and I have a mental model of what the processor does) then
>> misoptimizations (or wrong code) can be blindingly obvious,
>> such as in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622
>> (which we discussed here a bit ago, and which has been fixed in
>> the meantime on gcc trunk by deletion of code, always the best way).
>
> The report you cite is for QOI, not architecture. In our pre-alpha state
> we don't need QOI reports; we generate more than enough ourselves :-)
>
>> There are also things where an ISA matches very well to language
>> construct.  For example, for My 66000, I would stronlgy expect
>>
>>     WHERE (a>0)
>>       a = a + 3
>>     ELSEWHERE
>>       a = a + b
>>     END WHERE
>>
>> to be translated into a VEC / LOOP pair with a predicate inside.
>> If not, I would open a missed-optimization bug report.
>>
>>> Not much I can do about the plenitude of instructions; there are over a
>>> thousand models, because we use an attributed definition where most
>>> other docs just define the major opcodes and leave the attributes to the
>>> fine print. Still, it is true that the Mill is far more orthogonal than
>>> most, which leads to more instructions but simpler hardware.
>>
>> I don't mind many instructions (or I would never look at POWER in my
>> life :-)
>>
>>> For example, all operations that can cause integer overflow come in four
>>> flavors of overflow handling behavior. Perhaps you would prefer to see
>>> one integer add page that mentions a two bit overflow field in passing.
>>> Our doc uses four pages, one for each, because they are intended for use
>>> by people looking up a hex pattern from a code dump, not for casual
>>> browsers.
>>
>> Is that information available somewhere?  What I have found so far is
>> http://millcomputing.com/wiki/Instruction_Set but that is not enough
>> to get a grip on what happens, and nothing I found specifically
>> mentions encodings.
>>
>> [...]
>
> Encodings are mechanically generated and differ for each slot of each
> family member. During development the member configurations change
> frequently, which can completely alter the encoding. This makes a
> traditional ISA book possible but unwieldy. Rather than explode the page
> count by a factor of a hundred or so, the pages you looked at omit the
> (immediately out of date) binary encoding and show only the attributes.

I may be wrong here, but it appears to me that Thomas doesn't understand
the idea of GenAsm and specialization. I won't try to explain that
here, as Ivan can certainly do a much better job, but I think that for
what Thomas wants, at least initially, understanding what GenAsm gets
generated may be more useful, at least initially, than the specifics of
the model dependent encoding. Of course, he still needs to understand
basic concepts like the belt, etc.

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

Le 12/06/2021 à 22:28, Thomas Koenig a écrit :
> Advantages: There would be no need to write back the value
> to the physical register file, saving effort (and possibly
> making analysis easer).

I don't really get it. In what kind of microarchitecture would a
register be written back if it had not been modified anyway?

> Saving registers on function entry could be restricted on those
> which are actually valid, the same would hold for a context switch.

Yeah, why not. Except...

You need to figure out what a valid register means exactly. It's not
hard to figure that all registers would be flagged invalid upon 'reset'.
But once a given register has been written to, what exactly would make
it "invalid" again? This doesn't make much sense to me. I think I've
read in a later post that a register being "read" would then be flagged
invalid? That just doesn't work. In a normal execution flow, it's
extremely common that registers are read several times. If you don't
allow this, you would have to make the compiled code extremely inefficient.

So all in all, I just don't get it.

On Tuesday, June 15, 2021 at 4:49:30 AM UTC-5, Thomas Koenig wrote:
> Ivan Godard <iv...@millcomputing.com> schrieb:
> > On 6/14/2021 10:02 AM, Thomas Koenig wrote:
> >> Ivan Godard <iv...@millcomputing.com> schrieb:
> >>
> >>> Well BTAIM, you have human doc available. What kind of presentation
> >>> would you consider "readily available"?
> >>
> >> First, thanks for the offer.
> >>
> >> Some sort of document that it is possible to browse through without
> >> having to go through more than 20 hours of videos would be
> >> great - some sort of introductory text (or presentation) about the
> >> principles, what instructions look like, how they are processed,
> >> what serves as registers, what metadata there is and many other
> >> points that you and others have alluded to on this group.
> >>
> >> Something like Mitch's document about the My 66000 operations
> >> (which really explained the special points about his architecture
> >> well) or even the overview chapters in the POWER ISA, for
> >> example, would be great.
> >>
> >> I come at ISAs from a compiler perspective - I like to see how
> >> code (preferably for my personal favorite, modern Fortran) is and
> >> should be translated, and how well this works. I would also like
> >> to be able to read assembler code, and see how well this works,
> >> or where the compiler should be improved. For this, I need some
> >> kind of mental model of what happens in a CPU. And, of course,
> >> I am all in favor of ISAs which allow efficient operation.
> >>
> >> So... anything shorter than the vidos available? I don't know
> >> how self-explanatory the slides from your talks are, maybe
> >> these could be published?
> >>
> >
> > The slides are and have always been published; you will find them next
> > to the videos on millcomputing.com. You need real Powerpoint; the clones
> > choke on animations (or at least they used to; try and see if you want).
> >
> > An introductory Mill book would be very valuable I agree.
> I don't think it would have to be a whole book; some sort of
> technical report or white paper would be quite helpful already.
> >There is a
> > great dearth of tech writers though, especially those who will work
> > sweat equity. If you would like to help fix this problem please send me
> > a note to ivan at the millcomputing site and describe your prior
> > experience writing such books.
> Thanks, but I am a technical writer (I wrote a couple of chapters
> for a couple of books, and some patents, where the focus far less on
> legibility). I also don't really have a lot of time due to a
> full-time day job :-)
> > For Fortran, you compile with flang into LLVM. The resulting IR is the
> > same as you get from C or C++.
> Sure.
>
> The interesting question is how well the IR matches the semantics
> of the language in question, and the semantics of the machine language.
<
Having read my share of LLVM IR after doing the My 66000 ISA, I can
state that the IR is a superset of your typical RISC machine. IT has
the majority of RISC ISA and PHI operators--which tell the back end to
allocate all of the PHI operand to the same register. Kind of clean and
neat at the same time.
>
> For example, Fortran has array expressions which need to be
> translated into the IR. If the IR does not have arrays as
> first-class citizens, this requires scalarization, i.e. translation
> into scalar loops, which is a) hairy and b) prone to add additional
> restrictions which Fortran language definition does not have: it
> needs to chose an iteration order or loop ordering, which may not
> be optimum and which the middle end (which is usually based on
> some sort of C-like model) would need to figure out and correct.
>
> This is the reason, for example, why I added loop interchange to
> FORALL and DO CONCURRENT in gortran, because the gcc middle end
> didn't get it right.
> >As a practical matter, to understand the
> > code gen you must learn to read LLVM IR; it's well documented and you
> > can run all the tests you want. The Mill itself is an ISA, and doesn't
> > care about the source language used so long as LLVM will eat it. The
> > Mill tool chain has made no front-end or middle-end modifications to
> > standard LLVM.
> And the question then is... how information much is lost along that way?
>
> My usual way is to look at source code and assembly output,
> and see what goes wrong. If the assembler is readable
> (and I have a mental model of what the processor does) then
> misoptimizations (or wrong code) can be blindingly obvious,
> such as in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622
> (which we discussed here a bit ago, and which has been fixed in
> the meantime on gcc trunk by deletion of code, always the best way).
>
> There are also things where an ISA matches very well to language
> construct. For example, for My 66000, I would stronlgy expect
>
> WHERE (a>0)
> a = a + 3
> ELSEWHERE
> a = a + b
> END WHERE
>
> to be translated into a VEC / LOOP pair with a predicate inside.
> If not, I would open a missed-optimization bug report.
> > Not much I can do about the plenitude of instructions; there are over a
> > thousand models, because we use an attributed definition where most
> > other docs just define the major opcodes and leave the attributes to the
> > fine print. Still, it is true that the Mill is far more orthogonal than
> > most, which leads to more instructions but simpler hardware.
> I don't mind many instructions (or I would never look at POWER in my
> life :-)
> > For example, all operations that can cause integer overflow come in four
> > flavors of overflow handling behavior. Perhaps you would prefer to see
> > one integer add page that mentions a two bit overflow field in passing.
> > Our doc uses four pages, one for each, because they are intended for use
> > by people looking up a hex pattern from a code dump, not for casual
> > browsers.
> Is that information available somewhere? What I have found so far is
> http://millcomputing.com/wiki/Instruction_Set but that is not enough
> to get a grip on what happens, and nothing I found specifically
> mentions encodings.
>
> [...]
> > However, it's not the instruction set that distinguishes a Mill;
> > although there are lots of changes rung on the basics, there are very
> > few instructions that you wouldn't recognize in the next RISC off a bus.
> > What is different is the macro architecture. We have found that
> > explaining temporal addressing, split-stream encoding, virtual zero,
> > phasing... the list is not short - requires pictures, and specifically
> > animations. So look at the slides. My benign commentary in the videos
> > may be helpful if you need more. If that fails too then I'm here for
> > concrete questions.
> I'll look at it, and see if it is enough to form that mental
> picture. Thanks!
<
Since you are a "bit" familiar with source to asm relationships, you
should be able to read you way to LLVM IR as a half way step.

On Tuesday, June 15, 2021 at 11:30:38 AM UTC-5, Guillaume wrote:
> Le 12/06/2021 à 22:28, Thomas Koenig a écrit :
> > Advantages: There would be no need to write back the value
> > to the physical register file, saving effort (and possibly
> > making analysis easer).
> I don't really get it. In what kind of microarchitecture would a
> register be written back if it had not been modified anyway?
<
x86 where one has a shift and a shift count of 0. In this case the write back
is there to signal that the shift is complete and anyone dependent upon it
can now proceed.
<
> > Saving registers on function entry could be restricted on those
> > which are actually valid, the same would hold for a context switch.
<
> Yeah, why not. Except...
<
How does the code at the entry point know this ? Are you going to
test and branch around the store ?
>
> You need to figure out what a valid register means exactly. It's not
> hard to figure that all registers would be flagged invalid upon 'reset'.
> But once a given register has been written to, what exactly would make
> it "invalid" again? This doesn't make much sense to me. I think I've
> read in a later post that a register being "read" would then be flagged
> invalid? That just doesn't work. In a normal execution flow, it's
> extremely common that registers are read several times. If you don't
> allow this, you would have to make the compiled code extremely inefficient.
>
> So all in all, I just don't get it.

On 6/15/2021 8:48 AM, Stephen Fuld wrote:
> On 6/15/2021 5:29 AM, Ivan Godard wrote:
>> On 6/15/2021 2:49 AM, Thomas Koenig wrote:
>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>> On 6/14/2021 10:02 AM, Thomas Koenig wrote:
>>>>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>>>>
>>>>>> Well BTAIM, you have human doc available. What kind of presentation
>>>>>> would you consider "readily available"?
>>>>>
>>>>> First, thanks for the offer.
>>>>>
>>>>> Some sort of document that it is possible to browse through without
>>>>> having to go through more than 20 hours of videos would be
>>>>> great - some sort of introductory text (or presentation) about the
>>>>> principles, what instructions look like, how they are processed,
>>>>> what serves as registers, what metadata there is and many other
>>>>> points that you and others have alluded to on this group.
>>>>>
>>>>> Something like Mitch's document about the My 66000 operations
>>>>> (which really explained the special points about his architecture
>>>>> well) or even the overview chapters in the POWER ISA, for
>>>>> example, would be great.
>>>>>
>>>>> I come at ISAs from a compiler perspective - I like to see how
>>>>> code (preferably for my personal favorite, modern Fortran) is and
>>>>> should be translated, and how well this works.  I would also like
>>>>> to be able to read assembler code, and see how well this works,
>>>>> or where the compiler should be improved.  For this, I need some
>>>>> kind of mental model of what happens in a CPU.  And, of course,
>>>>> I am all in favor of ISAs which allow efficient operation.
>>>>>
>>>>> So... anything shorter than the vidos available?  I don't know
>>>>> how self-explanatory the slides from your talks are, maybe
>>>>> these could be published?
>>>>>
>>>>
>>>> The slides are and have always been published; you will find them next
>>>> to the videos on millcomputing.com. You need real Powerpoint; the
>>>> clones
>>>> choke on animations (or at least they used to; try and see if you
>>>> want).
>>>>
>>>> An introductory Mill book would be very valuable I agree.
>>>
>>> I don't think it would have to be a whole book; some sort of
>>> technical report or white paper would be quite helpful already.
>>>
>>>> There is a
>>>> great dearth of tech writers though, especially those who will work
>>>> sweat equity. If you would like to help fix this problem please send me
>>>> a note to ivan at the millcomputing site and describe your prior
>>>> experience writing such books.
>>>
>>> Thanks, but I am a technical writer (I wrote a couple of chapters
>>> for a couple of books, and some patents, where the focus far less on
>>> legibility).  I also don't really have a lot of time due to a
>>> full-time day job :-)
>>>
>>>> For Fortran, you compile with flang into LLVM. The resulting IR is the
>>>> same as you get from C or C++.
>>>
>>> Sure.
>>>
>>> The interesting question is how well the IR matches the semantics
>>> of the language in question, and the semantics of the machine language.
>>>
>>> For example, Fortran has array expressions which need to be
>>> translated into the IR.  If the IR does not have arrays as
>>> first-class citizens, this requires scalarization, i.e. translation
>>> into scalar loops, which is a) hairy and b) prone to add additional
>>> restrictions which Fortran language definition does not have: it
>>> needs to chose an iteration order or loop ordering, which may not
>>> be optimum and which the middle end (which is usually based on
>>> some sort of C-like model) would need to figure out and correct.
>>>
>>> This is the reason, for example, why I added loop interchange to
>>> FORALL and DO CONCURRENT in gortran, because the gcc middle end
>>> didn't get it right.
>>
>> And I'm sure your changes were beneficial, but they are all above the
>> ISA level. We take what LLVM gives us; if the user isn't satisfied
>> with LLVM then it's not for us to fix. If they persuade LLVM to fix
>> their issue, and the fix forces a change to the IR, then our software
>> will track that change.
>>
>>>> As a practical matter, to understand the
>>>> code gen you must learn to read LLVM IR; it's well documented and you
>>>> can run all the tests you want. The Mill itself is an ISA, and doesn't
>>>> care about the source language used so long as LLVM will eat it. The
>>>> Mill tool chain has made no front-end or middle-end modifications to
>>>> standard LLVM.
>>>
>>> And the question then is... how information much is lost along that way?
>>>
>>> My usual way is to look at source code and assembly output,
>>> and see what goes wrong.  If the assembler is readable
>>> (and I have a mental model of what the processor does) then
>>> misoptimizations (or wrong code) can be blindingly obvious,
>>> such as in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622
>>> (which we discussed here a bit ago, and which has been fixed in
>>> the meantime on gcc trunk by deletion of code, always the best way).
>>
>> The report you cite is for QOI, not architecture. In our pre-alpha
>> state we don't need QOI reports; we generate more than enough
>> ourselves :-)
>>
>>> There are also things where an ISA matches very well to language
>>> construct.  For example, for My 66000, I would stronlgy expect
>>>
>>>     WHERE (a>0)
>>>       a = a + 3
>>>     ELSEWHERE
>>>       a = a + b
>>>     END WHERE
>>>
>>> to be translated into a VEC / LOOP pair with a predicate inside.
>>> If not, I would open a missed-optimization bug report.
>>>
>>>> Not much I can do about the plenitude of instructions; there are over a
>>>> thousand models, because we use an attributed definition where most
>>>> other docs just define the major opcodes and leave the attributes to
>>>> the
>>>> fine print. Still, it is true that the Mill is far more orthogonal than
>>>> most, which leads to more instructions but simpler hardware.
>>>
>>> I don't mind many instructions (or I would never look at POWER in my
>>> life :-)
>>>
>>>> For example, all operations that can cause integer overflow come in
>>>> four
>>>> flavors of overflow handling behavior. Perhaps you would prefer to see
>>>> one integer add page that mentions a two bit overflow field in passing.
>>>> Our doc uses four pages, one for each, because they are intended for
>>>> use
>>>> by people looking up a hex pattern from a code dump, not for casual
>>>> browsers.
>>>
>>> Is that information available somewhere?  What I have found so far is
>>> http://millcomputing.com/wiki/Instruction_Set but that is not enough
>>> to get a grip on what happens, and nothing I found specifically
>>> mentions encodings.
>>>
>>> [...]
>>
>> Encodings are mechanically generated and differ for each slot of each
>> family member. During development the member configurations change
>> frequently, which can completely alter the encoding. This makes a
>> traditional ISA book possible but unwieldy. Rather than explode the
>> page count by a factor of a hundred or so, the pages you looked at
>> omit the (immediately out of date) binary encoding and show only the
>> attributes.
>
> I may be wrong here, but it appears to me that Thomas doesn't understand
> the idea of GenAsm and specialization.  I won't try to explain that
> here, as Ivan can certainly do a much better job, but I think that for
> what Thomas wants, at least initially, understanding what GenAsm gets
> generated may be more useful, at least initially, than the specifics of
> the model dependent encoding.  Of course, he still needs to understand
> basic concepts like the belt, etc.

On 6/15/2021 9:30 AM, Guillaume wrote:
> Le 12/06/2021 à 22:28, Thomas Koenig a écrit :
>> Advantages: There would be no need to write back the value
>> to the physical register file, saving effort (and possibly
>> making analysis easer).
>
> I don't really get it. In what kind of microarchitecture would a
> register be written back if it had not been modified anyway?
>
>> Saving registers on function entry could be restricted on those
>> which are actually valid, the same would hold for a context switch.
>
> Yeah, why not. Except...
>
> You need to figure out what a valid register means exactly. It's not
> hard to figure that all registers would be flagged invalid upon 'reset'.
> But once a given register has been written to, what exactly would make
> it "invalid" again? This doesn't make much sense to me. I think I've
> read in a later post that a register being "read" would then be flagged
> invalid? That just doesn't work. In a normal execution flow, it's
> extremely common that registers are read several times. If you don't
> allow this, you would have to make the compiled code extremely inefficient.
>
> So all in all, I just don't get it.

There have been many efforts to have a "last use" signal of some kind in
the instructions. It usually runs foul of encoding constraints, as in so
many shoehorning efforts here and elsewhere. Some feature that costs a
bit in each register specifier needs to have some glaring advantage and
none has been found.

An alternative is to have registers implicitly "time out" in some way;
the belt is an example. Another is to partition the register banks by
lifetime: maybe one bank expires on first use, another doesn't expire.
Such a scheme implies a NURA architecture; perhaps something of the sort
would fit into Mitch's SuperPDP11.

Thomas Koenig <tkoenig@netcologne.de> schrieb:

> Thanks, but I am a technical writer

That should have read "I am not a technical writer".

On 6/15/2021 9:30 AM, Guillaume wrote:
> Le 12/06/2021 à 22:28, Thomas Koenig a écrit :
>> Advantages: There would be no need to write back the value
>> to the physical register file, saving effort (and possibly
>> making analysis easer).
>
> I don't really get it. In what kind of microarchitecture would a
> register be written back if it had not been modified anyway?
>
>> Saving registers on function entry could be restricted on those
>> which are actually valid, the same would hold for a context switch.
>
> Yeah, why not. Except...
>
> You need to figure out what a valid register means exactly. It's not
> hard to figure that all registers would be flagged invalid upon 'reset'.
> But once a given register has been written to, what exactly would make
> it "invalid" again?

How about you have started the execution of a load instruction, but the
memory system hasn't yet returned the value? You don't want to use the
"old"/existing value, but the new value isn't available yet.

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

On Tuesday, June 15, 2021 at 11:52:53 AM UTC-5, Thomas Koenig wrote:
> Thomas Koenig <tko...@netcologne.de> schrieb:
> > Thanks, but I am a technical writer
> That should have read "I am not a technical writer".
<
Would it be rude of me to point out that that is bit more than a minor typo ?

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Tuesday, June 15, 2021 at 11:52:53 AM UTC-5, Thomas Koenig wrote:
>> Thomas Koenig <tko...@netcologne.de> schrieb:
>> > Thanks, but I am a technical writer
>> That should have read "I am not a technical writer".
><
> Would it be rude of me to point out that that is bit more than a minor typo ?

No, please go ahead.

On Tuesday, June 15, 2021 at 12:36:24 PM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Tuesday, June 15, 2021 at 11:52:53 AM UTC-5, Thomas Koenig wrote:
> >> Thomas Koenig <tko...@netcologne.de> schrieb:
> >> > Thanks, but I am a technical writer
> >> That should have read "I am not a technical writer".
> ><
> > Would it be rude of me to point out that that is bit more than a minor typo ?
> No, please go ahead.
<
At this point is no longer seem necessary.

Le 15/06/2021 à 18:39, MitchAlsup a écrit :
> On Tuesday, June 15, 2021 at 11:30:38 AM UTC-5, Guillaume wrote:
>> Le 12/06/2021 à 22:28, Thomas Koenig a écrit :
>>> Advantages: There would be no need to write back the value
>>> to the physical register file, saving effort (and possibly
>>> making analysis easer).
>> I don't really get it. In what kind of microarchitecture would a
>> register be written back if it had not been modified anyway?
> <
> x86 where one has a shift and a shift count of 0. In this case the write back
> is there to signal that the shift is complete and anyone dependent upon it
> can now proceed.

That's really an oddball here. How worth it can it be to go through such
extents just to marginally improve I'm not even sure what in the end?