On 2/28/2022 9:44 AM, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>
>> int a;
>> int foo(int b, int c) {
>> if ((b&14) == 0)
>> a = c - 1414;
>> else
>> b += c;
>> return b;
>> }
>
> Let me see if I can reasd this:
>
>> Compiled conAsm:
>> F("foo") %0 %1;
>> formals() %0 %1,
>
> Is this an actual instruction, or some sort of
> pseudo-instruction?

A pseudo. It gives the %N belt values of the arguments an identifier
definition, so that the assembler can sanity check that every identifier
has a definition.

>
>> rd(w(1414)) %7,
>
> I assume this loads a belt entry with the constant 1414.

Yes. The terminology is "drops the four-byte value 1414 to the belt"

>> sub(b2 %1, b0 %7) %4,
>
> Hm, if I understand you correctly this is
>
> %4 = sub (b2, b0), correct? Is the target always the
> last digit after the percent sign?

digits, not digit

>
>> eqlb() %3, andl(b2 %0, 14) %2,
>> storetr(b3 %4, dp, gl("a"), b2 %3),
>> add(b5 %1, b4 %0) %6,
>> retnfl(b2 %3, b0 %6),
>> retn(b5 %0);
>
> Without further explanation, this is rather hard to read, certainly
> not your average assembler syntax :-)

That's because you have to deal with temporal addressing in these
samples, whereas the topic was asm syntax. I completely agree that
temporal is hard going, even for those that are used to it; that's why
the compiler includes helpful comment that I elided to show just the
syntax.

You could use Mill asm syntax in a genreg machine that uses spatial
addressing - just replace every instance of "bM %N" with "rN". It would
look like:
rd(w(1414)) r7,
sub(r1, r7) r4
eqlb() r3, andl(r0, 14) r22,
storetr(r4, dp, gl("a"), r3),
add(r1, r0) r6,
retnfl(r3, r6),
retn(r0);

which is probably more readable for you.

Similarly, one could have a temporal assembler with conventional syntax:
"sub %4,b2 %1,b0 %7" etc. Or omit the value tracing "%N" to get "sub
b2,b0", though trust me, you don't want to do manual value tracing in
temporal addressing - it's hard enough to do in spatial, where you have
to remember what's in which register.

>>
>> Edited to remove compiler-generated documentary comment, such as source
>> line/column numbers, belt event activity description, etc. I have left
>> in the "%N" belt value identifiers, although these can be omitted in
>> manual asm (only the "bN" temporal indices are necessary).
>
>> Note that this function comprises one bundle and takes one cycle to
>> execute on a low-midrange Mill.
>
> That is rather impressive. It would also be interesting to know
> how your compiler fares with some normal Fortran code :-)

We don't have the resources to add Fortan to the development list on our
own. However, we'd welcome a Fortran expert to join the team part time
and try it out using flang and LLVM. Hint, hint...

On 2/28/2022 10:00 AM, Thomas Koenig wrote:
> John Levine <johnl@taugh.com> schrieb:
>> It appears that Ivan Godard <ivan@millcomputing.com> said:
>>> Or you can make the asm be similar to the syntax of a HLL, arguably more
>>> familiar to most readers than a traditional asm syntax, even one with
>>> your suggestions.
>>
>> I liked PL360 which was a S/360 assembler with a syntax similar to Algol.
>> Wirth used it to write Algol W. I used it some around 1970 at Princeton
>> which let people run small PL360 and AlgolW programs without needing an account.
>> I don't think they realized that PL360 was an assembler so you could write some
>> rather naughty programs if you wanted to.
>>
>> http://bitsavers.org/pdf/stanford/cs_techReports/STAN-CS-71-215_PL360_Rev_May72.pdf
>
> That is an interesting piece of software.
>
> I see they deviated from the usual meaning of
>
> R1 := R2 + R1
>
> which would scare me - one of FORTRAN's great achievement
> was to be able to write formulas naturally. But it is
> certainly the highest-level assembler I have seen yet.

The PL360 syntax goes only part way to a direct translation to a
sequence of machine instruction: PL360 ":=" is right-to-left, whereas
everything else is left-to-right without precedence. APL goes all the
way - everything is right-to-left without precedence, and Mary reversed
that.

Mary did everything left-to-right no precedence:
r3 := a+b*c=:d+e=:f;
gets you:
<use r3 for expression>
load
add
mul
store
add
store

Parentheses worked normally in Mary, and the parenthesized expression
could set another working register; in PL360 (IIRC) you had to use a
separate statement.

Ivan Godard wrote:
> That's because you have to deal with temporal addressing in these
> samples, whereas the topic was asm syntax. I completely agree that
> temporal is hard going, even for those that are used to it; that's why
> the compiler includes helpful comment that I elided to show just the
> syntax.
>
> You could use Mill asm syntax in a genreg machine that uses spatial
> addressing - just replace every instance of "bM %N" with "rN". It would
> look like:
>        rd(w(1414)) r7,
>        sub(r1, r7) r4
>        eqlb() r3, andl(r0, 14) r22,
>        storetr(r4, dp, gl("a"), r3),
>        add(r1, r0) r6,
>        retnfl(r3, r6),
>        retn(r0);
>
> which is probably more readable for you.
>
> Similarly, one could have a temporal assembler with conventional syntax:
> "sub %4,b2 %1,b0 %7" etc. Or omit the value tracing "%N" to get "sub
> b2,b0", though trust me, you don't want to do manual value tracing in
> temporal addressing - it's hard enough to do in spatial, where you have
> to remember what's in which register.

That's more or less what we did back in the 8087 days, writing a
Mandelbrot generator that tried to keep everything inside the 8-slot FP
register stack. It needed a written model with a stack pointer to index
off from. The belt never seemed that much harder to me until I got into
spill/fill traffic due to belt pressure. :-)

I suspect Anton would be quite comfortable with it as well.

Terje

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

On 2022-02-28 22:35, Ivan Godard wrote:
> On 2/28/2022 10:00 AM, Thomas Koenig wrote:
>> John Levine <johnl@taugh.com> schrieb:
>>> It appears that Ivan Godard  <ivan@millcomputing.com> said:
>>>> Or you can make the asm be similar to the syntax of a HLL, arguably
>>>> more
>>>> familiar to most readers than a traditional asm syntax, even one with
>>>> your suggestions.
>>>
>>> I liked PL360 which was a S/360 assembler with a syntax similar to
>>> Algol.
>>> Wirth used it to write Algol W.  I used it some around 1970 at Princeton
>>> which let people run small PL360 and AlgolW programs without needing
>>> an account.
>>> I don't think they realized that PL360 was an assembler so you could
>>> write some
>>> rather naughty programs if you wanted to.
>>>
>>> http://bitsavers.org/pdf/stanford/cs_techReports/STAN-CS-71-215_PL360_Rev_May72.pdf
>>>
>>
>> That is an interesting piece of software.
>>
>> I see they deviated from the usual meaning of
>>
>> R1 := R2 + R1
>>
>> which would scare me - one of FORTRAN's great achievement
>> was to be able to write formulas naturally.  But it is
>> certainly the highest-level assembler I have seen yet.

In the early 1980's I defined and implemented a similar kind of language
for the Zilog Z-80, for use in the TRS-80 microcomputers. It had some
syntax modelled on Algol 68, but only the data types and operations of
the Z-80. It also used left-to-right evaluation. Branches could only use
the condition flags, named with non-alphabetic characters such as "="
for the Z (zero, equal) flag, "#" for NZ (not zero, not equal), "<" for
the C (carry, less-than) flag, and so on.

Here is an example, a procedure that compares two non-null strings
pointed to by the HL and DE register pairs (each 16 bits), respectively,
for at most the number of bytes given in the 8-bit B register. The
procedure returns the result in the flags "=" or "#". If the strings
differ, HL and DE are left pointing at the first differing position. If
the strings are equal, HL and DE are both increased by B on return.

proc Compare
(do
if A=@DE ? @HL : # then ret fi;
HL+1; DE+1
until B-1 : = od)

The body of the do-loop loads (=) the character at DE (@DE) into the
accumulator A, then compares (?) A to the character at HL, and returns
if they differ, with the "#" (NZ) result. Otherwise HL and DE are both
incremented, B is decremented, and the loop repeats if B is still
non-zero. When B is decremented to zero, the loop ends and the procedure
returns with the "=" (Z) result.

The language was called RaKo, short for Rakenteellinen Konekieli, which
is Finnish for Structured Machine Language. The language was used for
one serious application (controlling a radio-astronomical instrument)
and of course for its own compiler/assembler, boot-strapped from a
compiler/asembler written in BASIC.

