In article <vegmul$ne3v$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>On Sun, 13 Oct 2024 13:43:54 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>>In article <vefvo0$k1mm$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>>>On Sat, 12 Oct 2024 16:36:26 -0000 (UTC)
>>>It can mean either. Essentially its a binary that contains directly runnable
>>>CPU machine code. I'm not sure why you're having such a conceptual struggle
>>>understanding this simple concept.
>>
>>Oh, I understand what you mean; it's your choice of non-standard
>>terminology that I object to. Admittedly, Microsoft uses the
>
>So what is standard terminology then?

I've already explained this to you.

>>Or consider x86; most modern x86 processors are really dataflow
>>CPUs, and the x86 instruction encoding is just a bytecode that
>>is, in fact, interpreted by the real CPU under the hood. So
>>where does that fit on your little shrink-to-fit taxonomy? What
>
>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
compiler means, "generates object code directly runnable on a
CPU"? If, as you admit, what the CPU does is highly variable,
then why do you cling so hard to this meaningless distinction?

>[lots of waffle snipped]

In other words, you discard anything that doesn't fit with your
preconceptions. Got it.

>>Then I can only guess that you never used either SunOS or HP-UX.
>
>"I disagree with you so you must be lying". Whatever.

Way to miss the point by fixating on random details. Lawrence,
is that you?

>>Sorry, you've shown no evidence why I should believe your
>>assertions, and you've ignored directly disconfirming evidence
>
>Likewise.

I've cited evidence written by acknowledged experts in the
field; have you?

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

>>>So in your mind google translate is a "compiler" for spoken languages is it?
>>
>>To quote you above, "now you're just being silly."
>
>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.

>>>No, it was a pre-compiler. Just like Oracles PRO*C/C++.
>>
>>Nope.
>
>Yes, they're entirely analoguous.
>
>https://docs.oracle.com/cd/E11882_01/appdev.112/e10825/pc_02prc.htm

Nah, not really.

>>>I know the important ones. You've dug out some obscure names from google
>>>that probably only a few CS courses even mention never mind study the work of.
>>
>>
>>Ok, so you aren't familiar with the current state of the field
>>as far as systems go; fair enough.
>
>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."

>>Aho, Sethi, and Ullman: "Simply stated, a compiler is a program
>>that reads a program written in one language -- the _source_
>>language -- and translates it into an equivalent program in
>>another language -- the _target_ language."
>
>Thats an opinion, not a fact.
>
>>So it would seem that your definition is not shared by those who
>>quite literally wrote the book on compilers.
>
>Writing the book is not the same as writing the compilers.

Well, let's look at the words of someone who wrote the compiler,
then. Stroustrup writes in his HOPL paper on C++ that cfront
was, "my original C++ compiler". Quoted from,
https://stroustrup.com/hopl-almost-final.pdf (page 6).

>>Look, I get the desire to want to pin things down into neat
>>little categorical buckets, and if in one's own experience a
>>"compiler" has only ever meant GCC or perhaps clang (or maybe
>>Microsoft's compiler), then I can get where one is coming from.
>
>You can add a couple of TI and MPLAB compilers into that list. And obviously
>Arduinos , whatever its called. Been a while.
>
>>But as usual, in its full generality, the world is just messier
>>than whatever conceptual boxes you've built up here.
>
>There's a difference between accepting there are shades of grey and asserting
>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
language to a binary machine language, but that needn't be the
case.

- Dan C.

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

[ X-post list reduced ]

On 13.10.2024 18:02, Muttley@DastartdlyHQ.org wrote:
> On Sun, 13 Oct 2024 15:30:03 -0000 (UTC)
> cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>>> [...]
>>
>> 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.

Careful (myself included); watch out for the glazed frost!

You know there's formal definitions for what constitutes languages.

At first glance I don't see why machine code wouldn't quality as a
language (either as some specific "mnemonic" representation, or as
a sequence of integral numbers or other "code" representations).

What's the problem, in your opinion, with considering machine code
as a language?

Janis

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 Sun, 13 Oct 2024 18:28:32 +0200, Janis Papanagnou wrote:

> You know there's formal definitions for what constitutes languages.

Not really. For example, some have preferred the term “notation” instead
of “language”.

Regardless of what you call it, machine code still qualifies.

On 13.10.2024 23:10, Lawrence D'Oliveiro wrote:
> On Sun, 13 Oct 2024 18:28:32 +0200, Janis Papanagnou wrote:
>
>> You know there's formal definitions for what constitutes languages.
>
> Not really. For example, some have preferred the term “notation” instead
> of “language”.

A "notation" is not the same as a [formal (or informal)] "language".

(Frankly, I don't know where you're coming from; mind to explain your
point if you think it's relevant. - But since you wrote "_some_ have
preferred" it might anyway have been only an opinion or a historic
inaccuracy so it's probably not worth expanding on that?)

I think we should be clear about terminology.

I was speaking about [formal] languages as introduced by Chomsky and
used (and extended) by scientists (specifically computer scientists)
since then. And these formal characteristics of languages and grammars
are also the base of the books that have been mentioned and recently
quoted in this sub-thread.

> Regardless of what you call it, machine code still qualifies.

Glad you agree.

Janis

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 Mon, 14 Oct 2024 01:16:11 +0200, Janis Papanagnou wrote:

> On 13.10.2024 23:10, Lawrence D'Oliveiro wrote:
>
>> On Sun, 13 Oct 2024 18:28:32 +0200, Janis Papanagnou wrote:
>>
>>> You know there's formal definitions for what constitutes languages.
>>
>> Not really. For example, some have preferred the term “notation”
>> instead of “language”.
>
> A "notation" is not the same as a [formal (or informal)] "language".
>
> (Frankly, I don't know where you're coming from ...

<https://en.wikipedia.org/wiki/Programming_language>:

A programming language is a system of notation for writing computer
programs.

On Sun, 13 Oct 2024 18:28:32 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
>[ X-post list reduced ]
>
>On 13.10.2024 18:02, Muttley@DastartdlyHQ.org wrote:
>> On Sun, 13 Oct 2024 15:30:03 -0000 (UTC)
>> cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>>>> [...]
>>>
>>> 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.
>
>Careful (myself included); watch out for the glazed frost!
>
>You know there's formal definitions for what constitutes languages.
>
>At first glance I don't see why machine code wouldn't quality as a
>language (either as some specific "mnemonic" representation, or as
>a sequence of integral numbers or other "code" representations).
>What's the problem, in your opinion, with considering machine code
>as a language?

A programming language is an abstraction of machine instructions that is
readable by people.

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.