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.

- Dan C.

On Sun, 13 Oct 2024 15:30:03 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>In article <vegmul$ne3v$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>>So what is standard terminology then?
>
>I've already explained this to you.

No you haven't. You explanation seems to be "anything that converts from one
language to another".

>>What happens inside the CPU is irrelevant. Its a black box as far as the
>>rest of the machine is concerned. As I said in another post, it could be
>>pixies with abacuses, doesn't matter.
>
>So why do you think it's so important that the definition of a

Who said its important? Its just what most people think of as compilers.

>CPU"? If, as you admit, what the CPU does is highly variable,
>then why do you cling so hard to this meaningless distinction?

You're the one making a big fuss about it with pages of waffle to back up
your claim.

>>[lots of waffle snipped]
>
>In other words, you discard anything that doesn't fit with your
>preconceptions. Got it.

No, I just have better things to do on a sunday than read all that. Keep
it to the point.

>>So its incomplete and has to revert to software for some opcodes. Great.
>>FWIW Sun also had a java processor but you still can't run bytecode on
>>normal hardware without a JVM.
>
>Cool. So if I run a program targetting a newer version of an
>ISA is run on an older machine, and that machine lacks a newer
>instruction present in the program, and the CPU generates an
>illegal instruction trap at runtime that the OS catches and
>emulates on the program's behalf, the program was not compiled?
>
>And again, what about an emulator for a CPU running on a
>different CPU? I can boot 7th Edition Unix on a PDP-11
>emulator on my workstation; does that mean that the 7the
>edition C compiler wasn't a compiler?

Its all shades of grey. You seem to be getting very worked up about it.
As I said, most people consider a compiler as something that translates source
code to machine code and writes it to a file.

>>Why, whats the difference? Your definition seems to be any program that can
>>translate from one language to another.
>
>If you can't see that yourself, then you're either ignorant or
>obstinant. Take your pick.

So you can't argue the failure of your logic then. Noted.

>>Yes, they're entirely analoguous.
>>
>>https://docs.oracle.com/cd/E11882_01/appdev.112/e10825/pc_02prc.htm
>
>Nah, not really.

Oh nice counter arguement, you really sold your POV there.

>>Who cares about the current state? Has nothing to do with this discussion.
>
>In other words, "I don't have an argument, so I'll just lamely
>try to define things until I'm right."

Im just defining things the way most people see it, not some ivory tower
academics. Anyway, lifes too short for the rest.

[tl;dr]

>>that a compiler is pretty much any program which translates from one thing to
>>another.
>
>No. It translates one computer _language_ to another computer
>_language_. In the usual case, that's from a textual source

Machine code isn't a language. Fallen at the first hurdle with that
definition.

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

On 2024-10-11, Muttley@DastartdlyHQ.org <Muttley@DastartdlyHQ.org> wrote:
> Irrelevant. Lot of interpreters do partial compilation and the JVM does it
> on the fly. A proper compiler writes a standalone binary file to disk.

You might want to check those goalposts again. You can easily make a
"proper compiler" which just writes a canned interpreter executable to
disk, appending to it the program source code.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 13/10/2024 17:31, Kaz Kylheku wrote:
> On 2024-10-11, Muttley@DastartdlyHQ.org <Muttley@DastartdlyHQ.org> wrote:
>> Irrelevant. Lot of interpreters do partial compilation and the JVM does it
>> on the fly. A proper compiler writes a standalone binary file to disk.
>
> You might want to check those goalposts again. You can easily make a
> "proper compiler" which just writes a canned interpreter executable to
> disk, appending to it the program source code.
>

So, an interpreter. The rest is just details of its deployment. In your
example, the program being run is just some embedded data.

Maybe the real question is what is 'hardware', and what is 'software'.
But the answer won't make everyone happy because because hardware can be
emulated in software.

(Implementing software in hardware, specifically the bit of software
that interprets a VM, is less common, and generally harder.)

I prefer that there is a clear distinction between compiler and
interpreter, because you immediately know what's what. (Here I'm
excluding complex JIT products that mix up both.)

