> I have just looked at PSHUFB
> <https://www.felixcloutier.com/x86/pshufb>, and I found the
> operational semantics more enlightening than the prose. So there are
> cases where formal stuff is competetive. But in most cases it's too
> unwieldy.

I can't remember ever seeing a formal semantics alone without someone
complaining about the lack of accompanying prose. So you clearly need
all 3 (i.e. prose, formal definition, and examples).

It's not just to maximize the chance that the user will understand at
least one formulation, but also because redundancy is necessary to
increase the chance that bugs can be clearly seen as bugs (and not as
"well, that's what the spec says, so it must be a feature").

Stefan

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
> On 3/2/2022 3:24 AM, aph@littlepinkcloud.invalid wrote:
> > Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:
> >>
> >> (32 bit ARM is interesting as it was designed to be nice to program
> >> in assembly, a consideration not normally part of instruction set
> >> design these days)
> >
> > That's an interesting point. In my experience 64-bit ARM is as nice to
> > program in assembly, at least as far as the set of base instructions
> > goes, even though there are more instructions.
> >
> > I also believe that if an instruction set is nice to program in
> > assembly, it's also nice to write a code generator for.
>
> Wasn't one of the results from the studies of generated code,that was
> used to justify RISC, that "nice to write assembly in" features such as
> complex and orthogonal addressing modes just weren't used in generated code?

Yes and no. For example, ARM32 has function prologues that look something
like this:

..myfunction
STMFD sp!, {r0-r12,lr} ; save all the registers
<function body>
LDMFD sp!, {r0-r12,pc} ; unstack and set pc<-old_lr

whereas classic RISC would be something like:

..myfunction
ADDI sp, sp, #-nn ; make space on the stack
ST r0, [sp, #0]
ST r1, [sp, #4]
ST r2, [sp, #8]
....
ST lr, [sp, #nn]
<function body>
LD r0, [sp, #0]
LD r1, [sp, #4]
LD r2, [sp, #8]
....
LD lr, [sp, #nn]
ADDI sp, sp, #nn
ADD pc, lr, 0

STM/LDM is more complicated to implement (and a bit of a burden down the
years), but it makes the programmer's life a lot easier and the compiler
does use it.

Theo

On 3/2/2022 1:41 PM, Stefan Monnier wrote:
>> I have just looked at PSHUFB
>> <https://www.felixcloutier.com/x86/pshufb>, and I found the
>> operational semantics more enlightening than the prose. So there are
>> cases where formal stuff is competetive. But in most cases it's too
>> unwieldy.
>
> I can't remember ever seeing a formal semantics alone without someone
> complaining about the lack of accompanying prose. So you clearly need
> all 3 (i.e. prose, formal definition, and examples).
>
> It's not just to maximize the chance that the user will understand at
> least one formulation, but also because redundancy is necessary to
> increase the chance that bugs can be clearly seen as bugs (and not as
> "well, that's what the spec says, so it must be a feature").

Take a look at the Revised Report and the Informal Introduction, and see
if you find them sufficient.

van Wijngaarden, Adriaan; Mailloux, Barry James; Peck, John Edward
Lancelot; Koster, Cornelis Hermanus Antonius; Sintzoff, Michel; Lindsey,
Charles Hodgson; Meertens, Lambert Guillaume Louis Théodore; Fisker,
Richard G., eds. (1976). Revised Report on the Algorithmic Language
ALGOL 68 (PDF). Springer-Verlag. ISBN 978-0-387-07592-1. OCLC 1991170

Lindsey, Charles H.; van der Meulen, S. G. (1977). An Informal
Introduction to Algol 68. Amsterdam; Oxford: North-Holland Publishing.
ISBN 0-7204-0726-5

Both at archive.org

On Wednesday, March 2, 2022 at 4:02:15 PM UTC-6, Theo wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> wrote:
> > On 3/2/2022 3:24 AM, a...@littlepinkcloud.invalid wrote:
> > > Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> > >>
> > >> (32 bit ARM is interesting as it was designed to be nice to program
> > >> in assembly, a consideration not normally part of instruction set
> > >> design these days)
> > >
> > > That's an interesting point. In my experience 64-bit ARM is as nice to
> > > program in assembly, at least as far as the set of base instructions
> > > goes, even though there are more instructions.
> > >
> > > I also believe that if an instruction set is nice to program in
> > > assembly, it's also nice to write a code generator for.
> >
> > Wasn't one of the results from the studies of generated code,that was
> > used to justify RISC, that "nice to write assembly in" features such as
> > complex and orthogonal addressing modes just weren't used in generated code?
> Yes and no. For example, ARM32 has function prologues that look something
> like this:
>
> .myfunction
> STMFD sp!, {r0-r12,lr} ; save all the registers
> <function body>
> LDMFD sp!, {r0-r12,pc} ; unstack and set pc<-old_lr
>
> whereas classic RISC would be something like:
>
> .myfunction
> ADDI sp, sp, #-nn ; make space on the stack
> ST r0, [sp, #0]
> ST r1, [sp, #4]
> ST r2, [sp, #8]
> ...
> ST lr, [sp, #nn]
> <function body>
> LD r0, [sp, #0]
> LD r1, [sp, #4]
> LD r2, [sp, #8]
> ...
> LD lr, [sp, #nn]
> ADDI sp, sp, #nn
> ADD pc, lr, 0
>
GLOBAL myfunction
ENTRY myfunction
myfunction:
ENTER R16,R0,sizeof( local_data )
< function body>
EXIT R16,R0,sizeof( local_data )
<
When used with stack frames R30 is manipulated in a controlled fashion,
SP is always manipulated. First it is used to push the registers on a stack
then it gets the constant subtracted allocating a stack frame.
<
When using the safe stack:: the registers get pushed on a stack this thread
has no access to (RWE = 000) and the registers store on that stack get
zeroed.
<
Code other than longjump() cannot even tell if safe stack is in use or not.
>
> STM/LDM is more complicated to implement (and a bit of a burden down the
> years), but it makes the programmer's life a lot easier and the compiler
> does use it.
>
> Theo

According to <aph@littlepinkcloud.invalid>:
>I also believe that if an instruction set is nice to program in
>assembly, it's also nice to write a code generator for. ...

Maybe. The VAX was designed to be stupendously uniform but
if you wanted to generate good code you needed to know
what was likely to be fast and what wasn't.

Compare that to the 801 where they took out all of the instructions
that the PL.8 compiler didn't generate. In later iterations they
put back a few things like load/store multiple that turned out to
be worth both putting in hardware and teaching the compiler about,
at least for procedure prolog and epilog.

--
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 Wednesday, March 2, 2022 at 6:18:15 PM UTC-6, John Levine wrote:
> According to <a...@littlepinkcloud.invalid>:
> >I also believe that if an instruction set is nice to program in
> >assembly, it's also nice to write a code generator for. ...
>
> Maybe. The VAX was designed to be stupendously uniform but
> if you wanted to generate good code you needed to know
> what was likely to be fast and what wasn't.
<
Most of the address modes added from 68010 to 68020 were
slower than performing the same in straight line code.
<
But the real surprise was that the VAX CALL/RET sequences
was so slow that some code got nearly a factor of 2× by converting
to BSR/JSR instead of using CALL.
>
> Compare that to the 801 where they took out all of the instructions
> that the PL.8 compiler didn't generate. In later iterations they
> put back a few things like load/store multiple that turned out to
> be worth both putting in hardware and teaching the compiler about,
> at least for procedure prolog and epilog.
>
>
>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

Theo <theom+news@chiark.greenend.org.uk> schrieb:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>> On 3/2/2022 3:24 AM, aph@littlepinkcloud.invalid wrote:
>> > Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:
>> >>
>> >> (32 bit ARM is interesting as it was designed to be nice to program
>> >> in assembly, a consideration not normally part of instruction set
>> >> design these days)
>> >
>> > That's an interesting point. In my experience 64-bit ARM is as nice to
>> > program in assembly, at least as far as the set of base instructions
>> > goes, even though there are more instructions.
>> >
>> > I also believe that if an instruction set is nice to program in
>> > assembly, it's also nice to write a code generator for.
>>
>> Wasn't one of the results from the studies of generated code,that was
>> used to justify RISC, that "nice to write assembly in" features such as
>> complex and orthogonal addressing modes just weren't used in generated code?
>
> Yes and no. For example, ARM32 has function prologues that look something
> like this:
>
> .myfunction
> STMFD sp!, {r0-r12,lr} ; save all the registers
><function body>
> LDMFD sp!, {r0-r12,pc} ; unstack and set pc<-old_lr
>
> whereas classic RISC would be something like:
>
> .myfunction
> ADDI sp, sp, #-nn ; make space on the stack
> ST r0, [sp, #0]

[...]

As written elsethread, both ARM and IBM deprecated multiple store
and load instructions - ARM by not including them in aarch64, IBM
by restricting them in POWER to 32-bit size and to big-endian only.
In other words, legacy code. POWER9 microcodes it, which incurs
a significant penalty. Mitch explained that it is less a burden
to his My 66000 implementations.

aarch64 has load and store double instead.

> STM/LDM is more complicated to implement (and a bit of a burden down the
> years), but it makes the programmer's life a lot easier and the compiler
> does use it.

It will use it for function prologue and epilogue, which is usually
generated after everything else in a function body is done.

Use in a function body is much harder (depending on what exactly
is in the ISA). If you can load/store regiters up to the maximum
register number that you have (POWER) or a register range (My
66000), you would have to work your whole register allocation
around the load/store multiple instruction. This would be
rather inconvenient, and I suspect that compilers would not use
it.

An instruction where you can load or store each register
individually would be easy to use, by comparison.

Ivan Godard <ivan@millcomputing.com> schrieb:
> On 3/2/2022 9:40 AM, Anton Ertl wrote:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>>> Ivan Godard <ivan@millcomputing.com> writes:
>>>>> Declarable (!) precedence was a disaster
>>>>> in A68 - what's the precedence of left circular shift?
>>>>
>>>> IMO the general concept of precedence is a disaster. You can do
>>>> implicit parenthesizing between well-established pairs of operators
>>>> (e.g., a+b*c,
>>>
>>> You should.
>>>
>>> FORTRAN pretty much settled this question. Evaluating a formula
>>> in any other way is a desaster.
>>
>> What disaster would ensue from not accepting a+b*c and instead
>> requiring a+(b*c)? However, it seems to me that the relative
>> precedences of + and * and widely-enough known that accepting a+b*c
>> instead does not cause problems.
>
> Well, if we are going to match mathematic practice that should be
> "a+bc"; there have been historical efforts toward that sort of thing.

Restricting the user to single-letter variables would not be such
a great idea, I think.

An alternative could be to use the space for multiplication, but that
is also probably not such a good idea (and would not have worked
for the original fixed format in FORTRAN).

> However, claiming familiarity as justification suffices only so long as
> + and * mean addition and multiplication. In the presence of declarable
> operator overloading however...

Operator overloading does not always improve legibility.

>There are well established mathematical
> domains in which * is not associative and neither commute, yet those
> symbols are used.

In that case (for example matrix multiplication) it is probably
better to use functions.

[...]

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>Wasn't one of the results from the studies of generated code,that was
>used to justify RISC, that "nice to write assembly in" features such as
>complex and orthogonal addressing modes just weren't used in generated code?

There are multiple aspects to this:

* Compilers around 1980 may have had a hard time generating some of
these addressing modes, and that's why they did not generate them.
For other features like instructions with implicit registers, this
is mostly still true.

* These addressing modes may have been slow, and that's why compilers
did not generate them.

* The compiler may have been able to generate them, but the access
pattern represented by the addressing mode occurs rarely, so it
occurs rarely in generated code (yet implementing the addressing
mode incurs a cost).

The other aspect is what programmers consider "nice to write in
assembly". I think that there are psychological red herrings at work,
e.g., the feeling of achievement when the programmer has found a case
where he can change the access pattern such that the complex
addressing mode can be used and saves an instruction or two. Even if
the actual execution counts of such instructions are low, programmers
tend to create an emotional attachment to these features.

And I don't think it's just the orthogonal features that can profit
from this effect. However, I guess that the orthogonal features have
additional honeypot potential because they are theoretically more
widely useful than non-orthogonal features like the 8086s LODS
instruction.

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

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
> On 3/2/2022 3:24 AM, aph@littlepinkcloud.invalid wrote:
>> Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:
>>>
>>> (32 bit ARM is interesting as it was designed to be nice to program
>>> in assembly, a consideration not normally part of instruction set
>>> design these days)
>>
>> That's an interesting point. In my experience 64-bit ARM is as nice to
>> program in assembly, at least as far as the set of base instructions
>> goes, even though there are more instructions.
>>
>> I also believe that if an instruction set is nice to program in
>> assembly, it's also nice to write a code generator for.
>
> Wasn't one of the results from the studies of generated code,that
> was used to justify RISC, that "nice to write assembly in" features
> such as complex and orthogonal addressing modes just weren't used in
> generated code?

Are complex addressing modes nice to write assembly in, though? I've
never found it to be so. I think the problem identified with IBM 370
was that many of the addressing modes weren't being used by compilers
or by hand-cranked code, but I can't find any data for that one way or
the other.

I can see the point of orthogonality, as long as it's not extended too
far. Of course no-one actually wants to have to use, say, a dedicated
pair of registers to do a multiply.

Andrew.

Ivan Godard <ivan@millcomputing.com> writes:
>On 3/2/2022 9:40 AM, Anton Ertl wrote:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>> FORTRAN pretty much settled this question. Evaluating a formula
>>> in any other way is a desaster.
>>
>> What disaster would ensue from not accepting a+b*c and instead
>> requiring a+(b*c)? However, it seems to me that the relative
>> precedences of + and * and widely-enough known that accepting a+b*c
>> instead does not cause problems.
>
>Well, if we are going to match mathematic practice that should be
>"a+bc"; there have been historical efforts toward that sort of thing.

This suffers from programmers using multi-character names (for good
reason), unlike mathematicians.

>However, claiming familiarity as justification suffices only so long as
>+ and * mean addition and multiplication. In the presence of declarable
>operator overloading however... There are well established mathematical
>domains in which * is not associative and neither commute, yet those
>symbols are used.

Associativity and commutativity don't play a role for the question of
whether a+b*c means (a+b)*c or a+(b*c). Whether the kind of
user-defined operator overloading on a syntax with fixed precedences
pioniered (or mainstreamed?) by C++ is a good idea is another
discussion. I don't have enough C++ experience to tell.

Lack of commutativity has not kept mathematicians from using the
established multiplication notation for matrix multiplication; and
programming languages seem to do ok with using + for string
concatenation.

Lack of associativity has not kept mathematicians and programming
languages from accepting "a-b-c", and I am not aware of problems with
that. Of course, one might wonder if it's a good idea to use a
normally associative operator like + for a non-associative operation
like FP addition, but that has a tradition going at least as far back
as Fortran (and one might justify it by saying that, like FP
approximates reals, FP addition approximates the addition of reals,
which is associative).

>Once out of arithmetic and into mathematics there really is no "natural"
>precedence. Still, your argument is sound because most computation is
>arithmetic and for common usage there are few operators.

My argument is actually that the normal case should be to require
explicit parentheses, and we can make a few exceptions to that rule
(but they should really be few).

>You ever used
>Iverson's APL?

No. A friend of mine uses APL occasionally, but I have only watched
him program it.

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

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>FWIW, Ada makes "a or b and c" illegal and requires parentheses.

Good.

>But Ada allows "not a and b"

Bad.

>with "not" having higher precedence than "and". I
>would recommend parentheses there, or writing it as "b and not a".

Accepting "b and not a" while not accepting "not a and b" would be the
way to go.

>"a + b and c" is legal Ada

Bad.

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

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Anton Ertl wrote:

>> I have made productive use of treating the results of comparisons as
>> numbers or masks, so I think it's a feature.

I disagree there. I have no objection to a function that transforms
a logical variable to a numeric one (which would be elided by the
compiler, of course).

>> The misfeature in C is a
>> syntax that accepts "a+b&c".
>
> That should at the very least be a warning: Is the intention "(a+b) & c"
> or is it "a + (b & c)"?
>
> IntelliJ flags lots of constructs that are legal but potentially
> non-obvious to anyone reading the code.

So does gcc:

$ cat b.c
unsigned int
foo (unsigned int a, unsigned int b, unsigned int c)
{ return a + b & c;
} $ gcc -c -Wall b.c
b.c: In function ‘foo’:
b.c:4:12: warning: suggest parentheses around ‘+’ in operand of ‘&’ [-Wparentheses]
4 | return a + b & c;
|

(clang doesn't, but complains about a missing prototype with
-Weverything).

On 3/3/2022 3:05 AM, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>> On 3/2/2022 9:40 AM, Anton Ertl wrote:
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>>>> Ivan Godard <ivan@millcomputing.com> writes:
>>>>>> Declarable (!) precedence was a disaster
>>>>>> in A68 - what's the precedence of left circular shift?
>>>>>
>>>>> IMO the general concept of precedence is a disaster. You can do
>>>>> implicit parenthesizing between well-established pairs of operators
>>>>> (e.g., a+b*c,
>>>>
>>>> You should.
>>>>
>>>> FORTRAN pretty much settled this question. Evaluating a formula
>>>> in any other way is a desaster.
>>>
>>> What disaster would ensue from not accepting a+b*c and instead
>>> requiring a+(b*c)? However, it seems to me that the relative
>>> precedences of + and * and widely-enough known that accepting a+b*c
>>> instead does not cause problems.
>>
>> Well, if we are going to match mathematic practice that should be
>> "a+bc"; there have been historical efforts toward that sort of thing.
>
> Restricting the user to single-letter variables would not be such
> a great idea, I think.

Was highly successful in the original BASIC.

Thomas Koenig <tkoenig@netcologne.de> writes:
>As written elsethread, both ARM and IBM deprecated multiple store
>and load instructions - ARM by not including them in aarch64, IBM
>by restricting them in POWER to 32-bit size and to big-endian only.
>In other words, legacy code. POWER9 microcodes it, which incurs
>a significant penalty. Mitch explained that it is less a burden
>to his My 66000 implementations.
>
>aarch64 has load and store double instead.
....
>Use in a function body is much harder (depending on what exactly
>is in the ISA). If you can load/store regiters up to the maximum
>register number that you have (POWER) or a register range (My
>66000), you would have to work your whole register allocation
>around the load/store multiple instruction. This would be
>rather inconvenient, and I suspect that compilers would not use
>it.

I have certainly seen quite a few load-pair and store-pair
instructions in gcc-generated Aarch64 code outside function
prologue/epilogue:

In the 6008 lines of output from "objdump -d
engine/engine-fast-ll-reg.o" (pretty much a single large function),
ldp occurs 133 times (among them 24 accesses through sp) and stp
occurs 76 times (17 accesses through sp). The accesses through sp are
probably around function calls, the others are other pairwise accesses
that the compiler could combine.

So I expect that efficient load-multiple or store-multiple
instructions would also be used by gcc; the question is how often
there would be cases with more than two registers. Apparently not
enough to make the Aarch64 architects add instructions for that.

The benefit of the load-pair and store-pair instructions over a pair
of loads/stores is that they reduce load/store-unit contention; of
course, the RISC-V answer to that is that the decoder can combine such
a pair into one pairwise micro-instruction.

>An instruction where you can load or store each register
>individually would be easy to use, by comparison.

Do you mean something other than a normal load or store instruction?

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

On 3/3/2022 3:40 AM, Anton Ertl wrote:
<snip>

> My argument is actually that the normal case should be to require
> explicit parentheses, and we can make a few exceptions to that rule
> (but they should really be few).

But (as noted by several commenters here) that leads to informal
parenthesizing everything in the name of readability and safety. But if
that's the result, why not dump all precedence entirely?

On 3/3/2022 4:02 AM, Anton Ertl wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> FWIW, Ada makes "a or b and c" illegal and requires parentheses.
>
> Good.
>
>> But Ada allows "not a and b"
>
> Bad.
>
>> with "not" having higher precedence than "and". I
>> would recommend parentheses there, or writing it as "b and not a".
>
> Accepting "b and not a" while not accepting "not a and b" would be the
> way to go.
>
>> "a + b and c" is legal Ada
>
> Bad.

Mary:
a not and b => (not a) and b
a and b not => not (a and b)
a and (b not) => a and (not b)

strict left-to-right order; monadic operators in suffix form.

Anton Ertl wrote:
> And I don't think it's just the orthogonal features that can profit
> from this effect. However, I guess that the orthogonal features have
> additional honeypot potential because they are theoretically more
> widely useful than non-orthogonal features like the 8086s LODS
> instruction.

Those original string ops on the 8088 were absolutely crucial, simply
because they allowed us to write extremely compact code.

On a CPU where all bytes read or stored (including instruction bytes
which usually would dominate) would take 4 cycles, using those
single-byte opcodes with auto-increment/decrement was the difference
between "too slow" and "usable".

Terje

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

Ivan Godard <ivan@millcomputing.com> writes:
>On 3/3/2022 3:40 AM, Anton Ertl wrote:
><snip>
>
>> My argument is actually that the normal case should be to require
>> explicit parentheses, and we can make a few exceptions to that rule
>> (but they should really be few).
>
>But (as noted by several commenters here) that leads to informal
>parenthesizing everything in the name of readability and safety.

I have no idea what "informal parenthesizing" is supposed to mean. If
you mean that nobody writes "a+b*c", I think you are wrong. But of
course, having zero exceptions to the rule of requiring explicit
parentheses is fine with me.

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

Anton Ertl wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>> As written elsethread, both ARM and IBM deprecated multiple store
>> and load instructions - ARM by not including them in aarch64, IBM
>> by restricting them in POWER to 32-bit size and to big-endian only.
>> In other words, legacy code. POWER9 microcodes it, which incurs
>> a significant penalty. Mitch explained that it is less a burden
>> to his My 66000 implementations.
>>
>> aarch64 has load and store double instead.
> ....
>> Use in a function body is much harder (depending on what exactly
>> is in the ISA). If you can load/store regiters up to the maximum
>> register number that you have (POWER) or a register range (My
>> 66000), you would have to work your whole register allocation
>> around the load/store multiple instruction. This would be
>> rather inconvenient, and I suspect that compilers would not use
>> it.
>
> I have certainly seen quite a few load-pair and store-pair
> instructions in gcc-generated Aarch64 code outside function
> prologue/epilogue:
>
> In the 6008 lines of output from "objdump -d
> engine/engine-fast-ll-reg.o" (pretty much a single large function),
> ldp occurs 133 times (among them 24 accesses through sp) and stp
> occurs 76 times (17 accesses through sp). The accesses through sp are
> probably around function calls, the others are other pairwise accesses
> that the compiler could combine.
>
> So I expect that efficient load-multiple or store-multiple
> instructions would also be used by gcc; the question is how often
> there would be cases with more than two registers. Apparently not
> enough to make the Aarch64 architects add instructions for that.
>
> The benefit of the load-pair and store-pair instructions over a pair
> of loads/stores is that they reduce load/store-unit contention; of
> course, the RISC-V answer to that is that the decoder can combine such
> a pair into one pairwise micro-instruction.

The register save set size sets the minimum width of a number of resources,
the number of register read and write ports,
width that LSQ should handle including store-load forwarding.
With LDP/STP 2*64 it should not be a hardship even for a minimal
implementation.

For LDM/STM to run at full speed it would need to operate on a
full 64B cache line, 8 register wide datapath to/from memory. That's
- 8 read ports on the rename tables
- 8 read and 8 write register file ports
- 8 operand buses to LSQ, store-load forwarding,
(possibly also internally forwarding withing the LSQ itself)
and input operand forwarding from FU results
- 8 result buses from LSQ, with output forwarding
(plus possibly internal forwarding withing the LSQ itself)
- 512 bit datapath to/from cache with alignment shifters for line straddles.

and it would still need some kind of microcode sequencer for
when there was more than 8 save/restore registers in a set.

On 3/3/2022 5:07 AM, Anton Ertl wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
>> On 3/3/2022 3:40 AM, Anton Ertl wrote:
>> <snip>
>>
>>> My argument is actually that the normal case should be to require
>>> explicit parentheses, and we can make a few exceptions to that rule
>>> (but they should really be few).
>>
>> But (as noted by several commenters here) that leads to informal
>> parenthesizing everything in the name of readability and safety.
>
> I have no idea what "informal parenthesizing" is supposed to mean. If
> you mean that nobody writes "a+b*c", I think you are wrong. But of
> course, having zero exceptions to the rule of requiring explicit
> parentheses is fine with me.
>
> - anton

"informal parenthesizing": syntactic rules required by convention but
not by formal syntax.

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>Anton Ertl wrote:
>> And I don't think it's just the orthogonal features that can profit
>> from this effect. However, I guess that the orthogonal features have
>> additional honeypot potential because they are theoretically more
>> widely useful than non-orthogonal features like the 8086s LODS
>> instruction.
>
>Those original string ops on the 8088 were absolutely crucial, simply
>because they allowed us to write extremely compact code.
>
>On a CPU where all bytes read or stored (including instruction bytes
>which usually would dominate) would take 4 cycles, using those
>single-byte opcodes with auto-increment/decrement was the difference
>between "too slow" and "usable".

I am wondering if this is a demonstration of the feeling of
achievement that creates an attachment to these features.

What was the proportion of these instructions in production code,
statically and dynamically?

Looking at an example, here's a table of implementations of NEXT
(virtual machine instruction dispatch) in various assembly languages:

PDP-11 6809 8086 8086'
next: mov (ip)+,w ldx ,y++ lods lods ax
mov bx,ax mov bx,ax
next1: jmp @(w)+ jmp [,x] mov dx,bx jmp word ptr[bx]
inc dx
jmp word ptr[bx]

IP and W are aliases for PDP-11 registers; IP/Y/SI is the virtual
machine instruction pointer.

8086 is what's in the table (originally from the fig-Forth listing,
like the PDP-11 and the 6809 variants), 8086' is a cleaned-up version
that does not pull stuff up from some of the possible jump targets.

So we see here that the implicit registers of lods combined with the
limitations of usable registers in the jmp conspire to require an
additional mov instruction. Not sure if this really saves code size
compared to the 6809 or PDP-11.

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

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:

>>An instruction where you can load or store each register
>>individually would be easy to use, by comparison.
>
> Do you mean something other than a normal load or store instruction?

What I mean is is a single instruction which optionally loads
or stores every register there is.

Hmm... looking at ARM, it seems that this is indeed more
or less implemented with LDM and STM - they have a 16-bit
mask which specifies which registers to transfer, and 32-bit
ARM has only 16 registers, so that fits.

The same could be done with more registers, but it is (obiously)
not possible to do with 32 registers for an ISA with 32 bit
instructions.

Compilers should have no problem using it, though.

On Thursday, March 3, 2022 at 1:48:32 AM UTC-6, Thomas Koenig wrote:
> Theo <theom...@chiark.greenend.org.uk> schrieb:
> > Stephen Fuld <sf...@alumni.cmu.edu.invalid> wrote:
> >> On 3/2/2022 3:24 AM, a...@littlepinkcloud.invalid wrote:
> >> > Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> >> >>
> >> >> (32 bit ARM is interesting as it was designed to be nice to program
> >> >> in assembly, a consideration not normally part of instruction set
> >> >> design these days)
> >> >
> >> > That's an interesting point. In my experience 64-bit ARM is as nice to
> >> > program in assembly, at least as far as the set of base instructions
> >> > goes, even though there are more instructions.
> >> >
> >> > I also believe that if an instruction set is nice to program in
> >> > assembly, it's also nice to write a code generator for.
> >>
> >> Wasn't one of the results from the studies of generated code,that was
> >> used to justify RISC, that "nice to write assembly in" features such as
> >> complex and orthogonal addressing modes just weren't used in generated code?
> >
> > Yes and no. For example, ARM32 has function prologues that look something
> > like this:
> >
> > .myfunction
> > STMFD sp!, {r0-r12,lr} ; save all the registers
> ><function body>
> > LDMFD sp!, {r0-r12,pc} ; unstack and set pc<-old_lr
> >
> > whereas classic RISC would be something like:
> >
> > .myfunction
> > ADDI sp, sp, #-nn ; make space on the stack
> > ST r0, [sp, #0]
> [...]
>
> As written elsethread, both ARM and IBM deprecated multiple store
> and load instructions - ARM by not including them in aarch64, IBM
> by restricting them in POWER to 32-bit size and to big-endian only.
> In other words, legacy code. POWER9 microcodes it, which incurs
> a significant penalty. Mitch explained that it is less a burden
> to his My 66000 implementations.
>
> aarch64 has load and store double instead.
> > STM/LDM is more complicated to implement (and a bit of a burden down the
> > years), but it makes the programmer's life a lot easier and the compiler
> > does use it.
> It will use it for function prologue and epilogue, which is usually
> generated after everything else in a function body is done.
>
> Use in a function body is much harder (depending on what exactly
> is in the ISA). If you can load/store regiters up to the maximum
> register number that you have (POWER) or a register range (My
> 66000), you would have to work your whole register allocation
> around the load/store multiple instruction. This would be
> rather inconvenient, and I suspect that compilers would not use
> it.
<
I developed ABI first than figured out how to make an instruction do
everything ABI required, including putting all the arguments together
(passed in registers and passed in memory) to simplify varargs.
>
> An instruction where you can load or store each register
> individually would be easy to use, by comparison.
<
Then you get into VAX terribilisms.

On Thursday, March 3, 2022 at 5:45:20 AM UTC-6, a...@littlepinkcloud.invalid wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> wrote:
> > On 3/2/2022 3:24 AM, a...@littlepinkcloud.invalid wrote:
> >> Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> >>>
> >>> (32 bit ARM is interesting as it was designed to be nice to program
> >>> in assembly, a consideration not normally part of instruction set
> >>> design these days)
> >>
> >> That's an interesting point. In my experience 64-bit ARM is as nice to
> >> program in assembly, at least as far as the set of base instructions
> >> goes, even though there are more instructions.
> >>
> >> I also believe that if an instruction set is nice to program in
> >> assembly, it's also nice to write a code generator for.
> >
> > Wasn't one of the results from the studies of generated code,that
> > was used to justify RISC, that "nice to write assembly in" features
> > such as complex and orthogonal addressing modes just weren't used in
> > generated code?
<
> Are complex addressing modes nice to write assembly in, though? I've
> never found it to be so. I think the problem identified with IBM 370
> was that many of the addressing modes weren't being used by compilers
> or by hand-cranked code, but I can't find any data for that one way or
> the other.
<
Brian had little trouble using:
MEM Rd,[Rbase+Rindex<<size+Displacement]
as the model.
With the additions of:
Rbase = R0 substitutes IP as base register
Rindex = R0 substituted 0x0 as the index
>
> I can see the point of orthogonality, as long as it's not extended too
> far. Of course no-one actually wants to have to use, say, a dedicated
> pair of registers to do a multiply.
>
> Andrew.