Quadibloc <jsavard@ecn.ab.ca> schrieb:

> So my memory reference instructions aren't
>
> opcode 6
> Rd 5
> Rs 5
> displacement 16
>
> they're
>
> opcode 5
> Rd 5
> Rx 3
> Rb 3
> displacement 16
>
> and so I have to make the 32 integer registers
> non-uniform; 1-7 are index registers, and 25-31
> are base registers.
>
> I'm fitting in index-base addressing into a single
> 32-bit word because the IBM 360 could do it, and
> I want to be almost as good!

You may not be aware of this, but one of the main insights that led
to the design of the 801 was that compilers for the /360 hardly ever
used the complex instructions, especially complex addressing modes.

I understand that you don't want to write, or port, your own
compiler. But do try to get some experience reading assembler
for other architectures, and see where yours could do better.

I would suggest configuring clang or gcc (clang by default, gcc with
a configure option) for a simple-minded RISC architecture. RISC-V
might be a good choice it does many operations as instructions,
which make it easier to follow.

For example, the RISC-V code for

void foo(int *p, unsigned long a, unsigned long b)
{ p[a+b+200]=1;
}

is

add a1, a1, a2
slli a1, a1, 2
add a0, a0, a1
li a1, 1
sw a1, 800(a0)
ret

which is a pattern you can surely recognize.

(Before Mitch chimes in: My 66000 could do this as

add r2,r2,r3
stw #1,[r1,r2<<2,800]
ret

although the compiler is not quite there yet).

If you're feeling very adventurous, you can write a little assembler
(using Perl, Python or another script language of your choice)
and do some dataflow analysis for basic blocks, which value ends up
where.

You could do so by having an associative array; at the start of a
basic block, you initialize the values to those of the register,
so (Perl syntax) $reg{'a1'} = 'a1';

On encountering each instruction, you do something like (if you
prefer a LISP-like syntax)

$value = "($instr $op2 $op3)";
$reg{$op1} = $value

so $reg{'a1'} is "(add a1 a2)" after the first instruction,
"(slli (add a1 a2) 2)" after the seconde, and so on.

You can then search for the combination of adds you want to replace
with a single instruction.

> This takes up 3/4 of the opcode space.

Isn't that rather a lot?

On Tuesday, May 16, 2023 at 3:14:28 AM UTC-6, Thomas Koenig wrote:

> You may not be aware of this, but one of the main insights that led
> to the design of the 801 was that compilers for the /360 hardly ever
> used the complex instructions, especially complex addressing modes.

It's hard for me to believe that base-index addressing is all that "complex",
and, indeed, it would seem to me to be the obvious and natural way to
access register elements. If the compiler doesn't use it, the problem is
with the compiler.

That the string instructions, for example, were hardly used by compilers
is obvious enough - some of the string and packed decimal instructions,
though, would earn their keep if they were used in the assembly-coded
system subroutines to convert numbers to character form or the reverse
for printing and input. And I'd expect a COBOL compiler to have some
use for them, even if a FORTRAN compiler wouldn't.

John Savard

On Tuesday, May 16, 2023 at 3:14:28 AM UTC-6, Thomas Koenig wrote:

> > This takes up 3/4 of the opcode space.

> Isn't that rather a lot?

I end up cutting it down to 3/8 of the opcode space, so that I have
1/2 of the opcode space available for 16 bit instructions, by using only
three base registers, instead of seven, for 16-bit displacements.

This seemed to be a compromise that would cause the least damage to
the instruction set.

However, in Concertina II as it is, with the block structure, the 16-bit
instructions only use 1/4 of the opcode space, thanks to only occuring
in pairs. The 1/8 of the opcode space gained is used for operate
instructions.

I think I can manage the conversion to a variable length encoding.

That's because the opcode space allocated to operate instructions is
rather generous - unlike that used for memory-reference instructions,
which is tightly squeezed.

John Savard

On Tuesday, May 16, 2023 at 5:19:52 PM UTC-6, Quadibloc wrote:

> and, indeed, it would seem to me to be the obvious and natural way to
> access register elements.

Oops, array elements.

John Savard