The compiler/assembler produced absolute binary directly, without any
relocatable form. Instead of a linker there was a "concatenator" that
could combine separately compiled/assembled binary files into one binary
executable file.

> The PL360 syntax goes only part way to a direct translation to a
> sequence of machine instruction: PL360 ":=" is right-to-left, whereas
> everything else is left-to-right without precedence. APL goes all the
> way - everything is right-to-left without precedence, and Mary reversed
> that.
>
> Mary did everything left-to-right no precedence:
>  r3 := a+b*c=:d+e=:f;
> gets you:
>  <use r3 for expression>
>  load
>  add
>  mul
>  store
>  add
>  store

RaKo was similar, but had no "=:" operator, so instead you had to use a
separate statement to move the result into another location. I don't
remember if I had already read about Mary when I made RaKo, but I'm sure
that I did not intend to follow the Mary model -- which is not meant as
a criticism of Mary.

> Parentheses worked normally in Mary, and the parenthesized expression
> could set another working register; in PL360 (IIRC) you had to use a
> separate statement.

RaKo had no parenthesized expressions, but they could have been added
easily.

On 3/1/2022 1:09 AM, Niklas Holsti wrote:
> On 2022-02-28 22:35, Ivan Godard wrote:
>> On 2/28/2022 10:00 AM, Thomas Koenig wrote:
>>> John Levine <johnl@taugh.com> schrieb:
>>>> It appears that Ivan Godard  <ivan@millcomputing.com> said:
>>>>> Or you can make the asm be similar to the syntax of a HLL, arguably
>>>>> more
>>>>> familiar to most readers than a traditional asm syntax, even one with
>>>>> your suggestions.
>>>>
>>>> I liked PL360 which was a S/360 assembler with a syntax similar to
>>>> Algol.
>>>> Wirth used it to write Algol W.  I used it some around 1970 at
>>>> Princeton
>>>> which let people run small PL360 and AlgolW programs without needing
>>>> an account.
>>>> I don't think they realized that PL360 was an assembler so you could
>>>> write some
>>>> rather naughty programs if you wanted to.
>>>>
>>>> http://bitsavers.org/pdf/stanford/cs_techReports/STAN-CS-71-215_PL360_Rev_May72.pdf
>>>>
>>>
>>> That is an interesting piece of software.
>>>
>>> I see they deviated from the usual meaning of
>>>
>>> R1 := R2 + R1
>>>
>>> which would scare me - one of FORTRAN's great achievement
>>> was to be able to write formulas naturally.  But it is
>>> certainly the highest-level assembler I have seen yet.
>
>
> In the early 1980's I defined and implemented a similar kind of language
> for the Zilog Z-80, for use in the TRS-80 microcomputers. It had some
> syntax modelled on Algol 68, but only the data types and operations of
> the Z-80. It also used left-to-right evaluation. Branches could only use
> the condition flags, named with non-alphabetic characters such as "="
> for the Z (zero, equal) flag, "#" for NZ (not zero, not equal), "<" for
> the C (carry, less-than) flag, and so on.
>
> Here is an example, a procedure that compares two non-null strings
> pointed to by the HL and DE register pairs (each 16 bits), respectively,
> for at most the number of bytes given in the 8-bit B register. The
> procedure returns the result in the flags "=" or "#". If the strings
> differ, HL and DE are left pointing at the first differing position. If
> the strings are equal, HL and DE are both increased by B on return.
>
>    proc Compare
>    (do
>       if A=@DE ? @HL : # then ret fi;
>       HL+1; DE+1
>    until B-1 : = od)
>
> The body of the do-loop loads (=) the character at DE (@DE) into the
> accumulator A, then compares (?) A to the character at HL, and returns
> if they differ, with the "#" (NZ) result. Otherwise HL and DE are both
> incremented, B is decremented, and the loop repeats if B is still
> non-zero. When B is decremented to zero, the loop ends and the procedure
> returns with the "=" (Z) result.
>
> The language was called RaKo, short for Rakenteellinen Konekieli, which
> is Finnish for Structured Machine Language. The language was used for
> one serious application (controlling a radio-astronomical instrument)
> and of course for its own compiler/assembler, boot-strapped from a
> compiler/asembler written in BASIC.
>
> The compiler/assembler produced absolute binary directly, without any
> relocatable form. Instead of a linker there was a "concatenator" that
> could combine separately compiled/assembled binary files into one binary
> executable file.
>
>
>> The PL360 syntax goes only part way to a direct translation to a
>> sequence of machine instruction: PL360 ":=" is right-to-left, whereas
>> everything else is left-to-right without precedence. APL goes all the
>> way - everything is right-to-left without precedence, and Mary
>> reversed that.
>>
>> Mary did everything left-to-right no precedence:
>>   r3 := a+b*c=:d+e=:f;
>> gets you:
>>   <use r3 for expression>
>>   load
>>   add
>>   mul
>>   store
>>   add
>>   store
>
>
> RaKo was similar, but had no "=:" operator, so instead you had to use a
> separate statement to move the result into another location. I don't
> remember if I had already read about Mary when I made RaKo, but I'm sure
> that I did not intend to follow the Mary model -- which is not meant as
> a criticism of Mary.

Great minds run in common :-) Declarable (!) precedence was a disaster
in A68 - what's the precedence of left circular shift? - and APL pointed
the way to abandoning precedence in a language for mathematics.

>> Parentheses worked normally in Mary, and the parenthesized expression
>> could set another working register; in PL360 (IIRC) you had to use a
>> separate statement.
>
>
> RaKo had no parenthesized expressions, but they could have been added
> easily.

Shame I never heard of RaKo at the time - would have invited you to join
IFIPS WG2.4 (Machine-Oriented Languages).

Interesting to see you using if-fi and do-od. "od" was probably my most
significant contribution to A68 - pre-Revision followed A60 syntax for
loops, and I claim credit for talking WG2.1 into do-od in the Revision.
Later in Mary I extended it to "do-in-out-od", with
again-while-until-yield as intra-loop statements, made loops be value
yielding in expressions, and supported parallel looping with multiple
control variables.

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, but not "a or b and c"), or in a few cases it's
intuitive (a<b+c, a<b and c), but that does not establish a transitive
relation (don't accept a+b and c).

My take would be to always require parenthesis when dealing with a
pair of operators that are not among the few exceptions for which a
binding relation is defined (when in doubt, don't add an exception,
e.g., for the pair of "and" and "or").

>- and APL pointed
>the way to abandoning precedence in a language for mathematics.

Always binding right-to-left is simple, and one can learn it, but it
runs counter to established practice in some cases and against
intuition in others. So it's not surprising that it did not catch on.

What is surprising to me is that C's precedences have caught on.

>Interesting to see you using if-fi and do-od. "od" was probably my most
>significant contribution to A68

And who added "fi"? Over in comp.compilers we recently had a
discussion about parser generator conflicts and the dangling-else
problem in a number of languages (e.g., Pascal and C, but not Algol
60); apparently fi was too late for Pascal and C, but it made it into
Modula. Unfortunately it was never fixed in the C descendants.

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

On 3/1/2022 4:36 AM, Anton Ertl wrote:
> Ivan Godard <ivan@millcomputing.com> writes:

>> Interesting to see you using if-fi and do-od. "od" was probably my most
>> significant contribution to A68
>
> And who added "fi"?

That was before my time in WG2.1 - I came in after the Great Schism and
during the Revision, not the initial Report. However IIRC Steve Bourne
was the major instigator, but he went with the schismatics.

> Over in comp.compilers we recently had a
> discussion about parser generator conflicts and the dangling-else
> problem in a number of languages (e.g., Pascal and C, but not Algol
> 60); apparently fi was too late for Pascal and C, but it made it into
> Modula. Unfortunately it was never fixed in the C descendants.

Wirth was a schismatic too, and never accepted VWG - "fi" was a little
easier to swallow? :-)

Ivan Godard <ivan@millcomputing.com> schrieb:

I have cross-posted this to comp.lang.fortran, maybe a volunteer will
step up there :-)

> We don't have the resources to add Fortan to the development list on our
> own. However, we'd welcome a Fortran expert to join the team part time
> and try it out using flang and LLVM. Hint, hint...

Thanks for the implied offer :-) but I think I will have to restrict
myself a bit there. I know gfortran fairly well, but getting into
flang (especially the old compiler, which is the only one that
produces workable code at the moment) is a bit more than I can do.

I can certainly provide you with *.ll files for the Polyhedron
benchmarks, for example, but the recipe for that is very simple:
Download the Polyhedron benchmarks (easy to google), unpack, cd to the
source directoy for Linux, run "flang -S -O2 -emit-llvm fatigue2.f90" (for
example), and you're set. Any of the *.f90 files are self-contained,
so you can inspect them and see what makes sense (which was enough
for me to submit a couple of github issues for My 66000).

As for running, this would require building the library, and I
have no experience at all setting up flang, which I believe is
separate from the mainline LLVM compiler.

However, if you get a gcc port running (you previously mentioned
that any compiler could, in principle, generate genAsm), I will
be happy to assist you in all matters gfortran. The same offer
also goes Mitch's My 66000, of course. I have a fondness for
unconventional architectures, which is why I hang out on comp.arch,
and which is also why I helped IBM in adapting gfortran on POWER to
IEEE 128-bit reals recently, which will be in the upcoming gcc 12.

Ivan Godard <ivan@millcomputing.com> writes:
>On 3/1/2022 4:36 AM, Anton Ertl wrote:
>> Over in comp.compilers we recently had a
>> discussion about parser generator conflicts and the dangling-else
>> problem in a number of languages (e.g., Pascal and C, but not Algol
>> 60); apparently fi was too late for Pascal and C, but it made it into
>> Modula. Unfortunately it was never fixed in the C descendants.
>
>Wirth was a schismatic too, and never accepted VWG

And nobody else has, either. From hindsight it seems that the later
languages were much more in line with the schismatics than with those
who stayed on Algol 68. But maybe I just don't know Algol 68 enough
to see all its features that eventually made it into mainstream
languages.

>- "fi" was a little
>easier to swallow? :-)

Sure, dangling else is an obvious blemish, the Algol 60 solution is
not so nice, either. Closing control structures rather than using
blocks for them is more practical in any case: You can simply add a
statement into a control structure without having to possiby add BEGIN
and END or { and }.

Actually Wirth uses END (not fi, od etc.) for everything that has a
statement sequence.

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

On 3/1/2022 9:47 AM, Anton Ertl wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
>> On 3/1/2022 4:36 AM, Anton Ertl wrote:
>>> Over in comp.compilers we recently had a
>>> discussion about parser generator conflicts and the dangling-else
>>> problem in a number of languages (e.g., Pascal and C, but not Algol
>>> 60); apparently fi was too late for Pascal and C, but it made it into
>>> Modula. Unfortunately it was never fixed in the C descendants.
>>
>> Wirth was a schismatic too, and never accepted VWG
>
> And nobody else has, either. From hindsight it seems that the later
> languages were much more in line with the schismatics than with those
> who stayed on Algol 68. But maybe I just don't know Algol 68 enough
> to see all its features that eventually made it into mainstream
> languages.

It turns out that *any* formal specification of language semantics is
beyond usual mortal ken; try reading Denotational Semantics someday :-)

When I was on the Green team (which became Ada), the subject of how we
would describe the semantics came up (BNF for syntax of course). I asked
"Maybe VWG?"
"Non, en Francaise!"
"But the reviewers don't speak French."
"So English."
"But it will be ambiguous, even with our greatest care."
(Ichbiah): " No matter - they will have paid us before they figure that
out, and then they can pay us again to fix it."

Of the various formalities I prefer VWG, and still consider it to have
been a massive advance in formal theory. Politically and marketly
however... :-(

>
>> - "fi" was a little
>> easier to swallow? :-)
>
> Sure, dangling else is an obvious blemish, the Algol 60 solution is
> not so nice, either. Closing control structures rather than using
> blocks for them is more practical in any case: You can simply add a
> statement into a control structure without having to possiby add BEGIN
> and END or { and }.

Agreed - that was Mary syntax too.

> Actually Wirth uses END (not fi, od etc.) for everything that has a
> statement sequence.
>
> - anton

On 3/1/2022 9:43 AM, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>
> I have cross-posted this to comp.lang.fortran, maybe a volunteer will
> step up there :-)
>
>> We don't have the resources to add Fortan to the development list on our
>> own. However, we'd welcome a Fortran expert to join the team part time
>> and try it out using flang and LLVM. Hint, hint...
>
> Thanks for the implied offer :-) but I think I will have to restrict
> myself a bit there. I know gfortran fairly well, but getting into
> flang (especially the old compiler, which is the only one that
> produces workable code at the moment) is a bit more than I can do.
>
> I can certainly provide you with *.ll files for the Polyhedron
> benchmarks, for example, but the recipe for that is very simple:
> Download the Polyhedron benchmarks (easy to google), unpack, cd to the
> source directoy for Linux, run "flang -S -O2 -emit-llvm fatigue2.f90" (for
> example), and you're set. Any of the *.f90 files are self-contained,
> so you can inspect them and see what makes sense (which was enough
> for me to submit a couple of github issues for My 66000).
>
> As for running, this would require building the library, and I
> have no experience at all setting up flang, which I believe is
> separate from the mainline LLVM compiler.
>
> However, if you get a gcc port running (you previously mentioned
> that any compiler could, in principle, generate genAsm), I will
> be happy to assist you in all matters gfortran. The same offer
> also goes Mitch's My 66000, of course. I have a fondness for
> unconventional architectures, which is why I hang out on comp.arch,
> and which is also why I helped IBM in adapting gfortran on POWER to
> IEEE 128-bit reals recently, which will be in the upcoming gcc 12.

Someday, but not until more talent or more money :-)

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Ivan Godard wrote:
>> That's because you have to deal with temporal addressing in these
>> samples, whereas the topic was asm syntax. I completely agree that
>> temporal is hard going, even for those that are used to it; that's why
>> the compiler includes helpful comment that I elided to show just the
>> syntax.
>>
>> You could use Mill asm syntax in a genreg machine that uses spatial
>> addressing - just replace every instance of "bM %N" with "rN". It would
>> look like:
>>        rd(w(1414)) r7,
>>        sub(r1, r7) r4
>>        eqlb() r3, andl(r0, 14) r22,
>>        storetr(r4, dp, gl("a"), r3),
>>        add(r1, r0) r6,
>>        retnfl(r3, r6),
>>        retn(r0);
>>
>> which is probably more readable for you.
>>
>> Similarly, one could have a temporal assembler with conventional syntax:
>> "sub %4,b2 %1,b0 %7" etc. Or omit the value tracing "%N" to get "sub
>> b2,b0", though trust me, you don't want to do manual value tracing in
>> temporal addressing - it's hard enough to do in spatial, where you have
>> to remember what's in which register.
>
> That's more or less what we did back in the 8087 days, writing a
> Mandelbrot generator that tried to keep everything inside the 8-slot FP
> register stack.

Ah, who didn't write Mandelbrot generators in those days...

One of the few assembler programs I wrote for the C64 was a
Mandelbrot generator which used the floating-point routines
built into the BASIC. Made about a factor of 10 difference
vs. the BASIC version. I gave that up after a friend's Amiga
was way faster in BASIC than my C64 version.

Later, for training and familiarization purposes (ahem) I wrote
a version for a vector computer, trying to find the right balance
between operations and gather/scatter (no sense in iterating over
something that had already converged). Output was on the 300 dpi
laser printer that the computer center had (what luxury!)

Thomas Koenig <tkoenig@netcologne.de> wrote:
> John Dallman <jgd@cix.co.uk> schrieb:
> > In article <svcqrj$jj6$1@newsreader4.netcologne.de>,
> > tkoenig@netcologne.de (Thomas Koenig) wrote:
> >
> >> If two instructions have a different encoding, they should have a
> >> different name. Apart from making an assembler marginally easier
> >> to write, this also makes clear what size an instruction is, if
> >> it has immediates.
> >
> > This hinges on what an assembly language is optimised for. Is it a
> > higher-level expression of a sequence of instructions, or a low-level
> > representation of a program? Those aren't quite the same thing, although
> > assembly languages do both duties.
>
> I would say the latter, except when using macros.

I think there's scope for doing both. Have a programmer friendly form that
elides some of the tedious details (eg it's fine to use ADD with an
immediate without calling it ADDI).

And then have a normalised form that has a 1:1 translation to the
instruction bit patterns. The normalised form is useful when you're for
example disassembling and reassembling a binary: it means that process will
produce exactly the same binary, without leaving any wiggle room for
different choices by the assembler.

You could maybe take that too far, eg on 32 bit ARM:

ADR r3, label

might disassemble to:

ADD r3, pc, #0x200

but the really anal normalised version might be:

ADDAL r3, r15, #0x2 LSL 8

