Re: On overly rigid definitions (was Re: Command Languages Versus Programming Languages)

Liste des GroupesRevenir à cl misc 
Sujet : Re: On overly rigid definitions (was Re: Command Languages Versus Programming Languages)
De : cross (at) *nospam* spitfire.i.gajendra.net (Dan Cross)
Groupes : comp.unix.shell comp.unix.programmer comp.lang.misc
Date : 14. Oct 2024, 01:58:11
Autres entêtes
Organisation : PANIX Public Access Internet and UNIX, NYC
Message-ID : <vehqb3$4q$1@reader1.panix.com>
References : 1 2 3 4
User-Agent : trn 4.0-test77 (Sep 1, 2010)
In article <veho4s$sghb$1@dont-email.me>, Bart  <bc@freeuk.com> wrote:
On 13/10/2024 21:29, Dan Cross wrote:
In article <vegs0o$nh5t$1@dont-email.me>, Bart  <bc@freeuk.com> wrote:
On 13/10/2024 16:52, Dan Cross wrote:
[snip]
Sure.  But the fact that any of these were going concerns is an
existence proof that one _can_ take bytecodes targetted toward a
"virtual" machine and execute it on silicon,
making the
distinction a lot more fluid than might be naively assumed, in
turn exposing the silliness of this argument that centers around
this weirdly overly-rigid definition of what a "compiler" is.
>
I've implemented numerous compilers and interpreters over the last few
decades (and have dabbled in emulators).
>
To me the distinctions are clear enough because I have to work at the
sharp end!
>
I'm not sure why people want to try and be clever by blurring the roles
of compiler and interpreter; that's not helpful at all.
 
I'm not saying the two are the same; what I'm saying is that
this arbitrary criteria that a compiler must emit a fully
executable binary image is not just inadquate, but also wrong,
as it renders separate compilation impossible.  I am further
saying that there are many different _types_ of compilers,
including specialized tools that don't emit machine language.
 
Sure, people can write emulators for machine code, which are a kind of
interpreter, or they can implement bytecode in hardware; so what?
 
That's exactly my point.
>
So, then what, we do away with the concepts of 'compiler' and
'interpreter'? Or allow them to be used interchangeably?

I don't see how you can credibly draw that conclusion from what
I've been saying.

But it's really pretty straight-forward; a compiler effects a
translation from one computer language to another (the
definition from Aho et al).  An interpreter takes a program
written in some computer language and executes it.  Of course
there's some gray area here; is a load-and-go compiler a
compiler in this sense (yes; it is still translating between
its source language and a machine language) or an interpreter?
(Possibly; after all, it's taking a source language and causing
a program written in it to be executed.)

Java is an interesting case in point here; the Java compiler is
obviously a compiler; the JVM is an interpreter.  I don't think
anyone would dispute this.  But by suggesting some hard and fast
division that can be rigidly upheld in all cases we're ignoring
so much nuance as to be reductive; but by pointing these things
out, we see how inane it is to assert that a "proper compiler"
is only one that takes a textual source input and emits machine
code for a silicon target.

Somehow I don't think it is useful to think of gcc as a interpreter for
C, or CPython as an native code compiler for Python.

I don't think anyone suggested that.  But we _do_ have examples
of true compilers emitting "code" for interpreters; cf LLVM and
eBPF, which I mentioned previously in this thread, or compilers
that emit code for hypothetical machines like MMIX, or compilers
that emit instructions that aren't implemented everywhere, or
more precisely are implemented by trap and emulation.

That doesn't really affect what I do. Writing compiler backends for
actual CPUs is hard work. Generating bytecode is a lot simpler.
 
That really depends on the bytecode, doesn't it?  The JVM is a
complex beast;
>
Is it? It's not to my taste, but it didn't look too scary to me. Whereas
modern CPU instruction sets are horrendous. (I normally target x64,
which is described in 6 large volumes. RISC ones don't look much better,
eg. RISC V with its dozens of extensions and special types)

I dunno.  Wirth wrote an Oberon compiler targeting MIPS in ~5000
lines of code.  It was pretty straight-forward.

And most of those ten volumes in the SDM have to do with the
privileged instruction set and details of the memory model like
segmentation and paging, most of which don't impact the compiler
author much at all: beyond, perhaps providing an intrinsic for
the `rdmsr` and `wrmsr` instructions, I don't think you care
much about MSRs, let alone VMX or the esoterica of under what
locked cycles the hardware sets the "A" bit on page table
entries on a TLB miss.

