Related articles |
---|
[2 earlier articles] |
Re: XPL Language pld@fc.hp.com (2000-07-27) |
Re: XPL Language andyj@mc.com (Andy Johnson) (2000-08-04) |
Re: XPL Language ab528@freenet.carleton.ca (2000-08-04) |
Re: XPL Language sjmeyer@www.tdl.com (2000-08-10) |
Re: XPL Language duane.sand@compaq.com (Duane Sand) (2000-08-13) |
Re: XPL Language sjmeyer@www.tdl.com (2000-08-27) |
Re: roots (was: XPL Language) duane.sand@mindspring.com (Duane Sand) (2000-09-08) |
From: | "Duane Sand" <duane.sand@mindspring.com> |
Newsgroups: | comp.compilers |
Date: | 8 Sep 2000 02:01:39 -0400 |
Organization: | MindSpring Enterprises |
References: | 00-06-118 00-07-016 00-07-075 00-08-018 00-08-028 00-08-055 00-08-083 00-08-127 |
Keywords: | history |
Steve Meyer wrote:
>I am not sure it makes sense to continue this historial discussion,
>but I think there is a lot more to story. The roots of modern
>computing lie in this story. For example, although both PL360 and XPL
>were available why did Professor Knuth use assembler in his Art of
>Programming books?
See page xi of preface to Volume I for why.
Kunth began writing this work in 1962.
The category of low-level yet widely portable languages
(eg BCPL, C, BLISS, Mary, ...) did not yet exist or the examples
were not widely known or widely implemented. The existing widely
implemented high-level languages were unsuited for Knuth's book
in being too far removed from actual machine ops (so those actions
couldn't be counted up by desk analysis) and in not having needed
primitives like addresses and pointers and arbitrary jumps.
When Aho, Hopcroft, and Ullman wrote a similar book in 1974,
it was by then obviously the right thing to present methods in a
higher notation, in this case "pidgin Algol".
> ...
>Parsing may have gotten tenure for lots of professors but the most
>advanced programming language areas such as HDLs (hardware
>descriptions languages) now use the "predated" operator precedence
>methods.
"most advanced"? hmmph.
I think the vast majority of boutique single-use languages are now
based on yacc parsers, with the runner up being recursive descent.
For most languages and compilers, the parsing method used is mostly
determined by accident -- by the background of the compiler writer and
the tools available. But it's always nice to use a tool you can
readily fully understand and take anywhere, which is trivial with
recursive descent, easy for precedence, and involves bookwork and
opaque tools for LR.
> ...
>I think PL360 was very popular within IBM and among the back then
>"modernist" movement away from assembly language. I know it was
>very popular at SLAC.
Wirth was working at SLAC when he developed PL/360. It's possible it
was little-used elsewhere. Can anyone confirm that it saw any use
within IBM? Perhaps you are thinking of IBM's PL.8 and PL/S, low
level system languages derived from PL/I; both were used extensively
for coding major products within IBM.
>I think it was hard back then to differentiate XPL from Mckeeman's
>advocacy of Burroughs B5500 style stack machine research program.
?? I don't recall there being any discussion of stack machines in
the XPL book. And the register-machine ports of XPL were much
more known and used than the B5500 port.
>Duane Sand wrote:
>>PL/M's level was limited by the 8008's near inability to support proc
>>calls. The first micro language to see significant use was Basic,
>>implemented by assembler-coded interpreters. Implementing real
>>applications in real compiled languages required later chips with
>>nicer instruction sets, eg 8088 (gag) and M6800.
>
>As the Z80 showed, 8088 was only one index register away from
>being real computer.
You meant 8080; the Z80 was an extension of 8080. The 8086/8088
family has lots more regs than either 8080 or Z80.
I take back what I wrote earlier about "real applications in real
compiled languages required later chips". I've since learned that
Digital Research and Intel both wrote nearly all their software products
in PL/M for many years, including DRI's operating systems, Intel's ISIS
operating system, Intel's Pascal compiler, and DRI's PL/I compiler.
(One component of one version of CP/M was rewritten in assembly
to conserve space.) And PL/M was used in an uncountable number
of embedded controller applications. The combination of PL/M and
8080 clearly worked good enough. There was enough demand
for PL/M to support four different compiler vendors; just as much
activity as with early C compilers for 8086.
>Historical question I think is why there was so little communciation
>between the current most popular BCPL, B, C, C++ research program and
>the Stanford/Silicon Valley research program.
Because it was a few individuals doing their own thing, not research
programs. Also no Internet, and no quick cheap easy way to share
major chunks of sofware even by mag tape, no portable (already
implemented) language except Fortran and Cobol, no shared single
character set, more variety in institutions' machine types than now,
more variety in incompatible operating systems before Unix, and
computers were owned and selected by institutions, not
individuals. And (before Unix itself) there was no sizeable body of
available software that motivated conformance to another's language
design. Would you spend 3-6 months porting another guy's little
compiler (for not-my language, for the wrong OS and wrong machine), or
just start over on your own language? Wirth's answer and Ritchie's
answer was always to do their own.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.