Path: ...!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Sun, 13 Oct 2024 20:29:46 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vehajq$fl2$2@reader1.panix.com>
References: <uu54la$3su5b$6@dont-email.me> <QnROO.226037$EEm7.111715@fx16.iad> <vegqbe$he8$1@reader1.panix.com> <vegs0o$nh5t$1@dont-email.me>
Injection-Date: Sun, 13 Oct 2024 20:29:46 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="16034"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 4748
Lines: 90

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.