On Tuesday, May 16, 2023 at 6:19:52 PM UTC-5, Quadibloc wrote:
> On Tuesday, May 16, 2023 at 3:14:28 AM UTC-6, Thomas Koenig wrote:
>
> > You may not be aware of this, but one of the main insights that led
> > to the design of the 801 was that compilers for the /360 hardly ever
> > used the complex instructions, especially complex addressing modes.
<
> It's hard for me to believe that base-index addressing is all that "complex",
> and, indeed, it would seem to me to be the obvious and natural way to
> access register elements. If the compiler doesn't use it, the problem is
> with the compiler.
<
There is a useful difference between base+index and base+scaled index.
The former requires linear induction, the later requires less.
<
But similar stories abound in that VAX doing indirect memory accesses
(and other exotic uses of the address modes) was almost always SLOWER
than simply using registers as a programmable cache. Then again, not
using the CALL and RET instruction (use JSR and JMP instead) provided
for very significant performance gains.
<
On the other hand, this was one of the things Brian's compiler had little
trouble utilizing.
>
> That the string instructions, for example, were hardly used by compilers
> is obvious enough - some of the string and packed decimal instructions,
> though, would earn their keep if they were used in the assembly-coded
> system subroutines to convert numbers to character form or the reverse
> for printing and input. And I'd expect a COBOL compiler to have some
> use for them, even if a FORTRAN compiler wouldn't.
<
In 1974, I figured out how to CON the PL/1 compiler to use the string
instructions to move checker boards (push and pop) so as to evaluate
multiple move sequences. The checker boards were a 4×8 matrix of
bytes {0 = unoccupied, 1 = pawn, 2 = queen}. The stack represented
the sequence the game took (backup), .....
>
> John Savard

On Tuesday, May 16, 2023 at 5:35:01 PM UTC-6, MitchAlsup wrote:

> In 1974, I figured out how to CON the PL/1 compiler to use the string
> instructions to move checker boards (push and pop) so as to evaluate
> multiple move sequences. The checker boards were a 4×8 matrix of
> bytes {0 = unoccupied, 1 = pawn, 2 = queen}. The stack represented
> the sequence the game took (backup), .....

I'm supposing you equivalenced the byte arrays to character strings
to manage that.

If you are only using 32 squares, indeed you are playing checkers.
But then that should be 1=man, 2=king. One only finds queens in
Chess, and for that matter, the same is true of pawns.

John Savard

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Tuesday, May 16, 2023 at 3:14:28 AM UTC-6, Thomas Koenig wrote:
>
>> You may not be aware of this, but one of the main insights that led
>> to the design of the 801 was that compilers for the /360 hardly ever
>> used the complex instructions, especially complex addressing modes.
>
> It's hard for me to believe that base-index addressing is all that "complex",
> and, indeed, it would seem to me to be the obvious and natural way to
> access register elements.

We were talking about

# opcode 5
# Rd 5
# Rx 3
# Rb 3
# displacement 16

You typically have a pointer to the first element of the array.
You run through it in a loop, using indexed load/stores.

Where does the displacement come in, and why 16 bits?

> If the compiler doesn't use it, the problem is
> with the compiler.

You cannot look at an architecture independent of the compiler.

This is likely a non-problem, because it occurs so infrequently
that it does not matter.

Do you actually look at assembler output for real programs to see
how often this is needed?

And did you consider my suggestion upthread about how to gather
actual data?

Quadibloc wrote:
> On Tuesday, May 16, 2023 at 3:14:28 AM UTC-6, Thomas Koenig wrote:
>
>> You may not be aware of this, but one of the main insights that led
>> to the design of the 801 was that compilers for the /360 hardly ever
>> used the complex instructions, especially complex addressing modes.
>
> It's hard for me to believe that base-index addressing is all that "complex",
> and, indeed, it would seem to me to be the obvious and natural way to
> access register elements. If the compiler doesn't use it, the problem is
> with the compiler.
>
> That the string instructions, for example, were hardly used by compilers
> is obvious enough - some of the string and packed decimal instructions,
> though, would earn their keep if they were used in the assembly-coded
> system subroutines to convert numbers to character form or the reverse
> for printing and input. And I'd expect a COBOL compiler to have some
> use for them, even if a FORTRAN compiler wouldn't.
>
> John Savard

The Vax Fortran 77 compiler used the string instructions -
arrays are first class types in F77 and mapped well to
those high level instructions. Also for record/struct moves.

The MOVC5 instruction takes 5 operands:
src len, src addr, dst len, dst addr, pad char,
and appears designed for F77 string edits.
(F77 string moves were defined as truncating if the
dst was shorter than source, pad with blanks if dst longer.)

Note though that F77 was an important compiler for DEC's business
as much of their customer base was scientists and engineers.
So they put a lot of development into that compiler.

The scuttlebutt I heard at that time was IBM had multiple Fortran
compilers and while at one time one of them was supposedly considered
state-of-the-art, it had not been actively developed for a while.
We ported a lot of F77 from VAX to VM/CMS and the IBM compiler
was extremely simplistic.

