🚀 go-pugleaf

Quadibloc <jsa...@ecn.ab.ca> writes:
> I remember it being said that IBM didn't write that compiler itself, but instead 
> they hired a firm that wrote compilers for computer manufacturers to do that; it 
> was a firm whose ads I remember seeing in Computerworld, they mentioned that they 
> used a stack-based technology for their compilers.
>
> But I can't seem to find or remember the name...
>
> John Savard

I remember Univ. of Chicago had some amount of the contract for Fort G
... but don't remember whether it was everything ... or just runtime
libraries. 

much later STL started subcontracting lots of compiler stuff out ...
there was some uproar over lots of internal compiler optimization
technology being given to some company.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

Quadibloc <jsa...@ecn.ab.ca> Wrote in message:
> I remember it being said that IBM didn't write that compiler itself, but instead 
> they hired a firm that wrote compilers for computer manufacturers to do that; it 
> was a firm whose ads I remember seeing in Computerworld, they mentioned that they 
> used a stack-based technology for their compilers.
> 
> But I can't seem to find or remember the name...
> 
> John Savard
> 

Digitek. They actually had a compiler written for a stack oriented
pseudo machine that they then wrote interpreters for to fit on small
machines. I believe the first was the SDS 910 but many small
hardware builders were customers. F4/40 for the PDP 6/10, for example.

They then tried to take on PL/1 and put themselves out of
 business. IIRC the survivers started Ryan McFarland.

IBM had more space on G sized machines, so they expanded the
 pseudo instructions as macros to speed it up.

sarr
-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

Sarr Blumson <sarr.blumson@alum.dartmouth.orgq> wrote:
> Quadibloc <jsa...@ecn.ab.ca> Wrote in message:
>> I remember it being said that IBM didn't write that compiler itself, but instead 
>> they hired a firm that wrote compilers for computer manufacturers to do that; it 
>> was a firm whose ads I remember seeing in Computerworld, they mentioned that they 
>> used a stack-based technology for their compilers.
>> 
>> But I can't seem to find or remember the name...
>> 
>> John Savard
>> 
> 
> Digitek. They actually had a compiler written for a stack oriented
> pseudo machine that they then wrote interpreters for to fit on small
> machines. I believe the first was the SDS 910 but many small
> hardware builders were customers. F4/40 for the PDP 6/10, for example.
> 
> They then tried to take on PL/1 and put themselves out of
>  business. IIRC the survivers started Ryan McFarland.
> 
> IBM had more space on G sized machines, so they expanded the
>  pseudo instructions as macros to speed it up.
> 

Thanks. I believe Digitek was hired to develop PL/I for Multics, but they
failed so spectacularly that the Multics people developed their own
compiler from scratch. It turned out to be one of the best ANSI-standard
PL/I compilers, better than PL/I(F).

-- 
Pete

On Monday, April 9, 2018 at 12:30:17 PM UTC-6, Sarr Blumson wrote:

> Digitek. They actually had a compiler written for a stack oriented
> pseudo machine that they then wrote interpreters for to fit on small
> machines. I believe the first was the SDS 910 but many small
> hardware builders were customers. F4/40 for the PDP 6/10, for example.

Thank you; I couldn't remember the name, but as soon as you said it, it rang a 
bell.

John Savard

In article <pagbfn$t1o$1...@dont-email.me>,
Sarr Blumson  <sarr.blumson@alum.dartmouth.orgq> wrote:
>Digitek. They actually had a compiler written for a stack oriented
>pseudo machine that they then wrote interpreters for to fit on small
>machines. I believe the first was the SDS 910 but many small
>hardware builders were customers. F4/40 for the PDP 6/10, for example.

Sounds right.  F4/40 generated machine code but it was pretty poor, and
I could easily believe it was macro expanded from a stack pseudomachine.

The code from Fortran G was also pretty poor, largely because it
didn't know anything about the 360's addressing so it was constantly
loading pointers from a literal pool to reference local scalars rather
than keeping a pointer to the base of the scalars in a register and
using the usual base+displacement.

I saw the note about Fortran G generating better code than Fortran H,
and find it hard to believe unless it was for some rather peculiar
code.

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

John Levine <jo...@taugh.com> wrote:
> In article <pagbfn$t1o$1...@dont-email.me>,
> Sarr Blumson  <sarr.blumson@alum.dartmouth.orgq> wrote:
>> Digitek. They actually had a compiler written for a stack oriented
>> pseudo machine that they then wrote interpreters for to fit on small
>> machines. I believe the first was the SDS 910 but many small
>> hardware builders were customers. F4/40 for the PDP 6/10, for example.
> 
> Sounds right.  F4/40 generated machine code but it was pretty poor, and
> I could easily believe it was macro expanded from a stack pseudomachine.
> 
> The code from Fortran G was also pretty poor, largely because it
> didn't know anything about the 360's addressing so it was constantly
> loading pointers from a literal pool to reference local scalars rather
> than keeping a pointer to the base of the scalars in a register and
> using the usual base+displacement.
> 
> I saw the note about Fortran G generating better code than Fortran H,
> and find it hard to believe unless it was for some rather peculiar
> code.
> 

