Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Mon, 14 Oct 2024 01:20:45 +0100
Organization: A noiseless patient Spider
Lines: 132
Message-ID: <veho4s$sghb$1@dont-email.me>
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>
 <vehajq$fl2$2@reader1.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 14 Oct 2024 02:20:45 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="469afc031e4f4d5cdad22fc639696cda";
	logging-data="934443"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+wL9hgyr7z1WmTD2lYgKvK"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:XS12vAfm4Yi3nqye5k+oO2TwyG8=
In-Reply-To: <vehajq$fl2$2@reader1.panix.com>
Content-Language: en-GB
Bytes: 6843

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:
>>> 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.

So, then what, we do away with the concepts of 'compiler' and 
'interpreter'? Or allow them to be used interchangeably?

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.

>> 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)

Example of JVM:

   aload index      Push a reference from local variable #index

 >>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.


>> 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!

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