29 Jan
2022
29 Jan
'22
12:07 a.m.
I'm reading in, Kernighan & Plauger's 1981 edition of Software Tools in
Pascal and in the book, the author's mention Bill Joy's Pascal and Andy
Tanenbaum's as being rock solid. So, a few related questions:
1. What edition of UNIX were they likely to be using?
2. What versions of "Standard Pascal" were in vogue on UNIX at the time
(1981)?
3. What combinations of UNIX/Pascal were popular?
Thanks,
Will
29 Jan
29 Jan
12:18 a.m.
On Fri, Jan 28, 2022 at 6:09 PM Will Senn <will.senn(a)gmail.com> wrote:
I'm reading in, Kernighan & Plauger's
1981 edition of Software Tools in
Pascal and in the book, the author's mention Bill Joy's Pascal and Andy
Tanenbaum's as being rock solid. So, a few related questions:
1. What edition of UNIX were they likely to be using?
I'm afraid I can't speak to your 2nd and 3rd questions, but I can offer
what I think is a reasonable guess about the first.
One of the neat things about Unix and Unix-adjacent books of that era is
that very often the copyright page held some information about the
production of the book itself. I just so happened to have a copy of,
"Software Tools in Pascal" sitting on my desk, and it says, "This books as
set in Times Roman and Courier by the authors, using a Mergenthaler
Linotron 202 phototypesetter driven by a PDP-11/70 running the Unix
operating system."
Given the PDP-11 and the date (1981) one may reasonably conclude that it
was running 7th Edition. I imagine the pascal was Joy's, from Berkeley.
- Dan C.
12:31 a.m.
On 1/28/22 5:18 PM, Dan Cross wrote:
On Fri, Jan 28, 2022 at 6:09 PM Will Senn
<will.senn(a)gmail.com> wrote:
I'm reading in, Kernighan & Plauger's 1981 edition of Software
Tools in Pascal and in the book, the author's mention Bill Joy's
Pascal and Andy Tanenbaum's as being rock solid. So, a few related
questions:
1. What edition of UNIX were they likely to be using?
I'm afraid I can't speak to your 2nd and 3rd questions, but I can
offer what I think is a reasonable guess about the first.
One of the neat things about Unix and Unix-adjacent books of that era
is that very often the copyright page held some information about the
production of the book itself. I just so happened to have a copy of,
"Software Tools in Pascal" sitting on my desk, and it says, "This
books as set in Times Roman and Courier by the authors, using a
Mergenthaler Linotron 202 phototypesetter driven by a PDP-11/70
running the Unix operating system."
Given the PDP-11 and the date (1981) one may reasonably conclude that
it was running 7th Edition. I imagine the pascal was Joy's, from Berkeley.
- Dan C.
Great hint. 20 seconds after I hit send on the original email, I came
across this:
http://www.lysator.liu.se/c/bwk-on-pascal.html
Where Brian Kernighan talks about the challenges they faced porting the
ratfor examples into pascal. He explains that:
The programs were first written in that dialect of Pascal supported
by the Pascal interpreter pi provided by the University of
California at Berkeley. The language is close to the nominal
standard of Jensen and Wirth,(6
<http://www.lysator.liu.se/c/bwk-on-pascal.html#lit-6>) with good
diagnostics and careful run-time checking. Since then, the programs
have also been run, unchanged except for new libraries of
primitives, on four other systems: an interpreter from the Free
University of Amsterdam (hereinafter referred to as VU, for Vrije
Universiteit), a VAX version of the Berkeley system (a true
compiler), a compiler purveyed by Whitesmiths, Ltd., and UCSD Pascal
on a Z80. All but the last of these Pascal systems are written in C.
So, you were right about it being Joy's pi.
Thanks,
Will
1:03 a.m.
Not really on topic for Unix, but historical and relevant to this
conversation and I think not well known.
In 1978 I was an exchange student working at EIR (now the Paul Scherrer
Institute), using the CDC 7600 (I think that was the model) at ETH, where
Wirth was a professor. EIR is about 30km from Zürich, and EIR had a remote
job entry system.
The computing environment was very odd, and I asked about it. Two things I
learned:
1) The University had bought a CDC machine instead of an IBM one, somewhat
against advice, because CDC, being a smaller company, did not have the
wherewithal to translate their manuals. IBM's manuals came in German and
were all but incomprehensible as they avoided the accepted terms of art
known and used even by a German-speaking programmer. The CDC manuals, being
in English, were easier to understand, especially when considering the
nuance and precision necessary to learn the correct interpretation of the
description of a computer's execution. The Swiss, being polyglots, handled
English manuals just fine.
2) The operating system's I/O model was bizarre, but it was also unique. It
was a version of NOS locally modified, partly (if I remember right) in
support of the remote execution setup. The peculiar sequence of cards
necessary to terminate the input was due to the local changes to NOS made
at ETH. This was the system Pascal was created for, and a consequence of
the design is the idiosyncratic way input worked in early Pascal, which
made little sense to almost anyone, was seriously hard to recreate on Unix,
but worked naturally if using punch cards on, and only on, the ETH 7600.
-rob
On Sat, Jan 29, 2022 at 10:32 AM Will Senn <will.senn(a)gmail.com> wrote:
On 1/28/22 5:18 PM, Dan Cross wrote:
On Fri, Jan 28, 2022 at 6:09 PM Will Senn <will.senn(a)gmail.com> wrote:
I'm reading in, Kernighan &
Plauger's 1981 edition of Software Tools in
Pascal and in the book, the author's mention Bill Joy's Pascal and Andy
Tanenbaum's as being rock solid. So, a few related questions:
1. What edition of UNIX were they likely to be using?
I'm afraid I can't speak to your 2nd and 3rd questions, but I can offer
what I think is a reasonable guess about the first.
One of the neat things about Unix and Unix-adjacent books of that era is
that very often the copyright page held some information about the
production of the book itself. I just so happened to have a copy of,
"Software Tools in Pascal" sitting on my desk, and it says, "This books
as
set in Times Roman and Courier by the authors, using a Mergenthaler
Linotron 202 phototypesetter driven by a PDP-11/70 running the Unix
operating system."
Given the PDP-11 and the date (1981) one may reasonably conclude that it
was running 7th Edition. I imagine the pascal was Joy's, from Berkeley.
- Dan C.
Great hint. 20 seconds after I hit send on the original email, I came
across this:
http://www.lysator.liu.se/c/bwk-on-pascal.html
Where Brian Kernighan talks about the challenges they faced porting the
ratfor examples into pascal. He explains that:
The programs were first written in that dialect of Pascal supported by the
Pascal interpreter pi provided by the University of California at Berkeley. The
language is close to the nominal standard of Jensen and Wirth,(6
<http://www.lysator.liu.se/c/bwk-on-pascal.html#lit-6>) with good
diagnostics and careful run-time checking. Since then, the programs have
also been run, unchanged except for new libraries of primitives, on four
other systems: an interpreter from the Free University of Amsterdam
(hereinafter referred to as VU, for Vrije Universiteit), a VAX version of
the Berkeley system (a true compiler), a compiler purveyed by Whitesmiths,
Ltd., and UCSD Pascal on a Z80. All but the last of these Pascal systems
are written in C.
So, you were right about it being Joy's pi.
Thanks,
Will
1:40 a.m.
On 1/28/22 5:31 PM, Will Senn wrote:
On 1/28/22 5:18 PM, Dan Cross wrote:
On the good news front, I was able to find a working pi/px environment -
4.2bsd built from tape on simulated vax780 works great (thank god vi
works there, too) and will run the programs in the book without mods,
out of the box. 4.3 would probably work similarly (I put it on the
list). I tried compiling the pascal distributed via 2bsd on v7, but
wasn't able to get it built (story of my life). This is prolly expected
because the notes in the distro say "This is still set up for version
6", so I'll stick with 4.2 for the time being. Just glad to have a
working environment to supplement the reading.
Will
On Fri, Jan 28, 2022 at 6:09 PM Will Senn
<will.senn(a)gmail.com> wrote:
I'm reading in, Kernighan & Plauger's 1981 edition of Software
Tools in Pascal and in the book, the author's mention Bill Joy's
Pascal and Andy Tanenbaum's as being rock solid. So, a few
related questions:
1. What edition of UNIX were they likely to be using?
I'm afraid I can't speak to your 2nd and 3rd questions, but I can
offer what I think is a reasonable guess about the first.
One of the neat things about Unix and Unix-adjacent books of that era
is that very often the copyright page held some information about the
production of the book itself. I just so happened to have a copy of,
"Software Tools in Pascal" sitting on my desk, and it says, "This
books as set in Times Roman and Courier by the authors, using a
Mergenthaler Linotron 202 phototypesetter driven by a PDP-11/70
running the Unix operating system."
Given the PDP-11 and the date (1981) one may reasonably conclude that
it was running 7th Edition. I imagine the pascal was Joy's, from
Berkeley.
- Dan C.
Great hint. 20 seconds after I hit send on the original email, I came
across this:
http://www.lysator.liu.se/c/bwk-on-pascal.html
Where Brian Kernighan talks about the challenges they faced porting
the ratfor examples into pascal. He explains that:
The programs were first written in that dialect of Pascal
supported by the Pascal interpreter pi provided by the University
of California at Berkeley. The language is close to the nominal
standard of Jensen and Wirth,(6
<http://www.lysator.liu.se/c/bwk-on-pascal.html#lit-6>) with good
diagnostics and careful run-time checking. Since then, the
programs have also been run, unchanged except for new libraries of
primitives, on four other systems: an interpreter from the Free
University of Amsterdam (hereinafter referred to as VU, for Vrije
Universiteit), a VAX version of the Berkeley system (a true
compiler), a compiler purveyed by Whitesmiths, Ltd., and UCSD
Pascal on a Z80. All but the last of these Pascal systems are
written in C.
So, you were right about it being Joy's pi.
Thanks,
Will 
8:05 p.m.
It would be interesting to know if the S.T. in P. programs will run on
{GNU,Free} Pascal.
On Fri, Jan 28, 2022 at 7:41 PM Will Senn <will.senn(a)gmail.com> wrote:
On 1/28/22 5:31 PM, Will Senn wrote:
On 1/28/22 5:18 PM, Dan Cross wrote:
On Fri, Jan 28, 2022 at 6:09 PM Will Senn <will.senn(a)gmail.com> wrote:
I'm reading in, Kernighan &
Plauger's 1981 edition of Software Tools in
Pascal and in the book, the author's mention Bill Joy's Pascal and Andy
Tanenbaum's as being rock solid. So, a few related questions:
1. What edition of UNIX were they likely to be using?
I'm afraid I can't speak to your 2nd and 3rd questions, but I can offer
what I think is a reasonable guess about the first.
One of the neat things about Unix and Unix-adjacent books of that era is
that very often the copyright page held some information about the
production of the book itself. I just so happened to have a copy of,
"Software Tools in Pascal" sitting on my desk, and it says, "This books
as
set in Times Roman and Courier by the authors, using a Mergenthaler
Linotron 202 phototypesetter driven by a PDP-11/70 running the Unix
operating system."
Given the PDP-11 and the date (1981) one may reasonably conclude that it
was running 7th Edition. I imagine the pascal was Joy's, from Berkeley.
- Dan C.
Great hint. 20 seconds after I hit send on the original email, I came
across this:
http://www.lysator.liu.se/c/bwk-on-pascal.html
Where Brian Kernighan talks about the challenges they faced porting the
ratfor examples into pascal. He explains that:
The programs were first written in that dialect of Pascal supported by the
Pascal interpreter pi provided by the University of California at Berkeley. The
language is close to the nominal standard of Jensen and Wirth,(6
<http://www.lysator.liu.se/c/bwk-on-pascal.html#lit-6>) with good
diagnostics and careful run-time checking. Since then, the programs have
also been run, unchanged except for new libraries of primitives, on four
other systems: an interpreter from the Free University of Amsterdam
(hereinafter referred to as VU, for Vrije Universiteit), a VAX version of
the Berkeley system (a true compiler), a compiler purveyed by Whitesmiths,
Ltd., and UCSD Pascal on a Z80. All but the last of these Pascal systems
are written in C.
So, you were right about it being Joy's pi.
Thanks,
Will
On the good news front, I was able to find a working pi/px environment -
4.2bsd built from tape on simulated vax780 works great (thank god vi works
there, too) and will run the programs in the book without mods, out of the
box. 4.3 would probably work similarly (I put it on the list). I tried
compiling the pascal distributed via 2bsd on v7, but wasn't able to get it
built (story of my life). This is prolly expected because the notes in the
distro say "This is still set up for version 6", so I'll stick with 4.2
for
the time being. Just glad to have a working environment to supplement the
reading.
Will
8:36 p.m.
The code from Software Tools in Pascal is in the TUHS archives
(courtesy of yours truly, quite some time ago).
See Applications/Software_Tools/swt/Pascal/*
So give them a go. :-)
Arnold
John Cowan <cowan(a)ccil.org> wrote:
It would be interesting to know if the S.T. in P.
programs will run on
{GNU,Free} Pascal.
On Fri, Jan 28, 2022 at 7:41 PM Will Senn <will.senn(a)gmail.com> wrote:
> On 1/28/22 5:31 PM, Will Senn wrote:
>
> On 1/28/22 5:18 PM, Dan Cross wrote:
>
> On Fri, Jan 28, 2022 at 6:09 PM Will Senn <will.senn(a)gmail.com> wrote:
>
>> I'm reading in, Kernighan & Plauger's 1981 edition of Software
Tools in
>> Pascal and in the book, the author's mention Bill Joy's Pascal and
Andy
>> Tanenbaum's as being rock solid. So, a few related questions:
>>
>> 1. What edition of UNIX were they likely to be using?
>>
>
> I'm afraid I can't speak to your 2nd and 3rd questions, but I can offer
> what I think is a reasonable guess about the first.
>
> One of the neat things about Unix and Unix-adjacent books of that era is
> that very often the copyright page held some information about the
> production of the book itself. I just so happened to have a copy of,
> "Software Tools in Pascal" sitting on my desk, and it says, "This
books as
> set in Times Roman and Courier by the authors, using a Mergenthaler
> Linotron 202 phototypesetter driven by a PDP-11/70 running the Unix
> operating system."
>
> Given the PDP-11 and the date (1981) one may reasonably conclude that it
> was running 7th Edition. I imagine the pascal was Joy's, from Berkeley.
>
> - Dan C.
>
> Great hint. 20 seconds after I hit send on the original email, I came
> across this:
> http://www.lysator.liu.se/c/bwk-on-pascal.html
>
> Where Brian Kernighan talks about the challenges they faced porting the
> ratfor examples into pascal. He explains that:
>
> The programs were first written in that dialect of Pascal supported by the
> Pascal interpreter pi provided by the University of California at Berkeley. The
> language is close to the nominal standard of Jensen and Wirth,(6
> <http://www.lysator.liu.se/c/bwk-on-pascal.html#lit-6>) with good
> diagnostics and careful run-time checking. Since then, the programs have
> also been run, unchanged except for new libraries of primitives, on four
> other systems: an interpreter from the Free University of Amsterdam
> (hereinafter referred to as VU, for Vrije Universiteit), a VAX version of
> the Berkeley system (a true compiler), a compiler purveyed by Whitesmiths,
> Ltd., and UCSD Pascal on a Z80. All but the last of these Pascal systems
> are written in C.
>
> So, you were right about it being Joy's pi.
>
> Thanks,
>
> Will
>
>
> On the good news front, I was able to find a working pi/px environment -
> 4.2bsd built from tape on simulated vax780 works great (thank god vi works
> there, too) and will run the programs in the book without mods, out of the
> box. 4.3 would probably work similarly (I put it on the list). I tried
> compiling the pascal distributed via 2bsd on v7, but wasn't able to get it
> built (story of my life). This is prolly expected because the notes in the
> distro say "This is still set up for version 6", so I'll stick with
4.2 for
> the time being. Just glad to have a working environment to supplement the
> reading.
>
> Will
>
8:59 p.m.
On Fri, Jan 28, 2022 at 6:08 PM Will Senn <will.senn(a)gmail.com> wrote:
1. What edition of UNIX were they likely to be using?
Already answered ...
2. What versions of "Standard Pascal" were
in vogue on UNIX at the time
(1981)?
Remember in 1981, the 'Pascal Standard' was still in flight. ISO 7185
was
1983 and Pascal really does not standardize enough that real
portability was possible until the 1990 version and people actually started
implementing compilers that obeyed it.
3. What combinations of UNIX/Pascal were popular?
Depends the implementation... there were a number of them... there were
the ones I had at that time
- UCB Pascal -- pi being the most popular for the PDP-11, and later pc
for the Vax
- VU Pascal for the 11
- The Zurich P4 compiler was around and of course eventually begat UCSD,
but I don't remember that it was directly made to run on Unix[I did not
have one], although it may/must have been.
- The Similer2 compiler for 68000 [was one of Wirth's -- I think was the
basis for the compiler that they used for Lilith - or maybe it was a fork
that produced the Lilith and the Similer2 compiler -- I don't remember].
That showed up on a couple of the 68K workstations in 1981.
- Andy's Amsterdam Toolkit
- There was a compiler that the RTS folks had at MIT, but I don't know
its origin or how complete it was.
- Purdue had something that had started on the CDCs -- that went to
Tektronix and was the basis for some of the stuff the Logical
Analizer folks were using. It was cross compiler that ran on Unix and
generated 8-bit microprocessor code for embedded systems.
- Per Brinch Hansen had a Pascal that we was pushing, but I don't think
he even moved it to Unix
- Plus, the "Tunis" folks in Toronto had a Concurrent-Pascal and a
UNIX-like system that ran on PDP-11s.
And the problem was 'standard' - lots of people messed with it and every
Pascal was a little different. In 1981 at one of the HP/Tektronix
[Hatfield/McCoy parties - Stienhart probably remembers], Mike Zuhl, TW Cook
and I counted 14 different "Tek Pascal's" and over 25 "HP
Basic's" -- each
was a little different.
UCSD Pascal was its own system, not Unix [sort of like Smalltalk -- a
walled garden within itself]. They started with the P4 compiler but they
made it work on 8-bit systems, so while it was around, it was not a UNIX
Pascal >>and<< it the Standard was still in flight. The OMSI Pascal
compiler was popular for the PDP-11's, but it was RT-11 and RSX [maybe
RSTS, but I'm not sure]. The Zurich PDP-10 Compiler was very popular in
PDP-10 land. DEC released the VAX/pascal for VMS, which they eventually
brought to Ultrix and Tru64. I believe that that was a scratch rewrite
and did not use P4 or anything from the PDP-10s or CDC systems before it.
One of the big issues with P4 based stuff is that the original P2 porting
kit from Wirth assumed a 40 bit integer of the CDC system. Making it work
with a 36 bit world was a tad easier than the 32 or 16 bit world, much less
the 8-bit micros. Folks like DEC, UCB and Amsterdam which started over
with a new front end, tended to have an easier go of it and often had
better compiler tools [which were mostly C based BTW for UNIX and a
combination of Pascal and BLISS at DEC].
Sun later brought the UCB PI and PC to the SunOS, but pls Rob G/Larry
correct me here - I think they later did their own compiler when they did
their new C and Fortran. Masscomp started with the Similer2 compiler, but
eventually did a new front end that matched their C and Fortran like DEC
had.
As for SWTinP running with FreePascal. I looked into it and decided it was
doable, but never went very fair with my investigation since the need for
it, was less. Back in the days of VMS, Pr1meOS and the like, SWT was a
Godsend. But Windows and like have real Unix subsystems, so I never really
was motivated other than pure curiosity.
9:02 p.m.
Clem Cole writes:
And the problem was 'standard' - lots of people messed with it and every
Pascal was a little different. In 1981 at one of the HP/Tektronix
[Hatfield/McCoy parties - Stienhart probably remembers], Mike Zuhl, TW Cook
and I counted 14 different "Tek Pascal's" and over 25 "HP
Basic's" -- each
was a little different.
Oh yeah. Part of this was because Pascal wasn't really up to the job.
So many product groups added their own p-codes for things that they
needed.
9:13 p.m.
On Jan 29, 2022, at 11:59 AM, Clem Cole <clemc(a)ccc.com <mailto:clemc@ccc.com>>
wrote:
Plus, the "Tunis" folks in Toronto had a Concurrent-Pascal and a UNIX-like
system that ran on PDP-11s.
Tunis was implemented in Concurrent Euclid, a descendant of
the Euclid programming language, designed by Ric Hort and
James Cordy. They later designed Turing, which had some
features from Pascal. [I bought their books during the '80s]
Per Brinch Hansen designed Concurrent Pascal and implemented
the Solo operating Solo operating system in it.
9:30 p.m.
Thanks -- sorry, they all blurr together.
On Sat, Jan 29, 2022 at 3:13 PM Bakul Shah <bakul(a)iitbombay.org> wrote:
On Jan 29, 2022, at 11:59 AM, Clem Cole
<clemc(a)ccc.com> wrote:
- Plus, the "Tunis" folks in Toronto had a Concurrent-Pascal and a
UNIX-like system that ran on PDP-11s.
Tunis was implemented in Concurrent Euclid, a descendant of
the Euclid programming language, designed by Ric Hort and
James Cordy. They later designed Turing, which had some
features from Pascal. [I bought their books during the '80s]
Per Brinch Hansen designed Concurrent Pascal and implemented
the Solo operating Solo operating system in it.
9:34 p.m.
On Sat, Jan 29, 2022 at 12:13:06PM -0800, Bakul Shah wrote:
On Jan 29, 2022, at 11:59 AM, Clem Cole
<clemc(a)ccc.com <mailto:clemc@ccc.com>> wrote:
I read the Tunis book, it seemed pretty cool from the book but I've never
played with it. Has anyone?
Plus, the "Tunis" folks in Toronto had a Concurrent-Pascal and a UNIX-like
system that ran on PDP-11s.
Tunis was implemented in Concurrent Euclid, a descendant of
the Euclid programming language, designed by Ric Hort and
James Cordy. 
10:03 p.m.
On 1/29/22 12:34 PM, Larry McVoy wrote:
I read the Tunis book, it seemed pretty cool from the
book but I've never
played with it. Has anyone?
http://bitsavers.org/bits/UniversityOfToronto/
PC version
10:38 p.m.
On Sat, Jan 29, 2022 at 01:03:48PM -0800, Al Kossow wrote:
On 1/29/22 12:34 PM, Larry McVoy wrote:
Is Tunis preserved anywhere and has anyone run it?
I read the Tunis book, it seemed pretty cool from
the book but I've never
played with it. Has anyone?
http://bitsavers.org/bits/UniversityOfToronto/
11:06 p.m.
On Jan 29, 2022, at 12:34 PM, Larry McVoy
<lm(a)mcvoy.com> wrote:
On Sat, Jan 29, 2022 at 12:13:06PM -0800, Bakul Shah wrote:
From Tunis I borrowed signal() & wait() as synchronization
primitives for the simulation library I wrote in 1983 but
that was about it.
On Jan 29, 2022, at 11:59 AM, Clem Cole
<clemc(a)ccc.com <mailto:clemc@ccc.com>> wrote:
I read the Tunis book, it seemed pretty cool from the book but I've never
played with it. Has anyone?
Plus, the "Tunis" folks in Toronto had a Concurrent-Pascal and a UNIX-like
system that ran on PDP-11s.
Tunis was implemented in Concurrent Euclid, a descendant of
the Euclid programming language, designed by Ric Hort and
James Cordy. 
11:48 p.m.
I was one of the TAs for the grad course that produced Tunis. It was heavily influenced by
V6 which we were running at the time. It was designed to run on a stripped down PDP11 so
it could be used in a classroom.
Sent from my iPhone
On Jan 29, 2022, at 5:07 PM, Bakul Shah
<bakul(a)iitbombay.org> wrote:
On Jan 29, 2022, at 12:34 PM, Larry McVoy
<lm(a)mcvoy.com> wrote:
From Tunis I borrowed signal() & wait() as synchronization
primitives for the simulation library I wrote in 1983 but
that was about it. On Sat, Jan 29, 2022 at 12:13:06PM -0800, Bakul
Shah wrote:
On Jan 29, 2022, at 11:59 AM, Clem Cole <clemc(a)ccc.com
<mailto:clemc@ccc.com>> wrote:
I read the Tunis book, it seemed pretty cool from the book but I've never
played with it. Has anyone?
Plus, the "Tunis" folks in Toronto had a Concurrent-Pascal and a UNIX-like
system that ran on PDP-11s.
Tunis was implemented in Concurrent Euclid, a descendant of
the Euclid programming language, designed by Ric Hort and
James Cordy.
30 Jan
30 Jan
4:27 a.m.
So what did you think of Tunis compared to V6?
I really liked the book, I'm hoping it was good but reality is not always that.
On Sat, Jan 29, 2022 at 05:48:39PM -0500, GREEN wrote:
I was one of the TAs for the grad course that produced
Tunis. It was heavily influenced by V6 which we were running at the time. It was designed
to run on a stripped down PDP11 so it could be used in a classroom.
Sent from my iPhone
> On Jan 29, 2022, at 5:07 PM, Bakul Shah <bakul(a)iitbombay.org> wrote:
>
> ???
>
>> On Jan 29, 2022, at 12:34 PM, Larry McVoy <lm(a)mcvoy.com> wrote:
>>
>>> On Sat, Jan 29, 2022 at 12:13:06PM -0800, Bakul Shah wrote:
>>> On Jan 29, 2022, at 11:59 AM, Clem Cole <clemc(a)ccc.com
<mailto:clemc@ccc.com>> wrote:
>>>>
>>>> Plus, the "Tunis" folks in Toronto had a Concurrent-Pascal and
a UNIX-like system that ran on PDP-11s.
>>>
>>> Tunis was implemented in Concurrent Euclid, a descendant of
>>> the Euclid programming language, designed by Ric Hort and
>>> James Cordy.
>>
>> I read the Tunis book, it seemed pretty cool from the book but I've never
>> played with it. Has anyone?
>
> From Tunis I borrowed signal() & wait() as synchronization
> primitives for the simulation library I wrote in 1983 but
> that was about it.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
5:57 p.m.
On Jan 29, 2022, at 11:59 AM, Clem Cole
<clemc(a)ccc.com> wrote:
On Fri, Jan 28, 2022 at 6:08 PM Will Senn <will.senn(a)gmail.com
<mailto:will.senn@gmail.com>> wrote:
3. What combinations of UNIX/Pascal were popular?
Depends the implementation... there were a number of them... there were the ones I had
at that time
The Zurich P4 compiler was around and of course eventually begat UCSD, but I don't
remember that it was directly made to run on Unix[I did not have one], although it
may/must have been.
Yes, the UCSD P-code interpreter was ported to 4.1 BSD on the
VAX and it ran natively there. I used it on sdcsvax in my senior year (1980).
David
7:07 p.m.
New subject: Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?
On Sun, Jan 30, 2022 at 8:58 AM David Barto <david(a)kdbarto.org> wrote:
Yes, the UCSD P-code interpreter was ported to 4.1 BSD
on the VAX and it
ran natively there. I used it on sdcsvax in my senior year (1980).
This reminds me of a question I've had percolating in the back of my mind.
Was USCD Pascal "compiled" or "interpreted" or both?
And is Java? They both have a byte code interpreter. Yes, modern Java is
JIT-compiled, but does that make Java a compiled language in the Oracle
implementation, or is it an interpreter with a pretty good runtime? Wasn't
Java referred to as "compiled" even back before the JIT compiler was
added? Granted, gcj is compiled. But Oracle's implementation of Java is
commonly referred to as a "Compiler". And what about back before Java's
JIT compiler was added - ISTR recall Java was referred to as a compiled
language before the JIT addition.
And then there's the CPython implementation of Python. It too uses a byte
code interpreter, but it's commonly referred to as "interpreted". But is
it really? Granted, it has an implicit, cached compilation step, but is it
less compiled for that?
Is there consistency here?
9:09 p.m.
New subject: Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?
On Jan 30, 2022, at 10:08 AM, Dan Stromberg
<drsalists(a)gmail.com> wrote:
UCSD Pascal was “compiled” into the byte code of the interpreter. I wrote a P-code
assembler in my senior year as part of the compiler class. Java started out doing the same
thing and over time native code generation was added in gcj.
David
On Sun, Jan 30, 2022 at 8:58 AM David Barto
<david(a)kdbarto.org> wrote:
Yes, the UCSD P-code interpreter was ported to 4.1 BSD on the VAX and it ran natively
there. I used it on sdcsvax in my senior year (1980).
This reminds me of a question I've had percolating in the back of my mind.
Was USCD Pascal "compiled" or "interpreted" or both?
And is Java? They both have a byte code interpreter. Yes, modern Java is JIT-compiled,
but does that make Java a compiled language in the Oracle implementation, or is it an
interpreter with a pretty good runtime? Wasn't Java referred to as
"compiled" even back before the JIT compiler was added? Granted, gcj is
compiled. But Oracle's implementation of Java is commonly referred to as a
"Compiler". And what about back before Java's JIT compiler was added -
ISTR recall Java was referred to as a compiled language before the JIT addition.
And then there's the CPython implementation of Python. It too uses a byte code
interpreter, but it's commonly referred to as "interpreted". But is it
really? Granted, it has an implicit, cached compilation step, but is it less compiled for
that?
Is there consistency here?
31 Jan
31 Jan
8:59 a.m.
New subject: Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?
Am 30.01.2022 um 21:09 schrieb David Barto:
> On Jan 30, 2022, at 10:08 AM, Dan Stromberg <drsalists(a)gmail.com> wrote:
> On Sun, Jan 30, 2022 at 8:58 AM David Barto <david(a)kdbarto.org> wrote:
>
> Yes, the UCSD P-code interpreter was ported to 4.1 BSD on the VAX
> and it ran natively there. I used it on sdcsvax in my senior year
> (1980).
>
>
> This reminds me of a question I've had percolating in the back of my
> mind.
>
> Was USCD Pascal "compiled" or "interpreted" or both?
[..]
UCSD Pascal was “compiled” into the byte code of the
interpreter. I
wrote a P-code assembler in my senior year as part of the compiler
class. Java started out doing the same thing and over time native code
generation was added in gcj.
Just for the record: There has been the WD9000 chipset which is actually
an LSI-11 with different Microms which could run the P-code (of UCSD
Pascal III) natively as it was its machine code. So this makes a
distinction of interpreted vs compiled even more fuzzy.
Holger
30 Jan
30 Jan
11:51 p.m.
New subject: Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?
On Sun, Jan 30, 2022 at 1:08 PM Dan Stromberg <drsalists(a)gmail.com> wrote:
Well, gcj (optionally) compiles to native machine code and comes with a
library that implements the functionality usually provided by the JVM; that
is, it can target a platform other than the JVM and give mostly the same
functionality. But javac and gcj are both very much compilers.
But Oracle's implementation of Java is commonly referred to as a
> "Compiler". And what about back before Java's JIT compiler was added
-
> ISTR recall Java was referred to as a compiled language before the JIT
> addition.
This is correct. A compiler simply transforms some representation of data
into a different representation of that same data, possibly with some
semantic loss; the canonical example is textual "source code" for some
programming language translated into object code for some target hardware
architecture, but this need not be the case. We were discussing troff and
TeX the other day; both of these are compilers, in that they take some
high-level source representation of a document and transform it into a
typeset representation. (Note: I mean "semantic loss" in the sense that,
say, we may lose details about types or the organization of data in the
compiled artifact.)
And then there's the CPython implementation of Python. It too uses a byte
> code interpreter, but it's commonly referred to as "interpreted". But
is
> it really? Granted, it has an implicit, cached compilation step, but is it
> less compiled for that?
I think that "interpreted" in this context means the load-and-go nature of
the system and the transience of the bytecode: the text is internally
compiled and then executed, but these steps are often linked and, while one
can coax the Python "interpreter" to emit .pyc and/or .pyo files, usually
one does not: the compiled bytecodes are lost as soon as the program is
done executing.
Is there consistency here?
Not really. As an interesting aside, before Java became widespread I heard
folks mention "P-code" as a generic term for what most folks mean when they
say "bytecode." Now we often just say "bytecode." Similarly with JIT
in
lieu of "load and go", though Java's JIT is a bit different (it's
converting from bytecode to native machine code on the fly; it's even more
elaborate when things like hot-spot are taken into account, where the
runtime has a kind of built-in profiler and will optimize particularly
expensive bits of the code over time).
- Dan C.
On Sun, Jan 30, 2022 at 8:58 AM David Barto
<david(a)kdbarto.org> wrote:
As others have mentioned, both. The compiler generated P-code, which was a
specialized bytecode representation of the compiled Pascal source.
The beauty of this is that it makes porting the system fairly easy; one
need only write a P-code interpreter. Assuming the system ships with a
p-code "binary" representation of the compiler in addition to the sources,
one could make it self-hosting very easily. With a threaded P-code
interpreter, it can also be quite small, making constrained 8-bit
microcomputers (like the Apple II) reasonable targets for Pascal.
This sort of representation also has some interesting properties with
respect to the actual bytecode used; it could, for example, have some
understanding of the semantics of types in the programming language. The
Dis virtual machine for the Limbo programming language used with the
Inferno virtual operating system did this; Dis understood Limbo strings,
whereas this isn't true on most machine architectures.
And is Java? They both have a byte code interpreter. Yes, modern Java is
Yes, the UCSD P-code interpreter was ported to
4.1 BSD on the VAX and it
ran natively there. I used it on sdcsvax in my senior year (1980).
This reminds me of a question I've had percolating in the back of my mind.
Was USCD Pascal "compiled" or "interpreted" or both?
JIT-compiled, but does that make Java a compiled
language in the Oracle
implementation, or is it an interpreter with a pretty good runtime?
Again, both. The compiler emits java bytecodes, which the JVM interprets.
Wasn't Java referred to as "compiled" even back before the JIT compiler
was
added?
Yes!
Granted, gcj is compiled.
31 Jan
31 Jan
12:57 a.m.
New subject: Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?
On Sun, Jan 30, 2022 at 2:52 PM Dan Cross <crossd(a)gmail.com> wrote:
On Sun, Jan 30, 2022 at 1:08 PM Dan Stromberg
<drsalists(a)gmail.com> wrote:
An interesting response.
I'll point out though, being a little picky, that python's "import"
statement will look for a .py, compile it, and write the byte code as a
.pyc - automatically. Then on subsequent invocations of the program(s)
using this module it will compare timestamps on the .py and .pyc and if the
.pyc is more recent than the .py, the compilation step will be skipped.
Thanks.
On Sun, Jan 30, 2022 at 8:58 AM David Barto
<david(a)kdbarto.org> wrote:
Yes!
And then there's the CPython implementation of Python. It too uses a byte
Yes, the UCSD P-code interpreter was ported to
4.1 BSD on the VAX and it
ran natively there. I used it on sdcsvax in my senior year (1980).
Wasn't Java referred to as "compiled" even back before the JIT compiler
was added?
code interpreter, but it's commonly referred
to as "interpreted". But is
it really? Granted, it has an implicit, cached compilation step, but is it
less compiled for that?
I think that "interpreted" in this context means the load-and-go nature of
the system and the transience of the bytecode: the text is internally
compiled and then executed, but these steps are often linked and, while one
can coax the Python "interpreter" to emit .pyc and/or .pyo files, usually
one does not: the compiled bytecodes are lost as soon as the program is
done executing.
1:23 a.m.
New subject: Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?
On 2022-01-30 17:51, Dan Cross wrote (in part):
Not really. As an interesting aside, before Java
became widespread I
heard folks mention "P-code" as a generic term for what most folks
mean when they say "bytecode." Now we often just say "bytecode."
Wirth called his Pascal bytecode P-code and his Modula bytecode M-code.
Why did Gosling not call his bytecode "J-code"?
- Dan C.
1:45 a.m.
New subject: Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?
On Sun, 30 Jan 2022, Nemo Nusquam wrote:
On 2022-01-30 17:51, Dan Cross wrote (in part):
And I think I've heard the Infocom compilers' bytecode called "Z-code"
(I
use this term too).
-uso.
Not really. As an interesting aside, before Java
became widespread I heard
folks mention "P-code" as a generic term for what most folks mean when they
say "bytecode." Now we often just say "bytecode."
Wirth called his Pascal bytecode P-code and his Modula bytecode M-code. Why
did Gosling not call his bytecode "J-code"? 
6:16 p.m.
New subject: Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?
On 1/30/22, Steve Nickolas <usotsuki(a)buric.co> wrote:
And I think I've heard the Infocom compilers' bytecode called
"Z-code" (I
use this term too).
That is correct. The Infocom games ran on an interpreter for an
abstract machine called the Z-machine. Z-code is the Z-machine's
instruction set. There is a freeware implementation out there called
Frotz.
-Paul W.
"Plugh" (said in a hollow voice)
9 p.m.
New subject: Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?
The definitions and boundaries between:
Instruction Set Architecture (usually hardware, but see Webasm)
P-code/bytecode interpreter internal instructions (e.g. Pascal, Java)
Register Transfer Languages (RTL - compilers)
seem awfully ... fuzzy. Are there any hard & fast rules for classifying particular
implementations into taxnomical categories? Wikipedia has an over-arching definition for
"intermediate representation" ...
https://en.wikipedia.org/wiki/Intermediate_representation
This is related to Unix in that Unix itself (both kernel system call API & C library)
is an abstracting intermediary between the hardware (whole computer system including
storage, networking), and application software, which "if written portably"
doesn't have to care what hardware it's run on, so long as that hardware meets
some minimum requirements for both Unix, and whatever the application's needs are.
Erik
11:45 p.m.
New subject: Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?
On Mon, 31 Jan 2022, Paul Winalski wrote:
On 1/30/22, Steve Nickolas <usotsuki(a)buric.co>
wrote:
There's also InfoTaskForce and JZIP, both of which I *think* work on *x,
but they are not as advanced as Frotz. JZIP comes closer, having been
Frotz's main competition for some time in the late 1990s.
-uso.
And I think I've heard the Infocom compilers' bytecode called
"Z-code" (I
use this term too).
That is correct. The Infocom games ran on an interpreter for an
abstract machine called the Z-machine. Z-code is the Z-machine's
instruction set. There is a freeware implementation out there called
Frotz.
-Paul W.
"Plugh" (said in a hollow voice)
2 Feb
2 Feb
5:53 a.m.
New subject: Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?
On Mon, Jan 31, 2022 at 10:17 AM Paul Winalski <paul.winalski(a)gmail.com>
wrote:
On 1/30/22, Steve Nickolas <usotsuki(a)buric.co>
wrote:
There's a reasonably functional Frotz implementation for TOPS-20, as it
happens. The ZIP interpreter was easier to port to 2.11BSD on the PDP-11.
https://github.com/athornton/tops20-frotz
Adam
And I think I've heard the Infocom
compilers' bytecode called "Z-code" (I
use this term too).
That is correct. The Infocom games ran on an interpreter for
an
abstract machine called the Z-machine. Z-code is the Z-machine's
instruction set. There is a freeware implementation out there called
Frotz.
31 Jan
31 Jan
2:41 a.m.
New subject: Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?
Is there consistency here?
There's a wide spectrum of strategies used for implementation of
languages, and no perfect and universally agreed on taxonomy.
(And in networking, where there is an "International Standard"
taxonomy, both the original ARPAnet, and the modern Internet
don't fit into the (ISO) model!)
At ends of the spectrum you might get people to agree on the "pure
interpreter", which intreprets source code DIRECTLY, and the "native
code compiler", which generates instructions for the instruction set
of a physical computer (typically the one the compiler is running on,
with the term "cross compiler" used when the target architecture is
different than the one the compiler is running on).
I don't doubt this has been brought up many times in the "comp.compilers"
group: https://compilers.iecc.com/
To bring the discussion back to "Unix Heritage":
The earliest Unix shells were pure interpreters
(and for all I know, most still are).
Some BASIC language systems have been pure interpreters, but it gets
murky fast; Some interpretive systems have converted source code to
tokens in memory, or even saved to disk.
Beyond pure interpreters, most interpreters perform some kind of
compilation into some alternate representation of the program often
starting (with and sometimes (LISP), ending) with a tree. Often, the
tree is traversed to a prefix or postfix "polish" form, which might,
or might not be written out (as a byte code, or other intermediate
form).
The earliest Unix language systems (TMG and B) on both the PDP-7 and
PDP-11 are interesting in that they output "word code" that is
assembled by as, and loaded with ld to produce "regular" executable
files which contain interpreters.
The earliest (PDP-7) Unix compilers, TMG and B both generated code for
(stack-oriented, postfix) pseudo machines (which happened to have
opcode fields the same size and position as the PDP-7 itself).
Since PDP-11 pointers can be a full 16-bit word, PDP-11 TMG and B
generate a stream of 16-bit postfix code (with pointers to interpreter
and "native code" support routines). TMG contains an interpreter
loop, but the B interpreter is "threaded code" using machine register
r3 for the interpreter program counter, and each interpreter opcode
routine ends with "jmp *(r3)+"
I haven't examined Sixth Edition "bas" (written in assembler) closely
enough to say what kind of internal representation (if any) it uses.
"bc" generates postfix "dc" code using a yacc parser, and
"sno"
appears to recursively eval a tree.
Seventh Edition awk looks to recursively execute a tree generated by a
yacc parser.
Compilers on older/smaller systems were sometimes divided into
multiple passes and wrote intermediate representations to disk, and
such output _could_ have been interpreted.
Language processors which output source code for another language (on
heritage Unix; struct, ratfor, and cfront for early C++) are usually
called preprocessors.
So... Interpreters and preprocessors may perform much the same work
as compilers in their front ends, may or may not be identified as
compilers.
Java (and UCSD Pascal?) have compilers (to virtual machine code)
and an interpreter (for the virtual machine code).
Clear as mud?
7 Feb
7 Feb
4:04 a.m.
On 1/29/2022 11:59 AM, Clem Cole wrote:
Sun later brought the UCB PI and PC to the SunOS, but
pls Rob G/Larry
correct me here - I think they later did their own compiler when they
did their new C and Fortran.
Sun never replaced the UCB Pascal front-end, just moved it across
back-ends as it evolved them.
The development of SPARC required Sun to develop back-end expertise.
Although the investments focused on SPARC, there was also work on the
back-ends for the Motorola- and Intel-based products.
Sun's front-end investments began with the SVR4 project as an ANSI C
compiler was needed. (A priority for SVR4 was conformance with
then-current external standards such as POSIX and ANSI. Over the course
of SVR4's development strict ANSI conformance came to be seen as
problematic: most SV licensees didn't just use the release as delivered
and instead merged portions into their extant, and not ANSI, product
source code bases. This led to some late-in-the-project de-ANSIfying of
the source in the interest of making SVR4 more digestible by the licensees.)
That C compiler was the basis for the unbundled C compiler product that
came out at the time of SunOS 4.1.
Sun's larger investments in front-end development were motivated by the
later transition from F77 to F9X. Which is another data point in support
of Clem's frequent observation that FORTRAN is a big deal in parts of
the real world. At that point Sun tended to its own front ends for C,
C++, and FORTRAN but Pascal was always the UCB front end.
1014
days inactive
1024
days old
30 comments
21 participants
participants (21)
-
Adam Thornton -
Al Kossow -
arnold＠skeeve.com -
Bakul Shah -
Clem Cole -
Dan Cross -
Dan Stromberg -
David Barto -
Erik E. Fair -
GREEN -
John Cowan -
Jon Steinhart -
Larry McVoy -
Nemo Nusquam -
Paul Winalski -
Phil Budne -
Rob Gingell -
Rob Pike -
Steve Nickolas -
WEB -
Will Senn