ISTR that H had problems initially ('67 or so).  I recall being warned not
to use it. I would hope that the problems got fixed.

-- 
Pete

In article <1613292015.545100577.072...@news.eternal-september.org> you write:
>John Levine <jo...@taugh.com> wrote:
>> I saw the note about Fortran G generating better code than Fortran H,
>> and find it hard to believe unless it was for some rather peculiar
>> code.
>
>ISTR that H had problems initially ('67 or so).  I recall being warned not
>to use it. I would hope that the problems got fixed.

I was using Fortran H on production code in about 1973 on Princeton's
360/91 and it worked fine.  It was a large (for the time) numerical
economic simulation that took forever to run.  Recompiling with H
rather than G and rewriting a couple of subroutines so they didn't
open and close a file every time they read a record from the disk made
a huge difference.



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

On 11/04/2018 05:30, John Levine wrote:
> In article <1613292015.545100577.072...@news.eternal-september.org> you write:
>> John Levine <jo...@taugh.com> wrote:
>>> I saw the note about Fortran G generating better code than Fortran H,
>>> and find it hard to believe unless it was for some rather peculiar
>>> code.
>>
>> ISTR that H had problems initially ('67 or so).  I recall being warned not
>> to use it. I would hope that the problems got fixed.
> 
> I was using Fortran H on production code in about 1973 on Princeton's
> 360/91 and it worked fine.  It was a large (for the time) numerical
> economic simulation that took forever to run.  Recompiling with H
> rather than G and rewriting a couple of subroutines so they didn't
> open and close a file every time they read a record from the disk made
> a huge difference.
> 
> 
> 
 From what I know the preserved versions of Fortran H that are around 
still contain bugs. There is some reference here:-

https://books.google.co.uk/books?id=aBxVAAAAMAAJ&lpg=PA5&ots=cpnQJFjS0k&dq=ibm%20%22fortran%20h%22%20bugs&pg=PA5

(sorry for the long url)

perhaps they were not fixed until IBM made the compiler a program product.

Dave

On 4/10/2018 4:37 PM, John Levine wrote:
> In article <pagbfn$t1o$1...@dont-email.me>,
> Sarr Blumson  <sarr.blumson@alum.dartmouth.orgq> wrote:
>> Digitek. They actually had a compiler written for a stack oriented
>> pseudo machine that they then wrote interpreters for to fit on small
>> machines. I believe the first was the SDS 910 but many small
>> hardware builders were customers. F4/40 for the PDP 6/10, for example.
> 
> Sounds right.  F4/40 generated machine code but it was pretty poor, and
> I could easily believe it was macro expanded from a stack pseudomachine.
> 

Thyere is a comment in Don Woods' original Adventure code...  that 
references a bug in the F40 compiler code generation.  Look at he middle 
line in the following...

1004    READ(1,1005)LOC,(LINES(J),J=LINUSE+1,LINUSE+14),KK
1005    FORMAT(1G,15A5)
         IF(KK.NE.' ')CALL BUG(0)
         IF(LOC.EQ.-1)GOTO 1002
         DO 1006 K=1,14
         KK=LINUSE+15-K
         IF(LINES(KK).NE.' ')GOTO 1007
1006    CONTINUE
         IF(LOC.EQ.0)GOTO 1004
C  ABOVE KLUGE IS TO AVOID F40 BUG IF CRLF BROKEN ACROSS RECORD BOUNDARY
         CALL BUG(1)
1007    LINES(LINUSE)=KK+1
         IF(LOC.EQ.OLDLOC)GOTO 1020
         LINES(LINUSE)=-LINES(LINUSE)
         IF(SECT.EQ.12)GOTO 1013
         IF(SECT.EQ.10)GOTO 1012
         IF(SECT.EQ.6)GOTO 1011
         IF(SECT.EQ.5)GOTO 1010
         IF(SECT.EQ.1)GOTO 1008


-- 
numerist at aquaporin4 dot com

In article <palhs0$pfb$1...@dont-email.me>,
Charles Richmond  <nume...@aquaporin4.com> wrote:
>Thyere is a comment in Don Woods' original Adventure code...  that 
>references a bug in the F40 compiler code generation.  Look at he middle 
>line in the following...

That's not a code bug.  It's a library bug.  For some reason lost in the mists
of time F4/F40 called a lot of its runtime library via user UUOs, which is
so PDP-6/10 specific that I would assume a lot of the library was written at DEC.

R's,
John

>1004    READ(1,1005)LOC,(LINES(J),J=LINUSE+1,LINUSE+14),KK
>1005    FORMAT(1G,15A5)
>         IF(KK.NE.' ')CALL BUG(0)
>         IF(LOC.EQ.-1)GOTO 1002
>         DO 1006 K=1,14
>         KK=LINUSE+15-K
>         IF(LINES(KK).NE.' ')GOTO 1007
>1006    CONTINUE
>         IF(LOC.EQ.0)GOTO 1004
>C  ABOVE KLUGE IS TO AVOID F40 BUG IF CRLF BROKEN ACROSS RECORD BOUNDARY
>         CALL BUG(1)
>1007    LINES(LINUSE)=KK+1
>         IF(LOC.EQ.OLDLOC)GOTO 1020
>         LINES(LINUSE)=-LINES(LINUSE)
>         IF(SECT.EQ.12)GOTO 1013
>         IF(SECT.EQ.10)GOTO 1012
>         IF(SECT.EQ.6)GOTO 1011
>         IF(SECT.EQ.5)GOTO 1010
>         IF(SECT.EQ.1)GOTO 1008
>
>
>-- 
>numerist at aquaporin4 dot com


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

John Levine <jo...@taugh.com> Wrote in message:
> 
> Sounds right.  F4/40 generated machine code but it was pretty poor, and
> I could easily believe it was macro expanded from a stack pseudomachine.

People told me writing was too concise even before tablets. :)

The _compiler_ was written in pseudo code by humans. It generated
 real code for the target machine so some serious porting was
 required for a new architecture.

F40 was amazingly aggressive, actually. It used all 16 registers
 before resorting to temp variables and did common subexpression
 reduction within individual statements. Not always correctly,
 unfortunately.

Sarr


-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/