Re: Command Languages Versus Programming Languages

In article <vegs0o$nh5t$1@dont-email.me>, Bart  <bc@freeuk.com> wrote:

On 13/10/2024 16:52, Dan Cross wrote:

In article <QnROO.226037$EEm7.111715@fx16.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <vefvo0$k1mm$1@dont-email.me>,  <Muttley@DastartdlyHQ.org> wrote:

>

Really? So java bytecode will run direct on x86 or ARM will it? Please give
some links to this astounding discovery you've made.

>
Um, ok. https://en.wikipedia.org/wiki/Jazelle

>
There was also a company a couple of decades ago that
built an entire processor designed to execute bytecode
directly - with a coprocessor to handle I/O.
>
IIRC, it was Azul.    There were a number of others, including
Sun.
>
None of them panned out - JIT's ended up winning that battle.
>
Even ARM no longer includes Jazelle extensions in any of their
mainstream processors.

 
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.

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

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.

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

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.

- Dan C.