In article <vegqu5$o3ve$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>On Sun, 13 Oct 2024 15:30:03 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>>In article <vegmul$ne3v$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>>>So what is standard terminology then?
>>
>>I've already explained this to you.
>
>No you haven't. You explanation seems to be "anything that converts from one
>language to another".
>
>>>What happens inside the CPU is irrelevant. Its a black box as far as the
>>>rest of the machine is concerned. As I said in another post, it could be
>>>pixies with abacuses, doesn't matter.
>>
>>So why do you think it's so important that the definition of a
>
>Who said its important? Its just what most people think of as compilers.
>
>>CPU"? If, as you admit, what the CPU does is highly variable,
>>then why do you cling so hard to this meaningless distinction?
>
>You're the one making a big fuss about it with pages of waffle to back up
>your claim.
>
>>>[lots of waffle snipped]
>>
>>In other words, you discard anything that doesn't fit with your
>>preconceptions. Got it.
>
>No, I just have better things to do on a sunday than read all that. Keep
>it to the point.
>
>>>So its incomplete and has to revert to software for some opcodes. Great.
>>>FWIW Sun also had a java processor but you still can't run bytecode on
>>>normal hardware without a JVM.
>>
>>Cool. So if I run a program targetting a newer version of an
>>ISA is run on an older machine, and that machine lacks a newer
>>instruction present in the program, and the CPU generates an
>>illegal instruction trap at runtime that the OS catches and
>>emulates on the program's behalf, the program was not compiled?
>>
>>And again, what about an emulator for a CPU running on a
>>different CPU? I can boot 7th Edition Unix on a PDP-11
>>emulator on my workstation; does that mean that the 7the
>>edition C compiler wasn't a compiler?
>
>Its all shades of grey. You seem to be getting very worked up about it.
>As I said, most people consider a compiler as something that translates source
>code to machine code and writes it to a file.
>
>>>Why, whats the difference? Your definition seems to be any program that can
>>>translate from one language to another.
>>
>>If you can't see that yourself, then you're either ignorant or
>>obstinant. Take your pick.
>
>So you can't argue the failure of your logic then. Noted.
>
>>>Yes, they're entirely analoguous.
>>>
>>>https://docs.oracle.com/cd/E11882_01/appdev.112/e10825/pc_02prc.htm
>>
>>Nah, not really.
>
>Oh nice counter arguement, you really sold your POV there.
>
>>>Who cares about the current state? Has nothing to do with this discussion.
>>
>>In other words, "I don't have an argument, so I'll just lamely
>>try to define things until I'm right."
>
>Im just defining things the way most people see it, not some ivory tower
>academics. Anyway, lifes too short for the rest.
>
>[tl;dr]
>
>>>that a compiler is pretty much any program which translates from one thing to
>>>another.
>>
>>No. It translates one computer _language_ to another computer
>>_language_. In the usual case, that's from a textual source
>
>Machine code isn't a language. Fallen at the first hurdle with that
>definition.
>
>

Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Summary:
Expires:
References: <uu54la$3su5b$6@dont-email.me> <vegmul$ne3v$1@dont-email.me> <vegp1r$oqh$1@reader1.panix.com> <vegqu5$o3ve$1@dont-email.me>
Sender:
Followup-To:
Distribution:
Organization:
Keywords:
Cc:

In article <vegqu5$o3ve$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>On Sun, 13 Oct 2024 15:30:03 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>>In article <vegmul$ne3v$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>>>So what is standard terminology then?
>>
>>I've already explained this to you.
>
>No you haven't. You explanation seems to be "anything that converts from one
>language to another".

The context of this specific quote, which you snipped, was your
insistence on the meaning of the term, "standalone binary."
There are a number of common terms for what you are describing,
which is the general term for the executable output artifact
from a software build, none of which is "standalone binary".

Common terms are "executable" or "executable file" (that's what
the ELF standard calls it, for instance), but also "binary",
"image", etc.

>>>What happens inside the CPU is irrelevant. Its a black box as far as the
>>>rest of the machine is concerned. As I said in another post, it could be
>>>pixies with abacuses, doesn't matter.
>>
>>So why do you think it's so important that the definition of a
>
>Who said its important? Its just what most people think of as compilers.

Well, you seem to think it's rather important.

>>CPU"? If, as you admit, what the CPU does is highly variable,
>>then why do you cling so hard to this meaningless distinction?
>
>You're the one making a big fuss about it with pages of waffle to back up
>your claim.

I just don't like misinformation floating around unchallenged.

You have cited nothing to back up your claims.

>>>So its incomplete and has to revert to software for some opcodes. Great.
>>>FWIW Sun also had a java processor but you still can't run bytecode on
>>>normal hardware without a JVM.
>>
>>Cool. So if I run a program targetting a newer version of an
>>ISA is run on an older machine, and that machine lacks a newer
>>instruction present in the program, and the CPU generates an
>>illegal instruction trap at runtime that the OS catches and
>>emulates on the program's behalf, the program was not compiled?
>>
>>And again, what about an emulator for a CPU running on a
>>different CPU? I can boot 7th Edition Unix on a PDP-11
>>emulator on my workstation; does that mean that the 7the
>>edition C compiler wasn't a compiler?
>
>Its all shades of grey. You seem to be getting very worked up about it.

Nah, I don't really care, aside from not wanting misinformation
to stand unchallenged.

>As I said, most people consider a compiler as something that translates source
>code to machine code and writes it to a file.

Sure, if you're talking informally and you mention "a compiler"
most people will know more or less what you're talking about.
But back in <vebffc$3n6jv$1@dont-email.me> you wrote,

|Does it produce a standalone binary as output? No, so its an
|intepreter not a compiler.

I said that was a bad distinction, to which you replied in
<vebi0j$3nhvq$1@dont-email.me>:

|A proper compiler writes a standalone binary file to disk.

Except that, well, it doesn't. Even the "proper compilers" that
you claim familiarity with basically don't do that; as I pointed
out to you, they generate object files and a driver invokes a
linker.

For that matter, the compiler itself may not even generate
object code, but rather, may generate textual assembly and let a
separate assembler pass turn _that_ into object code.

So yeah. What you've defined to be a "proper compiler" isn't
really what you seem to think that it is.

>[snip]
>>>Who cares about the current state? Has nothing to do with this discussion.
>>
>>In other words, "I don't have an argument, so I'll just lamely
>>try to define things until I'm right."
>
>Im just defining things the way most people see it, not some ivory tower
>academics. Anyway, lifes too short for the rest.

The people who create the field are the ones who get to make
the defintiions, not you.

>Machine code isn't a language. Fallen at the first hurdle with that
>definition.

Oh really? Is that why they call it "machine language"? It's
even in the dictionary with "machine code" as a synonymn:
https://www.merriam-webster.com/dictionary/machine%20language

- Dan C.

Christian Weisgerber <naddy@mips.inka.de> writes:
> On 2024-10-12, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> Indeed. As far as I know the term, an interpreter is something which
>> reads text from a file, parses it an checks it for syntax errors
>> and then executes the code as soon as enough of it has been gathered to
>> allow for execution of something, ie, a complete statement. This read,
>> check and parse, execute cycle is repeated until the program
>> terminates.
>
> I don't really want to participate in this discussion, but what
> you're saying there is that all those 1980s home computer BASIC
> interpreters, which read and tokenized a program before execution,
> were actually compilers.

If they contained something which compiled all of the source code prior
to execution in order to transform it some actually executable
intermediate representation whose execution didn't require future access
to the source code and thus, also didn't include checking the source
code for syntactical correctness, this something can be called a
compiler and the execution engine some sort of virtual machine which
could principally execute programs compiled from source code in any
programming language.

But judging from Wikipedia, Murkysoft Basic stored programs as linked
list of preprocessed lines and interpreted these, ie, doing string
lookups of keywords from the source code at run time in order to
determine what code to execute. Insofar I vaguely remember this from
Apple //c BASIC (has been a while) syntax errors would also be found at
runtime, ie, once execution reached the line with the error. This would
make it an interpreter.

In constrast to this, this somewhat amusing small Perl program:

while (<>) {
while (length) {
s/^(\w+)// and print(scalar reverse($1));
s/^(\W+)// and print($1);
}
}

[reads lines from stdin and prints them with each word reversed]

gets translated into an op tree whose textual representation (perl
-MO=Concise,-basic) looks like
this:

y <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter v ->2
2 <;> nextstate(main 1 a.pl:1) v:{ ->3
x <2> leaveloop vKP/2 ->y
3 <{> enterloop(next->r last->x redo->4) v ->s
- <1> null vK/1 ->x
w <|> and(other->4) vK/1 ->x
v <1> defined sK/1 ->w
- <1> null sK/2 ->v
- <1> ex-rv2sv sKRM*/1 ->t
s <#> gvsv[*_] s ->t
u <1> readline[t2] sKS/1 ->v
t <#> gv[*ARGV] s ->u
- <@> lineseq vKP ->-
4 <;> nextstate(main 3 a.pl:2) v:{ ->5
q <2> leaveloop vKP/2 ->r
5 <{> enterloop(next->m last->q redo->6) v ->n
- <1> null vK/1 ->q
p <|> and(other->6) vK/1 ->q
o <1> length[t4] sK/BOOL,1 ->p
- <1> ex-rv2sv sK/1 ->o
n <#> gvsv[*_] s ->o
- <@> lineseq vKP ->-
6 <;> nextstate(main 5 a.pl:3) v:{ ->7
- <1> null vK/1 ->f
9 <|> and(other->a) vK/1 ->f
8 </> subst(/"^(\\w+)"/) sK/BOOL ->9
7 <$> const[PV ""] s ->8
e <@> print vK ->f
a <0> pushmark s ->b
- <1> scalar sK/1 ->e
d <@> reverse[t6] sK/1 ->e
b <0> pushmark s ->c
- <1> ex-rv2sv sK/1 ->d
c <#> gvsv[*1] s ->d
f <;> nextstate(main 5 a.pl:4) v:{ ->g
- <1> null vK/1 ->m
i <|> and(other->j) vK/1 ->m
h </> subst(/"^(\\W+)"/) sK/BOOL ->i
g <$> const[PV ""] s ->h
l <@> print vK ->m
j <0> pushmark s ->k
- <1> ex-rv2sv sK/1 ->l
k <#> gvsv[*1] s ->l
m <0> unstack v ->n
r <0> unstack v ->s

Each line represents a node on this tree and the names refer to builtin
'ops'. In the actual tree, they're pointers to C functions and execution
happens as preorder traversal of this tree and invoking the op functions
from the leaves to root to produce the arguments necessary for invoking
op functions residing at a higher level in this tree.

Modules for writing this internal representation to a file and loading
it back from there and even for translating it into C exist. They're
just not part of the core distribution anymore.

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.

In article <20241013093004.251@kylheku.com>,
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>On 2024-10-11, Muttley@DastartdlyHQ.org <Muttley@DastartdlyHQ.org> wrote:
>> Irrelevant. Lot of interpreters do partial compilation and the JVM does it
>> on the fly. A proper compiler writes a standalone binary file to disk.
>
>You might want to check those goalposts again. You can easily make a
>"proper compiler" which just writes a canned interpreter executable to
>disk, appending to it the program source code.

Indeed; this is what the Moscow ML compiler does.

- Dan C.

On Sun, 13 Oct 2024 08:22:53 -0000 (UTC), Muttley boring babbled:

> On Sat, 12 Oct 2024 21:25:17 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>On Sat, 12 Oct 2024 08:42:17 -0000 (UTC), Muttley boring babbled:
>>
>>> Code generated by a compiler does not require an interpreter.
>>
>>Something has to implement the rules of the “machine language”. This is
>>why we use the term “abstract machine”, to avoid having to distinguish
>>between “hardware” and “software”.
>>
>>Think: modern CPUs typically have “microcode” and “firmware” associated
>>with them. Are those “hardware” or “software”?
>
> Who cares what happens inside the CPU hardware?

Because that’s where your “software” runs.

Muttley@DastartdlyHQ.org writes:
> On Sat, 12 Oct 2024 16:39:20 +0000
> Eric Pozharski <apple.universe@posteo.net> boring babbled:
>>with <87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com> Rainer
>>Weikusat wrote:
>>> Muttley@DastartdlyHQ.org writes:
>>>> On Wed, 09 Oct 2024 22:25:05 +0100 Rainer Weikusat
>>>> <rweikusat@talktalk.net> boring babbled:
>>>>>Bozo User <anthk@disroot.org> writes:
>>>>>> On 2024-04-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>>>> On Sun, 07 Apr 2024 00:01:43 +0000, Javier wrote:
>>
>>*CUT* [ 19 lines 6 levels deep]
>>
>>>> Its syntax is also a horrific mess.
>>> Which means precisely what?
>>
>>You're arguing with Unix Haters Handbook. You've already lost.
>
> ITYF the people who dislike Perl are the ones who actually like the unix
> way of having simple daisychained tools instead of some lump of a language
> that does everything messily.

Perl is a general-purpose programming language, just like C or Java (or
Python or Javascript or Rust or $whatnot). This means it can be used to
implement anything (with some practical limitation for anything) and not
that it "does everything".

On Sun, 13 Oct 2024 08:19:16 -0000 (UTC), Muttley wrote:

> ITYF the people who dislike Perl are the ones who actually like the unix
> way of having simple daisychained tools instead of some lump of a
> language that does everything messily.

Not sure how those small tools can work without the support of much bigger
lumps like the shell, the compiler/interpreter for those tools and the
kernel itself.

On Sun, 13 Oct 2024 14:54:13 -0000 (UTC), Muttley wrote:

> What happens inside the CPU is irrelevant.

But that’s where your “software” runs.

On Sun, 13 Oct 2024 16:02:13 -0000 (UTC), Muttley wrote:

> You explanation seems to be "anything that converts from one
> language to another".

You would call that a “translator”. That term was used more in the early
days, but that’s essentially synonymous with “compiler”.

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.

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.

On Sun, 13 Oct 2024 20:15:45 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>In article <vegqu5$o3ve$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:

[tl;dr]

>The people who create the field are the ones who get to make
>the defintiions, not you.

ITYF people in the field as a whole make the definitions.

>>Machine code isn't a language. Fallen at the first hurdle with that
>>definition.
>
>Oh really? Is that why they call it "machine language"? It's
>even in the dictionary with "machine code" as a synonymn:
>https://www.merriam-webster.com/dictionary/machine%20language

Its not a programming language.

On Sun, 13 Oct 2024 21:33:56 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>Muttley@DastartdlyHQ.org writes:
>> ITYF the people who dislike Perl are the ones who actually like the unix
>> way of having simple daisychained tools instead of some lump of a language
>> that does everything messily.
>
>Perl is a general-purpose programming language, just like C or Java (or
>Python or Javascript or Rust or $whatnot). This means it can be used to
>implement anything (with some practical limitation for anything) and not
>that it "does everything".

I can be , but generally isn't. Its niche tends to be text processing of
some sort and for that there are better tools IMO. It used to be big in web
backend but those days are long gone.

Muttley@DastartdlyHQ.org writes:
> On Sun, 13 Oct 2024 21:33:56 +0100
> Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>>Muttley@DastartdlyHQ.org writes:
>>> ITYF the people who dislike Perl are the ones who actually like the unix
>>> way of having simple daisychained tools instead of some lump of a language
>>> that does everything messily.
>>
>>Perl is a general-purpose programming language, just like C or Java (or
>>Python or Javascript or Rust or $whatnot). This means it can be used to
>>implement anything (with some practical limitation for anything) and not
>>that it "does everything".
>
> I can be , but generally isn't. Its niche tends to be text processing of
> some sort

It is. That sysadmin-types using it don't use it to create actual
programs is of no concern for this, because they never do that and this
use only needs a very small subset of the features of the language. I've
been using it as system programming language for programs with up to
21,000 LOC in the main program (and some more thousands in auxiliary
modules) and it's very well-suited to that.

The simple but flexible OO system, reliable automatic memory management
and support for functions/ subroutine as first-class objects make it
very nice for implementing event-driven, asynchronous "crossbar"
programs connecting various external entities both running locallly and
on other computers on the internet to create complex applications from
them.

On Mon, 14 Oct 2024 11:38:29 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>The simple but flexible OO system, reliable automatic memory management

For a certain definition of OO. The requirement to have to use $self->
everywhere to denote object method/var access makes it little better than
doing OO in C. Then there's the whole 2 stage object creation with the "bless"
nonsense. Hacky.

In article <veiki1$14g6h$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>On Sun, 13 Oct 2024 20:15:45 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>>Oh really? Is that why they call it "machine language"? It's
>>even in the dictionary with "machine code" as a synonymn:
>>https://www.merriam-webster.com/dictionary/machine%20language
>
>Its not a programming language.

That's news to those people who have, and sometimes still do,
write programs in it.

But that's not important. If we go back and look at what I
wrote that you were responding to, it was this statement, about
what a compiler does, and your claim that I was asserting it
was translating anything to anything, which I was not:

|No. It translates one computer _language_ to another computer
|_language_. In the usual case, that's from a textual source

Note that I said, "computer language", not "programming
language". Being a human-readable language is not a requirement
for a computer language.

Your claim that "machine language" is not a "language" is simply
not true. Your claim that a "proper" compiler must take the
shape you are pushing is also not true.

- Dan C.

On Mon, 14 Oct 2024 13:38:04 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>In article <veiki1$14g6h$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>>On Sun, 13 Oct 2024 20:15:45 -0000 (UTC)
>>cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>>>Oh really? Is that why they call it "machine language"? It's
>>>even in the dictionary with "machine code" as a synonymn:
>>>https://www.merriam-webster.com/dictionary/machine%20language
>>
>>Its not a programming language.
>
>That's news to those people who have, and sometimes still do,
>write programs in it.

Really? So if its a language you'll be able to understand this then:

0011101011010101010001110101010010110110001110010100101001010100
0101001010010010100101010111001010100110100111010101010101010101
0001110100011101010001001010110011100010101001110010100101100010

>But that's not important. If we go back and look at what I

Oh right.

>
>|No. It translates one computer _language_ to another computer
>|_language_. In the usual case, that's from a textual source
>
>Note that I said, "computer language", not "programming
>language". Being a human-readable language is not a requirement
>for a computer language.

Oh watch those goalpost moves with pedant set to 11. Presumably you
think the values of the address lines is a language too.

>Your claim that "machine language" is not a "language" is simply
>not true. Your claim that a "proper" compiler must take the
>shape you are pushing is also not true.

If you say so.

Muttley@DastartdlyHQ.org writes:
>On Mon, 14 Oct 2024 13:38:04 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>>In article <veiki1$14g6h$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>>>On Sun, 13 Oct 2024 20:15:45 -0000 (UTC)
>>>cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>>>>Oh really? Is that why they call it "machine language"? It's
>>>>even in the dictionary with "machine code" as a synonymn:
>>>>https://www.merriam-webster.com/dictionary/machine%20language
>>>
>>>Its not a programming language.
>>
>>That's news to those people who have, and sometimes still do,
>>write programs in it.
>
>Really? So if its a language you'll be able to understand this then:
>
>0011101011010101010001110101010010110110001110010100101001010100
>0101001010010010100101010111001010100110100111010101010101010101
>0001110100011101010001001010110011100010101001110010100101100010

I certainly understand this, even four decades later

94A605440C00010200010400000110

Muttley@DastartdlyHQ.org writes:
> On Mon, 14 Oct 2024 11:38:29 +0100
> Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>>The simple but flexible OO system, reliable automatic memory management

[...]

> Then there's the whole 2 stage object creation with the "bless"
> nonsense. Hacky.

I was planning to write a longer reply but killed it. You're obviously
argueing about something you reject for political reasons despite you're
not really familiar with it and you even 'argue' like a politician. That
is, you stick peiorative labels on stuff you don't like to emphasize how
really disagreeable you believe it to be. IMHO, such a method of
(pseudo-)discussing anything is completely pointless.

On 14/10/2024 16:53, Scott Lurndal wrote:
> Muttley@DastartdlyHQ.org writes:
>> On Mon, 14 Oct 2024 13:38:04 -0000 (UTC)
>> cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>>> In article <veiki1$14g6h$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>>>> On Sun, 13 Oct 2024 20:15:45 -0000 (UTC)
>>>> cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>>>>> Oh really? Is that why they call it "machine language"? It's
>>>>> even in the dictionary with "machine code" as a synonymn:
>>>>> https://www.merriam-webster.com/dictionary/machine%20language
>>>>
>>>> Its not a programming language.
>>>
>>> That's news to those people who have, and sometimes still do,
>>> write programs in it.
>>
>> Really? So if its a language you'll be able to understand this then:
>>
>> 0011101011010101010001110101010010110110001110010100101001010100
>> 0101001010010010100101010111001010100110100111010101010101010101
>> 0001110100011101010001001010110011100010101001110010100101100010
>
> I certainly understand this, even four decades later
>
> 94A605440C00010200010400000110
>

In my early days of assembly programming on my ZX Spectrum, I would
hand-assembly to machine code, and I knew at least a few of the codes by
heart. (01 is "ld bc, #xxxx", 18 is "jr", c9 is "ret", etc.) So while
I rarely wrote machine code directly, it is certainly still a
programming language - it's a language you can write programs in.