Perhaps the middle form would be OK, as long as convention describes exactly
how eg intermediate constants are represented, so there is no ambiguity.
If the disassembler came across an instruction that represent it as:

ADD r3, pc, #0x20 LSL 4

that would need a different disassembly format (like the above, perhaps).

(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)

Theo

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. This was one of the biggest steps
that FORTRAN took. Earlier programming languages which did
not have that features invited programming errors.

> but not "a or b and c"),

and is multiplication, or is (saturating) addition, so the precedence
is intuitive (at least if the relationship above is intuitive).

> or in a few cases it's
> intuitive (a<b+c, a<b and c), but that does not establish a transitive
> relation (don't accept a+b and c).

Conflating of numeric anc logical types is a misfeature rather specific
to C and its decendants. Introduce a distinct logical type and most
problems of that kind go away.

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. Tweako
special-case instructions are a pain to remember, but they're also a
pain to generate code for automatically.

Andrew.

Ivan Godard <ivan@millcomputing.com> writes:
>It turns out that *any* formal specification of language semantics is
>beyond usual mortal ken; try reading Denotational Semantics someday :-)

I have. Did not find it inspiring.

I think that formal stuff can be ok for certain aspects; (E)BNF is the
poster child for that, although the informal specification of the
resolution of the dangling else problem by Wirth demonstrates that
even EBNF is occasionally too complicated.

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.

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

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.

>> but not "a or b and c"),
>
>and is multiplication, or is (saturating) addition, so the precedence
>is intuitive (at least if the relationship above is intuitive).

It's not at all intuitive, and I expect that

* newbies relatively frequently make mistakes when they rely on precedence.

* experienced programmers and more cautious newbies use parentheses to
make it clear whether they want "(a or b) and c" or "a or (b and c)".

>> or in a few cases it's
>> intuitive (a<b+c, a<b and c), but that does not establish a transitive
>> relation (don't accept a+b and c).
>
>Conflating of numeric anc logical types is a misfeature rather specific
>to C and its decendants.

I have made productive use of treating the results of comparisons as
numbers or masks, so I think it's a feature. The misfeature in C is a
syntax that accepts "a+b&c".

>Introduce a distinct logical type and most
>problems of that kind go away.

They don't, because the parser does not perform type checking. In
particular, Modula-2 has a separate type BOOLEAN, and its parser
accepts "a+b AND c"; yes, it does report a type error for it, but it
also reports a type error for "a<b and c" if a, b are INTEGER, and c
is BOOLEAN. Of course, the latter misfeature would be much worse if
BOOLEAN was compatible with INTEGER.

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

aph@littlepinkcloud.invalid writes:
>I also believe that if an instruction set is nice to program in
>assembly, it's also nice to write a code generator for. Tweako
>special-case instructions are a pain to remember, but they're also a
>pain to generate code for automatically.

I think it depends on what concept of niceness the programmer has in
mind. If a programmer finds a use for such an instruction, they may
pride themselves in their knowledge. You see a similar phenomenon in
the "undefined behaviour" debate (comp.arch law satisfied), where some
pride themselves in knowing (or believing they know) the undefined
behaviour and how to avoid it, and claim that it is very important for
performance in order to make this knowledge seem relevant.

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

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?

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

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.
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.

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. You ever used
Iverson's APL?

On Wednesday, March 2, 2022 at 12:00:41 PM UTC-6, Anton Ertl wrote:
> Thomas Koenig <tko...@netcologne.de> writes:
> >Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> >> Ivan Godard <iv...@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.
<
Consider::
# define a (aproxy
# define b bproxy)
Now what does the above give you ?
<
(aproxy+bproxy)*c
<
Unlikely to be what you meant.
Whereas if you use parenthesis more or less as required in the face of
c-#defines, you at least get a compile time warning.
<
> >> but not "a or b and c"),
> >
> >and is multiplication, or is (saturating) addition, so the precedence
> >is intuitive (at least if the relationship above is intuitive).
> It's not at all intuitive, and I expect that
>
> * newbies relatively frequently make mistakes when they rely on precedence.
<
If C has taught me anything; it is that you have to parenthesize everything.
<
>
> * experienced programmers and more cautious newbies use parentheses to
> make it clear whether they want "(a or b) and c" or "a or (b and c)".
> >> or in a few cases it's
> >> intuitive (a<b+c, a<b and c), but that does not establish a transitive
> >> relation (don't accept a+b and c).
> >
> >Conflating of numeric anc logical types is a misfeature rather specific
> >to C and its decendants.
> I have made productive use of treating the results of comparisons as
> numbers or masks, so I think it's a feature. The misfeature in C is a
> syntax that accepts "a+b&c".
<
Reliably programming requires parens.
<
> >Introduce a distinct logical type and most
> >problems of that kind go away.
> They don't, because the parser does not perform type checking. In
> particular, Modula-2 has a separate type BOOLEAN, and its parser
> accepts "a+b AND c"; yes, it does report a type error for it, but it
> also reports a type error for "a<b and c" if a, b are INTEGER, and c
> is BOOLEAN. Of course, the latter misfeature would be much worse if
> BOOLEAN was compatible with INTEGER.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On 2022-03-02 19:40, 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.
>
>>> but not "a or b and c"),
>>
>> and is multiplication, or is (saturating) addition, so the precedence
>> is intuitive (at least if the relationship above is intuitive).
>
> It's not at all intuitive, and I expect that
>
> * newbies relatively frequently make mistakes when they rely on precedence.
>
> * experienced programmers and more cautious newbies use parentheses to
> make it clear whether they want "(a or b) and c" or "a or (b and c)".