MitchAlsup wrote:
> On Tuesday, May 16, 2023 at 6:19:52 PM UTC-5, Quadibloc wrote:
>> On Tuesday, May 16, 2023 at 3:14:28 AM UTC-6, Thomas Koenig wrote:
>>
>>> You may not be aware of this, but one of the main insights that led
>>> to the design of the 801 was that compilers for the /360 hardly ever
>>> used the complex instructions, especially complex addressing modes.
> <
>> It's hard for me to believe that base-index addressing is all that "complex",
>> and, indeed, it would seem to me to be the obvious and natural way to
>> access register elements. If the compiler doesn't use it, the problem is
>> with the compiler.
> <
> There is a useful difference between base+index and base+scaled index.
> The former requires linear induction, the later requires less.
> <
> But similar stories abound in that VAX doing indirect memory accesses
> (and other exotic uses of the address modes) was almost always SLOWER
> than simply using registers as a programmable cache. Then again, not
> using the CALL and RET instruction (use JSR and JMP instead) provided
> for very significant performance gains.

There is the extra clocks VAX 780 took to decode the index operand
specifiers. Also the ALU was 74181's which have only 2 source operands
so a scaled index took an extra trip through the ALU.
And some VAX models didn't do back-to-back fordwarding between uOps
which scaled index addressing requires.

In the VAX Fortran 77 compiler, strength reduction of loop induction
variables and replacing indexed array accesses with autoincrement
memory accesses was an important optimization.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Quadibloc wrote:
>> On Tuesday, May 16, 2023 at 3:14:28 AM UTC-6, Thomas Koenig wrote:
>>
>>> You may not be aware of this, but one of the main insights that led
>>> to the design of the 801 was that compilers for the /360 hardly ever
>>> used the complex instructions, especially complex addressing modes.
>>
>> It's hard for me to believe that base-index addressing is all that "complex",
>> and, indeed, it would seem to me to be the obvious and natural way to
>> access register elements. If the compiler doesn't use it, the problem is
>> with the compiler.
>>
>> That the string instructions, for example, were hardly used by compilers
>> is obvious enough - some of the string and packed decimal instructions,
>> though, would earn their keep if they were used in the assembly-coded
>> system subroutines to convert numbers to character form or the reverse
>> for printing and input. And I'd expect a COBOL compiler to have some
>> use for them, even if a FORTRAN compiler wouldn't.
>>
>> John Savard
>
>The Vax Fortran 77 compiler used the string instructions -

As did the Pascal compiler. A lot of VAX software was
written in Macro32 and the string instructions were commonly
used there as well.

In the Burroughs (medium systems - BCD machines), string
instructions were deriguour, as they were the only data
movement instructions (like MOVC5, they had the ability
to pad (leading with zeros or trailing with blanks as
required by the data type). Very heavily used by the
COBOL (68, 74) compilers.

There were also instructions to scan strings for a
set of delimiters (Scan Delimiter Equal (SDE) and Scan
Delimiter Unequal); useful for parsing etc.

Then there were the search instructions (two flavors of
search table instructions, and two flavors of search
linked list instructions).

And of course, there was the EDT (Edit) instruction to
support COBOL PIC clauses.

* 00772000
* Handle the case where the information is extracted 00773000
* from a LANGUAGE_TABLE entry 00774000
* 00775000
..Mls BOT (/FF) -Flag /Set request? 00776000
EQL +SetM /Yep, set it 00777000
* 00778000
LIX TBL-OF:+X4,IX1,DEFLAN /Fetch ptr to ptr 00779000
LNGH IX1 00780000
LIX BASE:+X1(SN),IX1 /Load real pointer 00781000
ADD LT-NAM(LL),IX1+RL,STRSBA:+X6 /String start 00782000
ADD LT-NAM(SZ),STRSBA:+X6,STRSEA:+X6 /String end 00783000
MVN IX1+DO,STRMA:+X6 /Set source M.A. 00784000
MVN IR-MGR:(EN),STRENV:+X6 /Set an env 00785000
MVS STRDSC:+X6,STRDSC:+X7(UA) /Move data, pad blanks 00786000
BUN +NEXT /Do next item 00787000
00788000
..SetM BRT (/FF) STRDSC:+X6 /Clear descriptor 00789000
ADD -LTnam(LL),IX3+RL,STRSBA:+X6 /String start 00790000
MVR (/03) STRSBA:+X6,STRSEA:+X6 /Set string & cont addr 00791000
INC -LTnam(SZ),STRCEA:+X6 /Set container end 00792000
MVS (/50) STRDSC:+X7,STRDSC:+X6(UA) /Move data, pad blanks 00793000
MVN =1,-CFlg /Change task attr 00794000
ADD -ErKey(LL),IX3,-Rptr /Return ptr 00795000
SIX -SavM,MOBILE /Save mobiles 00796000
MVW IX1/X2,-SavI /Save IX1/2 00797000
VEN -ChgP,MLSCHG /Change language 00798000
LIX -SavM,MOBILE /Restore mobiles 00799000
MVW -SavI,IX1/X2 /Restore IX1/X2 00800000
BUN +NEXT /Do next item 00801000
* 00802000
..JUST SUB RQ-BEG:+X2,RQ-END:+X2,-DELTA /Size of recieving fld 00803000
DEC -SSIZE,-DELTA /Find the bigger one 00804000
EQL +MOVE /Nobody, all ok. 00805000
GTR +DEST /Dest is bigger 0080600

StarTrek game in COBOL:

3000-COM-FUN. 605 CARD 1 67592
DISPLAY " ". 606 CARD 1 67592
01 067592 MVW 120003 204048 200336 CODE
01 067610 BCT 300254 CODE
01 067616 BUN 27 0C067636 CODE
^LCOBOL MARK 3.33 (DC 10/09/98) COMPILATION OF STREK 2022 JULY 25 07:01 PAGE 38

01 067626 ACON 000336 CODE
01 067632 CNST 1060 CODE
IF ENTRY1 NOT NUMERIC OR ENTRY1 < 1 OR ENTRY1 > 6 607 CARD 1 67636
01 067636 SDU 171001 004062 217014 CODE
01 067654 LEQ 23 0C067720 CODE
01 067664 CPN 46A101 100000 217014 CODE
01 067682 GTR 24 0C067720 CODE
01 067692 CPN 46A101 600000 217014 CODE
01 067710 GEQ 26 0C067800 CODE
DISPLAY "*COMPUTER ACTIVE AND AWAITING COMMAND* " 608 CARD 1 67720
01 067720 MVA 103939 204072 200336 CODE
01 067738 BCT 300254 CODE
01 067744 BUN 27 0C067764 CODE
01 067754 ACON 000336 CODE
01 067760 CNST 1390 CODE
ACCEPT COMP-COM 609 CARD 1 67764
01 067764 BCT 300254 CODE
01 067770 BUN 27 0C067790 CODE
01 067780 ACON 017536 CODE
01 067786 CNST 0010 CODE
01 067790 BUN 27 0C067818 CODE
ELSE 610 CARD
MOVE ENTRY1 TO COMP-COM. 611 CARD 1 67800
01 067800 MVN 110101 217014 217536 CODE
IF COMP-COM NOT NUMERIC OR COMP-COM < 1 OR COMP-COM > 6 612 CARD 1 67818
01 067818 SDU 171001 004062 217536 CODE
01 067836 LEQ 23 0C067902 CODE
01 067846 CPN 46A101 100000 217536 CODE
01 067864 GTR 24 0C067902 CODE
01 067874 CPN 46A101 600000 217536 CODE
01 067892 GEQ 26 0C068546 CODE
DISPLAY "INVALID COMPUTER COMMAND " 613 CARD 1 67902
01 067902 MVA 102525 204150 200336 CODE
01 067920 BCT 300254 CODE
01 067926 BUN 27 0C067946 CODE
01 067936 ACON 000336 CODE
01 067942 CNST 1250 CODE
DISPLAY "DO YOU WANT A LIST OF COMPUTER COMMANDS? " 614 CARD 1 67946
01 067946 MVW 120021 204200 200336 CODE
01 067964 BCT 300254 CODE
01 067970 BUN 27 0C067990 CODE
01 067980 ACON 000336 CODE
01 067986 CNST 1420

Scott Lurndal wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> Quadibloc wrote:
>>> On Tuesday, May 16, 2023 at 3:14:28 AM UTC-6, Thomas Koenig wrote:
>>>
>>>> You may not be aware of this, but one of the main insights that led
>>>> to the design of the 801 was that compilers for the /360 hardly ever
>>>> used the complex instructions, especially complex addressing modes.
>>> It's hard for me to believe that base-index addressing is all that "complex",
>>> and, indeed, it would seem to me to be the obvious and natural way to
>>> access register elements. If the compiler doesn't use it, the problem is
>>> with the compiler.
>>>
>>> That the string instructions, for example, were hardly used by compilers
>>> is obvious enough - some of the string and packed decimal instructions,
>>> though, would earn their keep if they were used in the assembly-coded
>>> system subroutines to convert numbers to character form or the reverse
>>> for printing and input. And I'd expect a COBOL compiler to have some
>>> use for them, even if a FORTRAN compiler wouldn't.
>>>
>>> John Savard
>> The Vax Fortran 77 compiler used the string instructions -
>
> As did the Pascal compiler. A lot of VAX software was
> written in Macro32 and the string instructions were commonly
> used there as well.
>
> In the Burroughs (medium systems - BCD machines), string
> instructions were deriguour, as they were the only data
> movement instructions (like MOVC5, they had the ability
> to pad (leading with zeros or trailing with blanks as
> required by the data type). Very heavily used by the
> COBOL (68, 74) compilers.
>
> There were also instructions to scan strings for a
> set of delimiters (Scan Delimiter Equal (SDE) and Scan
> Delimiter Unequal); useful for parsing etc.
>
> Then there were the search instructions (two flavors of
> search table instructions, and two flavors of search
> linked list instructions).
>
> And of course, there was the EDT (Edit) instruction to
> support COBOL PIC clauses.

VAX Ada used the CASE instruction for case statements.
Ada has packed arrays of bit-wise variables and IIRC compiler
used the bit field EXTV extract bit vector and INSV insert bit
vector instructions for accessing memory bit field vector arrays.

I never used COBOL but I'm pretty sure VAX compiler used the
decimal string instructions. Later PDP-11 models also had
decimal string instructions so likely the compilers used them too.

That's not to say these instructions weren't slow as molasses,
just that the compilers could spit them out.

On 5/16/2023 4:19 PM, Quadibloc wrote:
> On Tuesday, May 16, 2023 at 3:14:28 AM UTC-6, Thomas Koenig wrote:
>
>> You may not be aware of this, but one of the main insights that led
>> to the design of the 801 was that compilers for the /360 hardly ever
>> used the complex instructions, especially complex addressing modes.
>
> It's hard for me to believe that base-index addressing is all that "complex",
> and, indeed, it would seem to me to be the obvious and natural way to
> access register elements. If the compiler doesn't use it, the problem is
> with the compiler.
>
> That the string instructions, for example, were hardly used by compilers
> is obvious enough - some of the string and packed decimal instructions,
> though, would earn their keep if they were used in the assembly-coded
> system subroutines to convert numbers to character form or the reverse
> for printing and input. And I'd expect a COBOL compiler to have some
> use for them, even if a FORTRAN compiler wouldn't.

IBM's S/360 COBOL compiler used this type of instruction extensively.
Of course, if you defined a data item as COMP-3, all arithmetic was done
using using the decimal instructions. If you defined a data item as
display, arithmetic was done by generating a Pack instruction to convert
to packed decimal then doing the arithmetic, then unpacking the result.
Also, since the edit instruction took a packed decimal format, any COBOL
move to a display field that required editing generated a pack if
necessary, followed by the edit. In addition, most COBOL moves that
didn't require any modification were done by generating a move character
instruction (MVC). There were other "stringy" instructions that
implemented various COBOL verbs.

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

EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> Quadibloc wrote:
>> On Tuesday, May 16, 2023 at 3:14:28 AM UTC-6, Thomas Koenig wrote:
>>
>>> You may not be aware of this, but one of the main insights that led
>>> to the design of the 801 was that compilers for the /360 hardly ever
>>> used the complex instructions, especially complex addressing modes.
>>
>> It's hard for me to believe that base-index addressing is all that "complex",
>> and, indeed, it would seem to me to be the obvious and natural way to
>> access register elements. If the compiler doesn't use it, the problem is
>> with the compiler.
>>
>> That the string instructions, for example, were hardly used by compilers
>> is obvious enough - some of the string and packed decimal instructions,
>> though, would earn their keep if they were used in the assembly-coded
>> system subroutines to convert numbers to character form or the reverse
>> for printing and input. And I'd expect a COBOL compiler to have some
>> use for them, even if a FORTRAN compiler wouldn't.
>>
>> John Savard
>
> The Vax Fortran 77 compiler used the string instructions -
> arrays are first class types in F77 and mapped well to
> those high level instructions. Also for record/struct moves.

If you have a complex construct in a high-level language, you
can emit a library call, or you can emit a CISCy instruction
if it does the job.

That is not the problem.

It is much more problematic reconstructing such a use case from
a language which does not have that particular construct, like C.

> The MOVC5 instruction takes 5 operands:
> src len, src addr, dst len, dst addr, pad char,
> and appears designed for F77 string edits.
> (F77 string moves were defined as truncating if the
> dst was shorter than source, pad with blanks if dst longer.)

Sounds like Fortran character assignment, yes.

> Note though that F77 was an important compiler for DEC's business
> as much of their customer base was scientists and engineers.
> So they put a lot of development into that compiler.

The lineage of that compiler still exists, in Intel Fortran. Intel
took over DEC's compiler group before DEC was bought by Compaq.

> The scuttlebutt I heard at that time was IBM had multiple Fortran
> compilers and while at one time one of them was supposedly considered
> state-of-the-art, it had not been actively developed for a while.

VS Fortran wasn't bad, at the time. There is no IBM-developed
post-Fortran 77 compiler for zOS, but gfortran is available for
Linux on zSystem.

> We ported a lot of F77 from VAX to VM/CMS and the IBM compiler
> was extremely simplistic.

DEC's Fortran had a _lot_ of extensions, many of which plague
Fortran compiler writers to this day. If IBM's Fortran compilers
didn't support them, I can imagine that you had problems porting.

On Wednesday, May 17, 2023 at 11:58:30 AM UTC-5, Thomas Koenig wrote:
> EricP <ThatWould...@thevillage.com> schrieb:
> > Quadibloc wrote:
> >> On Tuesday, May 16, 2023 at 3:14:28 AM UTC-6, Thomas Koenig wrote:
> >>
> >>> You may not be aware of this, but one of the main insights that led
> >>> to the design of the 801 was that compilers for the /360 hardly ever
> >>> used the complex instructions, especially complex addressing modes.
> >>
> >> It's hard for me to believe that base-index addressing is all that "complex",
> >> and, indeed, it would seem to me to be the obvious and natural way to
> >> access register elements. If the compiler doesn't use it, the problem is
> >> with the compiler.
> >>
> >> That the string instructions, for example, were hardly used by compilers
> >> is obvious enough - some of the string and packed decimal instructions,
> >> though, would earn their keep if they were used in the assembly-coded
> >> system subroutines to convert numbers to character form or the reverse
> >> for printing and input. And I'd expect a COBOL compiler to have some
> >> use for them, even if a FORTRAN compiler wouldn't.
> >>
> >> John Savard
> >
> > The Vax Fortran 77 compiler used the string instructions -
> > arrays are first class types in F77 and mapped well to
> > those high level instructions. Also for record/struct moves.
<
> If you have a complex construct in a high-level language, you
> can emit a library call, or you can emit a CISCy instruction
> if it does the job.
>
> That is not the problem.
>
> It is much more problematic reconstructing such a use case from
> a language which does not have that particular construct, like C.
<
struct2 = struct1;
<
memmove( to, from, length );
<
> > The MOVC5 instruction takes 5 operands:
> > src len, src addr, dst len, dst addr, pad char,
> > and appears designed for F77 string edits.
> > (F77 string moves were defined as truncating if the
> > dst was shorter than source, pad with blanks if dst longer.)
> Sounds like Fortran character assignment, yes.
> > Note though that F77 was an important compiler for DEC's business
> > as much of their customer base was scientists and engineers.
> > So they put a lot of development into that compiler.
> The lineage of that compiler still exists, in Intel Fortran. Intel
> took over DEC's compiler group before DEC was bought by Compaq.
> > The scuttlebutt I heard at that time was IBM had multiple Fortran
> > compilers and while at one time one of them was supposedly considered
> > state-of-the-art, it had not been actively developed for a while.
<
After CRAY 1, IBM was not really in the FORTRAN game..........
Keeping the then current compiler provides support, but little
incentive to advance.
<
> VS Fortran wasn't bad, at the time. There is no IBM-developed
> post-Fortran 77 compiler for zOS, but gfortran is available for
> Linux on zSystem.
> > We ported a lot of F77 from VAX to VM/CMS and the IBM compiler
> > was extremely simplistic.
> DEC's Fortran had a _lot_ of extensions, many of which plague
> Fortran compiler writers to this day. If IBM's Fortran compilers
> didn't support them, I can imagine that you had problems porting.

MitchAlsup wrote:
> On Wednesday, May 17, 2023 at 11:58:30 AM UTC-5, Thomas Koenig wrote:
>> EricP <ThatWould...@thevillage.com> schrieb:
>>> Quadibloc wrote:
>>>> On Tuesday, May 16, 2023 at 3:14:28 AM UTC-6, Thomas Koenig wrote:
>>>>
>>>>> You may not be aware of this, but one of the main insights that led
>>>>> to the design of the 801 was that compilers for the /360 hardly ever
>>>>> used the complex instructions, especially complex addressing modes.
>>>> It's hard for me to believe that base-index addressing is all that "complex",
>>>> and, indeed, it would seem to me to be the obvious and natural way to
>>>> access register elements. If the compiler doesn't use it, the problem is
>>>> with the compiler.
>>>>
>>>> That the string instructions, for example, were hardly used by compilers
>>>> is obvious enough - some of the string and packed decimal instructions,
>>>> though, would earn their keep if they were used in the assembly-coded
>>>> system subroutines to convert numbers to character form or the reverse
>>>> for printing and input. And I'd expect a COBOL compiler to have some
>>>> use for them, even if a FORTRAN compiler wouldn't.
>>>>
>>>> John Savard
>>> The Vax Fortran 77 compiler used the string instructions -
>>> arrays are first class types in F77 and mapped well to
>>> those high level instructions. Also for record/struct moves.
> <
>> If you have a complex construct in a high-level language, you
>> can emit a library call, or you can emit a CISCy instruction
>> if it does the job.
>>
>> That is not the problem.
>>
>> It is much more problematic reconstructing such a use case from
>> a language which does not have that particular construct, like C.
>>
>>> The scuttlebutt I heard at that time was IBM had multiple Fortran
>>> compilers and while at one time one of them was supposedly considered
>>> state-of-the-art, it had not been actively developed for a while.
> <
> After CRAY 1, IBM was not really in the FORTRAN game..........
> Keeping the then current compiler provides support, but little
> incentive to advance.

All of which is why John probably should not use an IBM F77 compiler,
apparently in maintenance mode for a while,
as the basis for deciding what compilers can or cannot do.

Thomas Koenig <tkoenig@netcologne.de> schrieb:

> For example, the RISC-V code for
>
> void foo(int *p, unsigned long a, unsigned long b)
> {
> p[a+b+200]=1;
> }
>
> is
>
> add a1, a1, a2
> slli a1, a1, 2
> add a0, a0, a1
> li a1, 1
> sw a1, 800(a0)
> ret
>
> which is a pattern you can surely recognize.
>
> (Before Mitch chimes in: My 66000 could do this as
>
> add r2,r2,r3
> stw #1,[r1,r2<<2,800]
> ret
>
> although the compiler is not quite there yet).
>
> If you're feeling very adventurous, you can write a little assembler
> (using Perl, Python or another script language of your choice)
> and do some dataflow analysis for basic blocks, which value ends up
> where.

I felt adventurous, and implemented something like that - this
writes out expanded load and store addresses for RISC-V. Script is
attached below, it is probably somewhat buggy and may eat your cat,
so beware :-) The script tracks assignments to registers and writes
out load and store addresses. Every time a label or a branch is
encountered, it resets the registers to default because it cannot
make assumptions then.

It does not use a robust parser, it uses the convention on tabs
in assembly used by both gcc and clang to parse the input.

Foe example, for the input

add a1, a1, a2
lui a2, 5
addiw a2, a2, -480
addw a1, a1, a2
slli a1, a1, 2
add a0, a0, a1
lw a0, 0(a0)
ret

it produces the output

(add a0 (slli (addw (add a1 a2) 20000)) 2))