Example of JVM:
>
  aload index      Push a reference from local variable #index

Ok. `leaq index(%rip), %rax; pushq %rax` isn't that hard either.

MIPS or the unprivileged integer subset of RISC-V
are pretty simple in comparison.
 
(Especially in my case as I've devised myself, another distinction.
Compilers usually target someone else's instruction set.)
>
If you want one more distinction, it is this: with my compiler, the
resultant binary is executed by a separate agency: the CPU. Or maybe the
OS loader will run it through an emulator.
 
Python has a mode by which it will emit bytecode _files_, which
can be separately loaded and interpreted; it even has an
optimizing mode.  Is that substantially different?
>
Whether there is a discrete bytecode file is besides the point. (I
generated such files for many years.)
>
You still need software to execute it. Especially for dynamically typed
bytecode which doesn't lend itself easily to either hardware
implementations, or load-time native code translation.

Sure.  But if execution requires a "separate agency", and you
acknowledge that could be a CPU or a separate program, how is
that all that different than what Python _does_?  That doesn't
imply that the Python interpreter is the same as a CPU, or that
an interpreter is the same as a compiler.  But it does imply
that the definitions being thrown about here aren't particularly
good.

With my interpreter, then *I* have to write the dispatch routines and
write code to implement all the instructions.
 
Again, I don't think that anyone disputes that interpreters
exist.  But insisting that they must take a particular shape is
just wrong.
>
What shape would that be? Generally they will need some /software/ to
excute the instructions of the program being interpreted, as I said.
Some JIT products may choose to do on-demand translation to native code.
>
Is there anything else? I'd be interested in anything new!

I actually meant to write that "insisting that _compilers_ take
a specific shape is just wrong."  But I think the point holds
reasonably well for interpreters, as well: they need not
directly interpret the text of a program; they may well create
some sort of internal bytecode after several optimization and
type checking steps, looking more like a load-and-go compiler
than, say, the 6th Edition Unix shell.

Comparison to Roslyn-style compilers blurs the distinction
further still.

(My compilers generate an intermediate language, a kind of VM, which is
then processed further into native code.
 
Then by the definition of this psuedonyminous guy I've been
responding to, your compiler is not a "proper compiler", no?
>
Actually mine is more of a compiler than many, since it directly
generates native machine code. Others generally stop at ASM code (eg.
gcc) or OBJ code, and will invoke separate programs to finish the job.
>
The intermediate language here is just a step in the process.
>
But I have also tried interpreting that VM; it just runs 20 times slower
than native code. That's what interpreting usually means: slow programs.)
 
Not necessarily.  The JVM does pretty good, quite honestly.
>
But is it actually interpreting? Because if I generated such code for a
statically typed language, then I would first translate to native code,
of any quality, since it's going to be faster than interpreting.

Doesn't that reinforce my thesis that these things are much
blurier than all this uninformed talk of a mythical "proper
compiler" would lead one to believe?

- Dan C.


Date Sujet#  Auteur
29 Mar 24 * Command Languages Versus Programming Languages750Lawrence D'Oliveiro
29 Mar 24 +- Re: Command Languages Versus Programming Languages1candycanearter07
29 Mar 24 +* Re: Command Languages Versus Programming Languages170Muttley
29 Mar 24 i+- Re: Command Languages Versus Programming Languages1Josef Möllers
29 Mar 24 i+* Re: Command Languages Versus Programming Languages9Richard Kettlewell
29 Mar 24 ii`* Re: Command Languages Versus Programming Languages8Muttley
29 Mar 24 ii `* Re: Command Languages Versus Programming Languages7Kaz Kylheku
29 Mar 24 ii  `* Re: Command Languages Versus Programming Languages6Muttley
29 Mar 24 ii   `* Re: Command Languages Versus Programming Languages5Kaz Kylheku
30 Mar 24 ii    `* Re: Command Languages Versus Programming Languages4Muttley
30 Mar 24 ii     +- Re: Command Languages Versus Programming Languages1Janis Papanagnou
30 Mar 24 ii     `* Re: Command Languages Versus Programming Languages2Kaz Kylheku
1 Apr 24 ii      `- Re: Command Languages Versus Programming Languages1Muttley
29 Mar 24 i`* Re: Command Languages Versus Programming Languages159John Ames
29 Mar 24 i +* Re: Command Languages Versus Programming Languages157Muttley
29 Mar 24 i i+- Re: Command Languages Versus Programming Languages1John Ames
29 Mar 24 i i+* Re: Command Languages Versus Programming Languages151Kaz Kylheku
29 Mar 24 i ii`* Re: Command Languages Versus Programming Languages150Muttley
29 Mar 24 i ii +* Re: Command Languages Versus Programming Languages148Kaz Kylheku
29 Mar 24 i ii i+* Re: Command Languages Versus Programming Languages4David W. Hodgins
29 Mar 24 i ii ii+* Re: Command Languages Versus Programming Languages2Johanne Fairchild
30 Mar 24 i ii iii`- Re: Command Languages Versus Programming Languages1David W. Hodgins
30 Mar 24 i ii ii`- Re: Command Languages Versus Programming Languages1Janis Papanagnou
30 Mar 24 i ii i`* Re: Command Languages Versus Programming Languages143Muttley
30 Mar 24 i ii i `* Re: Command Languages Versus Programming Languages142Kaz Kylheku
1 Apr 24 i ii i  `* Re: Command Languages Versus Programming Languages141Muttley
1 Apr 24 i ii i   +* Re: Command Languages Versus Programming Languages139Johanne Fairchild
1 Apr 24 i ii i   i`* Re: Command Languages Versus Programming Languages138Muttley
1 Apr 24 i ii i   i +- Re: Command Languages Versus Programming Languages1Kaz Kylheku
2 Apr 24 i ii i   i `* Re: Command Languages Versus Programming Languages136Johanne Fairchild
2 Apr 24 i ii i   i  +* Re: Command Languages Versus Programming Languages115ram@zedat.fu-berlin.de (Stefan Ram)
2 Apr 24 i ii i   i  i+* Re: Command Languages Versus Programming Languages112Stefan Ram
2 Apr 24 i ii i   i  ii+* Re: Command Languages Versus Programming Languages110Stefan Ram
3 Apr 24 i ii i   i  iii`* Re: Command Languages Versus Programming Languages109Lawrence D'Oliveiro
3 Apr 24 i ii i   i  iii `* Re: Command Languages Versus Programming Languages108David Brown
3 Apr 24 i ii i   i  iii  +- Re: Command Languages Versus Programming Languages1Lawrence D'Oliveiro
3 Apr 24 i ii i   i  iii  +- Re: Command Languages Versus Programming Languages1John Ames
3 Apr 24 i ii i   i  iii  `* Re: Command Languages Versus Programming Languages105Keith Thompson
3 Apr 24 i ii i   i  iii   +* Re: Command Languages Versus Programming Languages100Richard Kettlewell
4 Apr 24 i ii i   i  iii   i+- Re: Command Languages Versus Programming Languages1Muttley
4 Apr 24 i ii i   i  iii   i`* Re: Command Languages Versus Programming Languages98Stefan Ram
5 Apr 24 i ii i   i  iii   i `* Re: Command Languages Versus Programming Languages97Lawrence D'Oliveiro
5 Apr 24 i ii i   i  iii   i  +* Re: Command Languages Versus Programming Languages49Muttley
5 Apr 24 i ii i   i  iii   i  i+* Re: Command Languages Versus Programming Languages3candycanearter07
5 Apr 24 i ii i   i  iii   i  ii`* Re: Command Languages Versus Programming Languages2Muttley
6 Apr 24 i ii i   i  iii   i  ii `- Re: Command Languages Versus Programming Languages1candycanearter07
6 Apr 24 i ii i   i  iii   i  i`* Re: Command Languages Versus Programming Languages45Lawrence D'Oliveiro
6 Apr 24 i ii i   i  iii   i  i `* Re: Command Languages Versus Programming Languages44Alan Bawden
6 Apr 24 i ii i   i  iii   i  i  +* Re: Command Languages Versus Programming Languages13Lawrence D'Oliveiro
8 Apr 24 i ii i   i  iii   i  i  i`* Re: Command Languages Versus Programming Languages12John Ames
9 Apr 24 i ii i   i  iii   i  i  i `* Re: Command Languages Versus Programming Languages11Lawrence D'Oliveiro
9 Apr 24 i ii i   i  iii   i  i  i  +* Re: Command Languages Versus Programming Languages9John Ames
9 Apr 24 i ii i   i  iii   i  i  i  i`* Re: Command Languages Versus Programming Languages8Richard Kettlewell
9 Apr 24 i ii i   i  iii   i  i  i  i +* Re: Command Languages Versus Programming Languages2Janis Papanagnou
9 Apr 24 i ii i   i  iii   i  i  i  i i`- Re: Command Languages Versus Programming Languages1Richard Kettlewell
9 Apr 24 i ii i   i  iii   i  i  i  i `* Re: Command Languages Versus Programming Languages5David Brown
9 Apr 24 i ii i   i  iii   i  i  i  i  `* Re: Command Languages Versus Programming Languages4Lawrence D'Oliveiro
9 Apr 24 i ii i   i  iii   i  i  i  i   `* Re: Command Languages Versus Programming Languages3David Brown
10 Apr 24 i ii i   i  iii   i  i  i  i    `* Re: Command Languages Versus Programming Languages2Lawrence D'Oliveiro
10 Apr 24 i ii i   i  iii   i  i  i  i     `- Re: Command Languages Versus Programming Languages1Kaz Kylheku
9 Apr 24 i ii i   i  iii   i  i  i  `- Re: Command Languages Versus Programming Languages1Kaz Kylheku
6 Apr 24 i ii i   i  iii   i  i  +* Re: Command Languages Versus Programming Languages3Kaz Kylheku
6 Apr 24 i ii i   i  iii   i  i  i`* Re: Command Languages Versus Programming Languages2David Brown
6 Apr 24 i ii i   i  iii   i  i  i `- Re: Command Languages Versus Programming Languages1Muttley
6 Apr 24 i ii i   i  iii   i  i  +- Re: Command Languages Versus Programming Languages1candycanearter07
6 Apr 24 i ii i   i  iii   i  i  `* Re: Command Languages Versus Programming Languages26Muttley
7 Apr 24 i ii i   i  iii   i  i   +* Re: Command Languages Versus Programming Languages22Alan Bawden
8 Apr 24 i ii i   i  iii   i  i   i`* Re: Command Languages Versus Programming Languages21Muttley
8 Apr 24 i ii i   i  iii   i  i   i `* Re: Command Languages Versus Programming Languages20David Brown
8 Apr 24 i ii i   i  iii   i  i   i  `* Re: Command Languages Versus Programming Languages19Muttley
8 Apr 24 i ii i   i  iii   i  i   i   +* Words to the wise (Was: Command Languages Versus Programming Languages)2Kenny McCormack
8 Apr 24 i ii i   i  iii   i  i   i   i`- Re: Words to the wise (Was: Command Languages Versus Programming Languages)1Muttley
8 Apr 24 i ii i   i  iii   i  i   i   `* Re: Command Languages Versus Programming Languages16Kaz Kylheku
8 Apr 24 i ii i   i  iii   i  i   i    +* Phrases that should be banned on Usenet (Was: Command Languages Versus Programming Languages)9Kenny McCormack
9 Apr 24 i ii i   i  iii   i  i   i    i`* Re: Phrases that should be banned on Usenet (Was: Command Languages Versus Programming Languages)8Janis Papanagnou
9 Apr 24 i ii i   i  iii   i  i   i    i +- Re: Phrases that should be banned on Usenet (Was: Command Languages Versus Programming Languages)1D
9 Apr 24 i ii i   i  iii   i  i   i    i `* Re: Phrases that should be banned on Usenet (Was: Command Languages Versus Programming Languages)6candycanearter07
9 Apr 24 i ii i   i  iii   i  i   i    i  `* Re: Phrases that should be banned on Usenet (Was: Command Languages Versus Programming Languages)5Janis Papanagnou
9 Apr 24 i ii i   i  iii   i  i   i    i   +- Re: Phrases that should be banned on Usenet (Was: Command Languages Versus Programming Languages)1candycanearter07
10 Apr 24 i ii i   i  iii   i  i   i    i   `* Re: Phrases that should be banned on Usenet (Was: Command Languages Versus Programming Languages)3Lawrence D'Oliveiro
10 Apr 24 i ii i   i  iii   i  i   i    i    +- Re: Phrases that should be banned on Usenet (Was: Command Languages Versus Programming Languages)1Chris Elvidge
10 Apr 24 i ii i   i  iii   i  i   i    i    `- Re: Phrases that should be banned on Usenet (Was: Command Languages Versus Programming Languages)1candycanearter07
9 Apr 24 i ii i   i  iii   i  i   i    `* Re: Command Languages Versus Programming Languages6Muttley
9 Apr 24 i ii i   i  iii   i  i   i     +- Re: Command Languages Versus Programming Languages1Kaz Kylheku
9 Apr 24 i ii i   i  iii   i  i   i     +- Re: Command Languages Versus Programming Languages1Janis Papanagnou
9 Apr 24 i ii i   i  iii   i  i   i     `* Re: Command Languages Versus Programming Languages3Muttley
9 Apr 24 i ii i   i  iii   i  i   i      `* Re: Command Languages Versus Programming Languages2John Ames
9 Apr 24 i ii i   i  iii   i  i   i       `- Re: Command Languages Versus Programming Languages1Muttley
8 Apr 24 i ii i   i  iii   i  i   +- [meta] Re: Command Languages Versus Programming Languages1Janis Papanagnou
10 Apr 24 i ii i   i  iii   i  i   `* Re: Command Languages Versus Programming Languages2Keith Thompson
10 Apr 24 i ii i   i  iii   i  i    `- Re: Command Languages Versus Programming Languages1Kenny McCormack
5 Apr 24 i ii i   i  iii   i  `* Re: Command Languages Versus Programming Languages47Janis Papanagnou
5 Apr 24 i ii i   i  iii   i   +* Re: Command Languages Versus Programming Languages27Stefan Ram
6 Apr 24 i ii i   i  iii   i   i+* Re: Command Languages Versus Programming Languages4Muttley
7 Apr 24 i ii i   i  iii   i   ii`* Re: Command Languages Versus Programming Languages3Lawrence D'Oliveiro
8 Apr 24 i ii i   i  iii   i   ii `* Re: Command Languages Versus Programming Languages2Muttley
9 Apr 24 i ii i   i  iii   i   ii  `- Re: Command Languages Versus Programming Languages1Lawrence D'Oliveiro
6 Apr 24 i ii i   i  iii   i   i+- Re: Command Languages Versus Programming Languages1Janis Papanagnou
6 Aug 24 i ii i   i  iii   i   i`* Re: Command Languages Versus Programming Languages21Sebastian
7 Aug 24 i ii i   i  iii   i   i `* Re: Command Languages Versus Programming Languages20Lawrence D'Oliveiro
7 Aug 24 i ii i   i  iii   i   i  +* Re: Command Languages Versus Programming Languages3Kaz Kylheku
8 Aug 24 i ii i   i  iii   i   i  +* Re: Command Languages Versus Programming Languages4Andreas Eder
25 Aug 24 i ii i   i  iii   i   i  `* Re: Command Languages Versus Programming Languages12Sebastian
5 Apr 24 i ii i   i  iii   i   +- Re: Command Languages Versus Programming Languages1Kaz Kylheku
6 Apr 24 i ii i   i  iii   i   `* Re: Command Languages Versus Programming Languages18Lawrence D'Oliveiro
3 Apr 24 i ii i   i  iii   `* Re: Command Languages Versus Programming Languages4David Brown
2 Apr 24 i ii i   i  ii`- Re: Command Languages Versus Programming Languages1Kaz Kylheku
2 Apr 24 i ii i   i  i`* Re: Command Languages Versus Programming Languages2Kaz Kylheku
2 Apr 24 i ii i   i  `* Re: Command Languages Versus Programming Languages20Lawrence D'Oliveiro
1 Apr 24 i ii i   `- Re: Command Languages Versus Programming Languages1Lawrence D'Oliveiro
1 Apr 24 i ii `- Re: Command Languages Versus Programming Languages1Andreas Eder
29 Mar 24 i i+- Re: Command Languages Versus Programming Languages1Christian Weisgerber
30 Mar 24 i i+* Re: Command Languages Versus Programming Languages2David Brown
30 Sep 24 i i`- Re: Command Languages Versus Programming Languages1Bozo User
29 Mar 24 i `- Re: Command Languages Versus Programming Languages1Kaz Kylheku
29 Mar 24 +* Re: Command Languages Versus Programming Languages554Johanne Fairchild
29 Mar 24 +* Re: Command Languages Versus Programming Languages2David Brown
29 Mar 24 +* Re: Command Languages Versus Programming Languages15Lawrence D'Oliveiro
30 Mar 24 +* Re: Command Languages Versus Programming Languages3Dmitry A. Kazakov
30 Sep 24 `* Re: Command Languages Versus Programming Languages4Bozo User

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal