Re: Command Languages Versus Programming Languages

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.
Sure, people can write emulators for machine code, which are a kind of interpreter, or they can implement bytecode in hardware; so what?
That doesn't really affect what I do. Writing compiler backends for actual CPUs is hard work. Generating bytecode is a lot simpler. (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.
With my interpreter, then *I* have to write the dispatch routines and write code to implement all the instructions.
(My compilers generate an intermediate language, a kind of VM, which is then processed further into native code.
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.)