So, here are some results. I used the concatenated assembly for
Perl because it is typical of one important class of applications,
interpreters, and because I had the source lying around in
a directory.

So:

$ perl parse.pl perl_all.s > perl.lst
$ wc -l perl.lst
230051 perl.lst

Around 230000 loads and stores... Perl is rather big.

$ grep sp perl.lst | wc -l
78885

Around 1/3 of them saving and restoring from the stack.

$ grep "add.*add" perl.lst | wc -l
5095

2.2% invoving more than one addition for address calculation.

$ grep 'addi' perl.lst | wc -l
161725

70% involve adding a constant to something, presumably a register.

$ grep 'add' perl.lst | grep sll | wc -l
6976

3% involve shifted values in addressing.

And so on... quite interesting what can be done with this.

@John S: If you play around with your own ISA, you could use this
kind of script to see how much of your proposed addressing modes
could actually be used.

And here is the script, free for anybody's use. But remember I warned
about this eating cats, so no guarantees of any kind :-)

#! /usr/bin/perl -w

@regname = qw(zero ra sp gp tp t0 t1 t2 s0 s1 a0 a1 a2 a3 a4 a5 a6 a7
s2 s3 s4 s5 s6 s7 s8 s9 s10 s11 t3 t4 t5 t6);

@unsaved = qw (a0 a1 a2 a3 a4 a5 a6 a7 t0 t1 t2 t3 t4 t5 t6);

@arith = qw (addw addi add addiw slli srli sub or ori and andi mul);
@load = qw (lw lwu lh lhu lbu ld);
@store = qw(sh sw sd sb);
@mv = qw(mv lui li);

for $i (@arith) { $arith{$i} ++; }

for $i(@load) { $load{$i} ++; }

for $i(@store) { $store{$i} ++; }

for $i(@mv) { $mv{$i} ++; }

$printit = 0;

&reset_reg;

@addr = ();

$line = 0;
while (<>)
{ $line ++;
&reset_reg if (/:/);
chomp;
$i = undef;
(undef,$i,$arglist) = split("\t");
&reset_call if (defined($i) and $i eq "call");
if (defined($i) && substr($i,0,1) ne "." ) {
if ($i =~ /^b/ || $i eq 'j') {
&reset_reg;
}
if (defined($arglist)) {
@args = split(/,\s*/,$arglist);
}
else {
@args = ();
}
print $_ if ($printit) ;
if ($#args >= 0) {
print "\t;\t",$i,"\t" if ($printit);
$is_store = exists($store{$i});
$is_load = exists($load{$i});
$is_mv = exists($mv{$i});
if ($is_load || $is_store) {
$args[1] =~ /([+-]?[0-9]+|%..\([^)]+\))\(([^(]+)\)/;
$offset = $1;
$reg = $2;
$addr = "";
print $args[0],", " if ($printit) ;
if ($offset =~ /^0/ ) {
$addr = $reg{$reg};
print "(", $addr, ")" if ($printit);
}
else {
$addr = "(addi $reg{$reg} $offset)";
}
$addr = &simplify($addr);

if ($printit)
{
push (@addr,$addr);
}
else {
print $addr,"\n";
}
$reg{$args[0]} = $args[0] if $is_load;

} elsif ($is_mv) {
if ($i eq "lui") {
if ($args[1] =~ /^[+-]?[0-9]+$/) {
$reg{$args[0]} = $args[1]*4096;
}
else {
$reg{$args[0]} = "(slli $args[1] 12)";
}
}
else {
$reg{$args[0]} = $args[1];
}
print $args[0], ", ", $args[1], "\n" if ($printit); }
else {
print $args[0] if ($printit);
for $n (1..$#args) {
if (exists($reg{$args[$n]})) {
print ", $reg{$args[$n]}" if ($printit);
} else {
print ", $args[$n]" if ($printit);
}
}
if (exists($arith{$i}) && $args[0] ne "sp" ) {
if ($i =~ /addi?/ && $args[1] eq "zero") {
$reg{$args[0]} = $args[2];
}
else {
my $new = "($i " . &is_reg($args[1]) . " "
. &is_reg($args[2]) . ")";

$new = &simplify($new);
if (length($new) < 500) {
$reg{$args[0]} = $new;
}
else
{
# Reset if too long, exponential explosion for long sequences otherwise.
$reg{$args[0]} = $args[0];
}
# print $new,"\n";
}
}
print "\n" if ($printit);
}
}
}
else {
print $_, "\n" if ($printit);
}
}

print join("\n",@addr),"\n" unless $printit;

sub is_reg
{ my($name) = shift;
return exists($reg{$name}) ? $reg{$name} : $name;
} sub reset_reg
{ my $r;
# print "reset_reg\n";
# for $r (@regname) {
# print "reset $r\n" if (defined($reg{$r}) && $reg{$r} ne $r);
# };

for $r(@regname) {
$reg{$r} = $r;
}
$reg{"zero"} = '0';
}

sub reset_call
{ my $r;
for $r(@unsaved) {
$reg{$r} = $r;
}
}

sub simplify
{ my $x = shift;
$x =~ s/\(addi?\s+\(slli?\s+%hi\(([^)]+)\)\s+12\)\s+%lo\(\g1\)\)/$1/;
while ($x =~ /\(addi?w?\s+([+-]?[0-9]+)\s+([+-][0-9]+)/)
{
if (defined($1) && defined($2)) {
my $sum = $1 + $2;
$x =~ s/\(addi?w?\s+[+-]?[0-9]+\s+[+-][0-9]+/$sum/;
}
}
$x;
}

MitchAlsup <MitchAlsup@aol.com> schrieb:

> After CRAY 1, IBM was not really in the FORTRAN game..........
> Keeping the then current compiler provides support, but little
> incentive to advance.

They tried to compete with the vector facility for their 3090,
but that flopped. The 3090 that was installed at the computer
center at Karlsruhe had 150 MFlops, compared to the a few tens
of Megaflops for each workstation - and they had whole clusters
of them. No contest regarding price/performance.

IBM still has a Fortran compiler (xlf), but for POWER.

On Friday, May 19, 2023 at 5:34:27 AM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > After CRAY 1, IBM was not really in the FORTRAN game..........
> > Keeping the then current compiler provides support, but little
> > incentive to advance.
<
> They tried to compete with the vector facility for their 3090,
> but that flopped. The 3090 that was installed at the computer
> center at Karlsruhe had 150 MFlops, compared to the a few tens
> of Megaflops for each workstation - and they had whole clusters
> of them. No contest regarding price/performance.
>
> IBM still has a Fortran compiler (xlf), but for POWER.
<
Yes, I was referring only to the 360-line of computers wrt Fortran