FWIW, Ada makes "a or b and c" illegal and requires parentheses. But Ada
allows "not a and b", with "not" having higher precedence than "and". I
would recommend parentheses there, or writing it as "b and not a".

>>> or in a few cases it's
>>> intuitive (a<b+c, a<b and c), but that does not establish a transitive
>>> relation (don't accept a+b and c).
>>
>> Conflating of numeric anc logical types is a misfeature rather specific
>> to C and its decendants.

When Ada gained true unsigned integers as "modular integer types", the
logical operators (and, or, xor, not) were extended to apply bit-wise to
such operands. For variables a, b, c of a modular type, this means that
"a + b and c" is legal Ada, with "and" having higher precedence than
"+". While that is not a conflation of numeric and logical types, it
does mix arithmetic and logical operators.

On Wednesday, March 2, 2022 at 12:42:43 PM UTC-6, Stephen Fuld 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?
<
We started this thread with::
<----------------------------------------------------------------------------------------
> > Then you would be eating up a lot of namespace in the programmers head::
> ><
> > ADD R7,R4,R19
> > ADD R7,R4,-R19
> > ADD R7,-R4,-R19
> > ADD R7,R4,#256
> > ADD R7,R4,#-256
> > ADD R7,#256,R19
> > ADD R7,#-256,R19
> > ADD R7,R4,#0x12345678
> > ADD R7,R4,#0x1234567890123456
> > ADD R7,#0x12345678,R19
> > ADD R7,#0x1234567890123456,R19
<
> I agree that it would make less sense for your ISA than
> for a more conventional RISC.
<----------------------------------------------------------------------------------------
<
In practice, good name-space in ASM is more for reading
and figuring out what the compiler is doing right (and wrong)
than for writing asm yourself.
>
>
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

Anton Ertl wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
>> It turns out that *any* formal specification of language semantics is
>> beyond usual mortal ken; try reading Denotational Semantics someday :-)
>
> I have. Did not find it inspiring.
>
> I think that formal stuff can be ok for certain aspects; (E)BNF is the
> poster child for that, although the informal specification of the
> resolution of the dangling else problem by Wirth demonstrates that
> even EBNF is occasionally too complicated.
>
> 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.

For many (most?) of these SIMD operations I find the pseudo-code
implementation the only one I'm sure I understand.

Terje

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

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.
>
>>> but not "a or b and c"),
>>
>> and is multiplication, or is (saturating) addition, so the precedence
>> is intuitive (at least if the relationship above is intuitive).
>
> It's not at all intuitive, and I expect that
>
> * newbies relatively frequently make mistakes when they rely on precedence.
>
> * experienced programmers and more cautious newbies use parentheses to
> make it clear whether they want "(a or b) and c" or "a or (b and c)".
>
>>> or in a few cases it's
>>> intuitive (a<b+c, a<b and c), but that does not establish a transitive
>>> relation (don't accept a+b and c).
>>
>> Conflating of numeric anc logical types is a misfeature rather specific
>> to C and its decendants.
>
> I have made productive use of treating the results of comparisons as
> numbers or masks, so I think it's a feature. 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.

Terje

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