[TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?

[TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?

[silas poulson]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]


Resending this as realised accidentally replied off list

Silas

On 30 Jan 2022, at 18:39, silas poulson <silas8642@hotmail.co.uk<mailto:silas8642@hotmail.co.uk>> wrote:

On 30 Jan 2022, at 18:07, Dan Stromberg <drsalists@gmail.com<mailto:drsalists@gmail.com>> wrote:
And is Java?  They both have a byte code interpreter.

My understanding is Java is both a compiled and interpreted language -
with javac compiling java code to byte code and then JVM interpreting
and executing the byte code.

And then there's the CPython implementation of Python. <snip>
Granted, it has an implicit, cached compilation step, but is it less compiled for that?

I would so no - in my mind compiling analyses the entire source and
then translates it whilst interpreters only explore a single line or
expression. Simply because the compilation happens only Just In Time,
doesn’t make it any less of a compilation step.

Hope that helps,
Silas



[-- Attachment #2: Type: text/html, Size: 1929 bytes --]

[TUHS] Looking back to 1981 - what pascal was popular on what unix?

[Will Senn]

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 703 bytes --]

Re: [TUHS] Looking back to 1981 - what pascal was popular on what unix?

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 3966 bytes --]

On Fri, Jan 28, 2022 at 6:08 PM Will Senn <will.senn@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.

>

[-- Attachment #2: Type: text/html, Size: 7164 bytes --]

Re: [TUHS] Looking back to 1981 - what pascal was popular on what unix?

[David Barto]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]



> On Jan 29, 2022, at 11:59 AM, Clem Cole <clemc@ccc.com> wrote:
> 
> 
> 
> On Fri, Jan 28, 2022 at 6:08 PM Will Senn <will.senn@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


[-- Attachment #2: Type: text/html, Size: 2357 bytes --]

[TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?

[Dan Stromberg]

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

On Sun, Jan 30, 2022 at 8:58 AM David Barto <david@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?

[-- Attachment #2: Type: text/html, Size: 1733 bytes --]

Re: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?

[David Barto]

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]


> On Jan 30, 2022, at 10:08 AM, Dan Stromberg <drsalists@gmail.com> wrote:
> 
> 
> 
>> On Sun, Jan 30, 2022 at 8:58 AM David Barto <david@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?
> 
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

[-- Attachment #2: Type: text/html, Size: 2316 bytes --]

Re: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?

[WEB]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

Am 30.01.2022 um 21:09 schrieb David Barto:
>
>> On Jan 30, 2022, at 10:08 AM, Dan Stromberg <drsalists@gmail.com> wrote:
>> On Sun, Jan 30, 2022 at 8:58 AM David Barto <david@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

[-- Attachment #2: Type: text/html, Size: 2599 bytes --]

Re: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 4248 bytes --]

On Sun, Jan 30, 2022 at 1:08 PM Dan Stromberg <drsalists@gmail.com> wrote:

> On Sun, Jan 30, 2022 at 8:58 AM David Barto <david@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?
>

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

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.

[-- Attachment #2: Type: text/html, Size: 6507 bytes --]

Re: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?

[Dan Stromberg]

[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]

On Sun, Jan 30, 2022 at 2:52 PM Dan Cross <crossd@gmail.com> wrote:

> On Sun, Jan 30, 2022 at 1:08 PM Dan Stromberg <drsalists@gmail.com> wrote:
>
>> On Sun, Jan 30, 2022 at 8:58 AM David Barto <david@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).
>>>
>>
>> Wasn't Java referred to as "compiled" even back before the JIT compiler
>> was added?
>>
>
> Yes!
>
> 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.
>

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.

[-- Attachment #2: Type: text/html, Size: 2950 bytes --]

Re: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?

[Nemo Nusquam]

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.

Re: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?

[Steve Nickolas]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

On Sun, 30 Jan 2022, Nemo Nusquam wrote:

> 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"?

And I think I've heard the Infocom compilers' bytecode called "Z-code" (I 
use this term too).

-uso.

Re: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?

[Paul Winalski]

On 1/30/22, Steve Nickolas <usotsuki@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)

Re: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?

[Erik E. Fair]

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

Re: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?

[Steve Nickolas]

On Mon, 31 Jan 2022, Paul Winalski wrote:

> On 1/30/22, Steve Nickolas <usotsuki@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)
>

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.

Re: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?

[Adam Thornton]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

On Mon, Jan 31, 2022 at 10:17 AM Paul Winalski <paul.winalski@gmail.com>
wrote:

> On 1/30/22, Steve Nickolas <usotsuki@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.
>
>
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

[-- Attachment #2: Type: text/html, Size: 1216 bytes --]

Re: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?

[Phil Budne]

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