[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 --]

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?

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

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

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

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

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

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?

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

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

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

[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 --]

[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 --]