Muttley@DastartdlyHQ.org writes:
> Rainer Weikusat <rweikusat@talktalk.net> boring babbled:

[...]

>>Eg, this a poor man's implementation of cat:
>>
>>perl -e 'open($fh, $_) and print <$fh> for @ARGV'
>
> Meanwhile in awk: { print }

perl -peZ

It's not only shorter than the awk version but it also works. cat
doesn't abort when some of its arguments don't name existin files.

On Fri, 11 Oct 2024 15:15:57 -0000 (UTC), Muttley wrote:

> On Fri, 11 Oct 2024 15:47:06 +0100
> Rainer Weikusat <rweikusat@talktalk.net>:
>
>>The Perl compiler turns Perl source code into a set of (that's a
>
> Does it produce a standalone binary as output? No, so its an intepreter
> not a compiler.

There are two parts: the interpreter interprets code generated by the compiler.

Remember, your CPU is an interpreter, too.

On Fri, 11 Oct 2024 16:28:03 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>In article <vebi0j$3nhvq$1@dont-email.me>, <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.
>
>Not generally, no. Most compilers these days generate object
>code and then, as a separate step, a linker is invoked to
>combine object files and library archives into an executable
>binary.

Ok, the compiler toolchain then. Most people invoke it using a single command,
the rest is behind the scenes.

>By the way, when many people talk about a "standalone" binary,
>they are referring to something directly executable on hardware,

For many read a tiny minority.

>without the benefit of an operating system. The Unix kernel is
>an example of such a "standalone binary."

If you're going to nitpick then I'm afraid you're wrong. Almost all operating
systems require some kind of bootloader and/or BIOS combination to start them
up. You can't just point the CPU at the first byte of the binary and off it
goes particularly in the case of Linux where the kernel requires decompressing
first.

>Most executable binaries are not standalone.

Standalone as you are well aware in the sense of doesn't require an interpreter
or VM to run on the OS and contains CPU machine code.

>>>Saving to some sort of object image is not a necessary function
>>>of a compiler.
>>
>>Yes it is.
>
>So you say, but that's not the commonly accepted definition.
>Sorry.

Where do you get this commonly accepted definition from?

On Fri, 11 Oct 2024 19:01:27 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>Muttley@DastartdlyHQ.org writes:
>> On Fri, 11 Oct 2024 15:47:06 +0100
>> Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
>>>Bart <bc@freeuk.com> writes:
>>>> Interpreter? Perl has some kind of compiler in it, right?
>>>
>>>The Perl compiler turns Perl source code into a set of (that's a
>>
>> Does it produce a standalone binary as output? No, so its an intepreter
>> not a compiler. However unlike the python interpreter its non interactive
>> making it an even less attractive option these days.
>
>The perl debugger offers an interactive environment (with line editing support
>if
>the necessary packages/ modules are available). It can be invoked with a
>suitable 'script argument' to use it without actually debugging
>something, eg,
>
>perl -de 0

I didn't know about that, I stand corrected on that point.

On Fri, 11 Oct 2024 20:58:26 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> boring babbled:
>On Fri, 11 Oct 2024 15:15:57 -0000 (UTC), Muttley wrote:
>
>> On Fri, 11 Oct 2024 15:47:06 +0100
>> Rainer Weikusat <rweikusat@talktalk.net>:
>>
>>>The Perl compiler turns Perl source code into a set of (that's a
>>
>> Does it produce a standalone binary as output? No, so its an intepreter
>> not a compiler.
>
>There are two parts: the interpreter interprets code generated by the compiler.

Code generated by a compiler does not require an interpreter.

>
>
>Remember, your CPU is an interpreter, too.

If you want to go down the reductio ad absurdum route then the electrons
are interpreters too.

Muttley@DastartdlyHQ.org writes:
> On Fri, 11 Oct 2024 20:58:26 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> boring babbled:
>>On Fri, 11 Oct 2024 15:15:57 -0000 (UTC), Muttley wrote:
>>
>>> On Fri, 11 Oct 2024 15:47:06 +0100
>>> Rainer Weikusat <rweikusat@talktalk.net>:
>>>
>>>>The Perl compiler turns Perl source code into a set of (that's a
>>>
>>> Does it produce a standalone binary as output? No, so its an intepreter
>>> not a compiler.
>>
>>There are two parts: the interpreter interprets code generated by the compiler.
>
> Code generated by a compiler does not require an interpreter.

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.

Example for this:

[rw@doppelsaurus]/tmp#cat a.sh
ed a.sh <<'TT' >/dev/null 2>&1
9,$d
wq
TT
echo `expr $i + 0`
i=`expr $i + 1`
test $i = 11 && exit
sed -n '5,8p' a.sh | tee -a a.sh >/dev/null

This is a script printing the numbers from 0 to 10 by exploiting
the property that /bin/sh is an interpeter.

In contrast to this, a compiler reads the source code completely, parses
and checks it and then transforms it into some sort of "other
representation" which can be executed without dealing with the source
code (text) again. Eg, the Java compiler transforms Java source code
into Java bytecode which is then usually executed by the jvm. OTOH,
processors capable of executing Java bytecode directly exit or at least
used to exist. ARM CPUs once had an extension for that (Jazelle).

In article <vedcjc$3mqn$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>On Fri, 11 Oct 2024 16:28:03 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>>In article <vebi0j$3nhvq$1@dont-email.me>, <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.
>>
>>Not generally, no. Most compilers these days generate object
>>code and then, as a separate step, a linker is invoked to
>>combine object files and library archives into an executable
>>binary.
>
>Ok, the compiler toolchain then. Most people invoke it using a single command,
>the rest is behind the scenes.
>
>>By the way, when many people talk about a "standalone" binary,
>>they are referring to something directly executable on hardware,
>
>For many read a tiny minority.
>
>>without the benefit of an operating system. The Unix kernel is
>>an example of such a "standalone binary."
>
>If you're going to nitpick then I'm afraid you're wrong. Almost all operating
>systems require some kind of bootloader and/or BIOS combination to start them
>up. You can't just point the CPU at the first byte of the binary and off it
>goes particularly in the case of Linux where the kernel requires decompressing
>first.

Again, not generally, no. Consider an embedded system where the
program to be executed on, say, a microcontroller is itself
statically linked at an absolute address and burned into a ROM,
with the program's entry point at the CPU's reset address. I
suppose that's not "standalone" if you count a ROM burner as
part of "loading" it.

Also, I mentioned Unix, not Linux. The two are different. The
first version of the Unix kernel started at a fixed location on
the PDP-7, without a separate loading step (Ken Thompson did
that manually).

Of course, this all gets more complex when we start talking
about modern systems with loading kernel modules and the like.

>>Most executable binaries are not standalone.
>
>Standalone as you are well aware in the sense of doesn't require an interpreter
>or VM to run on the OS and contains CPU machine code.

So what about a binary that is dynamically linked with a shared
object? That requires a runtime interpreter nee linker to bind
its constituent parts together before it's executable. And what
if it makes a system call? Then it's no longer "standalone", as
it necessarily relies on the operating system to perform part of
its function.

But that's really neither here nor there; I think you are
conflating object code with text containing instructions meant
for direct execution on a CPU with something like a P-code;
the distinction is kind of silly when you consider that we live
in a world with CPU simulators that let you boot entire systems
for architecture A in a program running on architecture B,
usually in userspace. Why do you think that a compiler that
generates bytecode for some virtual machine is any different
from a compiler that generates object code for some CPU?

You don't seem to be able to recognize that the compilation step
is separate from execution, and that the same techniques for
compiler development apply to both hardware and virtual targets.

>>>>Saving to some sort of object image is not a necessary function
>>>>of a compiler.
>>>
>>>Yes it is.
>>
>>So you say, but that's not the commonly accepted definition.
>>Sorry.
>
>Where do you get this commonly accepted definition from?

*shrug* Tanenbaum; Silberschatz; Kaashoek; Roscoe; etc. Where
did you get your definition?

- Dan C.

On Sat, 12 Oct 2024 13:53:56 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
>In article <vedcjc$3mqn$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>>up. You can't just point the CPU at the first byte of the binary and off it
>>goes particularly in the case of Linux where the kernel requires decompressing
>
>>first.
>
>Again, not generally, no. Consider an embedded system where the
>program to be executed on, say, a microcontroller is itself
>statically linked at an absolute address and burned into a ROM,

Unlikely to be running *nix in that case.

>with the program's entry point at the CPU's reset address. I
>suppose that's not "standalone" if you count a ROM burner as
>part of "loading" it.

Now you're just being silly.

>Also, I mentioned Unix, not Linux. The two are different. The

Are they? Thats debatable these days. I'd say Linux is a lot closer to
the philosphy of BSD and SYS-V than MacOS which is a certified unix.

>>Standalone as you are well aware in the sense of doesn't require an
>interpreter
>>or VM to run on the OS and contains CPU machine code.
>
>So what about a binary that is dynamically linked with a shared
>object? That requires a runtime interpreter nee linker to bind
>its constituent parts together before it's executable. And what
>if it makes a system call? Then it's no longer "standalone", as
>it necessarily relies on the operating system to perform part of
>its function.

Standalone in the sense that the opcodes in the binary don't need to be
transformed into something else before being loaded by the CPU.

>usually in userspace. Why do you think that a compiler that
>generates bytecode for some virtual machine is any different
>from a compiler that generates object code for some CPU?

I'd say its a grey area because it isn't full compilation is it, the p-code
still requires an interpreter before it'll run.

>You don't seem to be able to recognize that the compilation step

Compiling is not the same as converting. Is a javascript to C converter a
compiler? By your definition it is.

>>Where do you get this commonly accepted definition from?
>
>*shrug* Tanenbaum; Silberschatz; Kaashoek; Roscoe; etc. Where
>did you get your definition?

Only heard of one of them so mostly irrelevant. Mine come from the name of
tools that compile code to a runnable binary.

Muttley@dastardlyhq.com writes:
>On Sat, 12 Oct 2024 13:53:56 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
>>In article <vedcjc$3mqn$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>>>up. You can't just point the CPU at the first byte of the binary and off it
>>>goes particularly in the case of Linux where the kernel requires decompressing
>>
>>>first.
>>
>>Again, not generally, no. Consider an embedded system where the
>>program to be executed on, say, a microcontroller is itself
>>statically linked at an absolute address and burned into a ROM,
>
>Unlikely to be running *nix in that case.

Some do, some don't. Many run zephyr, others various
commercial embedded RTOS. In any case, they're binaries
and if properly created, one simply points the cpu to the
first byte of the binary (or more likely some standard
PC value that the processor starts fetching from when
it leaves reset, e.g. the VTOR on Cortex-m7 cores) and off it goes.

>>So what about a binary that is dynamically linked with a shared
>>object? That requires a runtime interpreter nee linker to bind
>>its constituent parts together before it's executable. And what
>>if it makes a system call? Then it's no longer "standalone", as
>>it necessarily relies on the operating system to perform part of
>>its function.
>
>Standalone in the sense that the opcodes in the binary don't need to be
>transformed into something else before being loaded by the CPU.

That's a rather unique definition of 'standalone'.

On Sat, 12 Oct 2024 15:32:28 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
>Muttley@dastardlyhq.com writes:
>>Standalone in the sense that the opcodes in the binary don't need to be
>>transformed into something else before being loaded by the CPU.
>
>That's a rather unique definition of 'standalone'.

Is it? As opposed to something that requires a seperate program to run any
of it. That java p-code isn't going to do much without a jvm to translate it
into x86 or ARM etc whereas a compiled binary will - after required libraries
are loaded with it - just run directly on the CPU.

In article <vee2b1$6vup$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>On Sat, 12 Oct 2024 13:53:56 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
>>In article <vedcjc$3mqn$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>>>up. You can't just point the CPU at the first byte of the binary and off it
>>>goes particularly in the case of Linux where the kernel requires decompressing
>>
>>>first.
>>
>>Again, not generally, no. Consider an embedded system where the
>>program to be executed on, say, a microcontroller is itself
>>statically linked at an absolute address and burned into a ROM,
>
>Unlikely to be running *nix in that case.

We're discussing the concept of a "standalone binary"; you seem
to think that means a binary image emitted by a linker and meant
to run under a hosted environment, like an operating system. It
does not.

>>with the program's entry point at the CPU's reset address. I
>>suppose that's not "standalone" if you count a ROM burner as
>>part of "loading" it.
>
>Now you're just being silly.

*shrug* Not my problem if you haven't dealt with many embedded
systems.

>>Also, I mentioned Unix, not Linux. The two are different. The
>
>Are they? Thats debatable these days. I'd say Linux is a lot closer to
>the philosphy of BSD and SYS-V than MacOS which is a certified unix.

Yes, they are.

>>>Standalone as you are well aware in the sense of doesn't require an
>>interpreter
>>>or VM to run on the OS and contains CPU machine code.
>>
>>So what about a binary that is dynamically linked with a shared
>>object? That requires a runtime interpreter nee linker to bind
>>its constituent parts together before it's executable. And what
>>if it makes a system call? Then it's no longer "standalone", as
>>it necessarily relies on the operating system to perform part of
>>its function.
>
>Standalone in the sense that the opcodes in the binary don't need to be
>transformed into something else before being loaded by the CPU.

Yeah, no, that's not what anybody serious means when they say
that.

>>usually in userspace. Why do you think that a compiler that
>>generates bytecode for some virtual machine is any different
>>from a compiler that generates object code for some CPU?
>
>I'd say its a grey area because it isn't full compilation is it, the p-code
>still requires an interpreter before it'll run.

Nope.

>>You don't seem to be able to recognize that the compilation step
>
>Compiling is not the same as converting. Is a javascript to C converter a
>compiler? By your definition it is.

Yes, of course it is. So is the terminfo compiler, and any
number of other similar things. The first C++ compiler, cfront
emitted C code, not object code. Was it not a compiler?

>>>Where do you get this commonly accepted definition from?
>>
>>*shrug* Tanenbaum; Silberschatz; Kaashoek; Roscoe; etc. Where
>>did you get your definition?
>
>Only heard of one of them so mostly irrelevant. Mine come from the name of
>tools that compile code to a runnable binary.

It's very odd that you seek to speak from a position of
authority when you don't even know who most of the major people
in the field are.

- Dan C.

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.

*CUT* [ 8 lines 2 levels deep]

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

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.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

On 12/10/2024 14:37, Rainer Weikusat wrote:
> Muttley@DastartdlyHQ.org writes:
>> On Fri, 11 Oct 2024 20:58:26 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> boring babbled:
>>> On Fri, 11 Oct 2024 15:15:57 -0000 (UTC), Muttley wrote:
>>>
>>>> On Fri, 11 Oct 2024 15:47:06 +0100
>>>> Rainer Weikusat <rweikusat@talktalk.net>:
>>>>
>>>>> The Perl compiler turns Perl source code into a set of (that's a
>>>>
>>>> Does it produce a standalone binary as output? No, so its an intepreter
>>>> not a compiler.
>>>
>>> There are two parts: the interpreter interprets code generated by the compiler.
>>
>> Code generated by a compiler does not require an interpreter.
>
> 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.

That would be some very old BASIC, or maybe a shell program where the
input is a stream of lines, and each must be executed when they were
entered (you'd never reach end-of-file otherwise!).

Most interpreters taking input from a file will compile the whole thing
to some intermediate form first (eg. to internal bytecode). Then it will
interpret that bytecode.

Otherwise they would be hoplessly slow.

> In contrast to this, a compiler reads the source code completely, parses
> and checks it and then transforms it into some sort of "other
> representation" which can be executed without dealing with the source
> code (text) again.

Some compilers (eg. the ones I write) can run programs from source just
like an interpreted language. The difference here is that it first
translates the whole program to native code rather than bytecode.

Then there are more complicated schemes which mix things up: they start
off interpreting and turn 'hot' paths into native code via JIT techniques.

On Sat, 12 Oct 2024 08:42:17 -0000 (UTC), Muttley wrote:

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

> If you want to go down the reductio ad absurdum route then the electrons
> are interpreters too.

<https://www.americanscientist.org/article/the-computational-universe>
<https://en.wikipedia.org/wiki/Digital_physics>

On Sat, 12 Oct 2024 16:36:26 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>In article <vee2b1$6vup$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>>Unlikely to be running *nix in that case.
>
>We're discussing the concept of a "standalone binary"; you seem
>to think that means a binary image emitted by a linker and meant
>to run under a hosted environment, like an operating system. It
>does not.

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.

>>Now you're just being silly.
>
>*shrug* Not my problem if you haven't dealt with many embedded
>systems.

I could bore you with the number I've actually "dealt with" including
military hardware but whats the point. You've probably programmed the
occasional PIC or arduino and think you're an expert.

>>Are they? Thats debatable these days. I'd say Linux is a lot closer to
>>the philosphy of BSD and SYS-V than MacOS which is a certified unix.
>
>Yes, they are.

I disagree. Modern linux reminds me a lot of SunOS and HP-UX from back in
the day. Not something that can be said for MacOS with its role-our-own
Apple specific way of doing pretty much everything.

>>Standalone in the sense that the opcodes in the binary don't need to be
>>transformed into something else before being loaded by the CPU.
>
>Yeah, no, that's not what anybody serious means when they say
>that.

Anybody serious presumably meaning you.

>>I'd say its a grey area because it isn't full compilation is it, the p-code
>>still requires an interpreter before it'll run.
>
>Nope.

Really? So java bytecode will run direct on x86 or ARM will it? Please give
some links to this astounding discovery you've made.

>>Compiling is not the same as converting. Is a javascript to C converter a
>>compiler? By your definition it is.
>
>Yes, of course it is. So is the terminfo compiler, and any

So in your mind google translate is a "compiler" for spoken languages is it?

>number of other similar things. The first C++ compiler, cfront
>emitted C code, not object code. Was it not a compiler?

No, it was a pre-compiler. Just like Oracles PRO*C/C++.

>>Only heard of one of them so mostly irrelevant. Mine come from the name of
>>tools that compile code to a runnable binary.
>
>It's very odd that you seek to speak from a position of
>authority when you don't even know who most of the major people
>in the field are.

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.

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.

On Sat, 12 Oct 2024 17:49:15 -0000 (UTC)
Christian Weisgerber <naddy@mips.inka.de> boring babbled:
>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.

He's painted himself into a corner. Will be interesting to see how gets
out of it.

On Sat, 12 Oct 2024 21:25:17 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> boring babbled:
>On Sat, 12 Oct 2024 08:42:17 -0000 (UTC), Muttley wrote:
>
>> 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? It could be a group of pixies
with abacuses for all the relevance it has to this argument. Standalone
binaries contain machine code that can be directly executed by the CPU.

>> If you want to go down the reductio ad absurdum route then the electrons
>> are interpreters too.
>
><https://www.americanscientist.org/article/the-computational-universe>
><https://en.wikipedia.org/wiki/Digital_physics>

Thats heading off into philosphy.

On 13.10.2024 10:19, Muttley@DastartdlyHQ.org wrote:
> On Sat, 12 Oct 2024 16:39:20 +0000
> Eric Pozharski <apple.universe@posteo.net> boring babbled:
>> [...]
>>
>> 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.

(I think some topics in this black-or-white mix should be sorted.)

The pipelining mechanisms - if you meant that with "daisychained
tools" - has its limitations. For simple filtering it's okay, but
once you need some information from the front of the processing
chain at the end of the chain solutions can get very clumsy, may
create logical problems, race conditions, etc. Being able to
memorize some information from the pipe-front processes to be used
later is one inherent advantage of using a [scripting-]language
like Perl, Awk, or whatever. (Personally I prefer a language like
Awk because it's simple and has a clear syntax as opposed to Perl,
but I understand that other folks might prefer Perl or Python.)

Janis

In article <vefvo0$k1mm$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
>On Sat, 12 Oct 2024 16:36:26 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>>In article <vee2b1$6vup$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>>>Unlikely to be running *nix in that case.
>>
>>We're discussing the concept of a "standalone binary"; you seem
>>to think that means a binary image emitted by a linker and meant
>>to run under a hosted environment, like an operating system. It
>>does not.
>
>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
term "standalone binary" to describe one other people might call
"statically" linked", but you seem to mean any binary that comes
out of say, invoking the `gcc` or `clang` driver and getting an
executable object image. And in context, you seem to mean that
a "compiler" is a program that _only_ generates such artifacts,
but that's nonsense, and in fact, many compilers simply don't
work that way. Even LLVM might generate an intermediate
language, that is then in turn processed to generate object code
for some particular target; that target might be an ISA for
which physical silicon exists, or it might not.

Consider, for example, the MMIX CPU designed by Knuth; a
compiler may generate code for that, even though there is no CPU
implementing the MMIX instruction set that I can pop on down to
Microcenter and buy. Does that make that compiler less of a
compiler? Or, keeping with the theme of MMIX, I'll bet someone
has done an HDL implementation of it suitable for loading into
and running on an FPGA; so is a compiler targeting it now a
real compiler?

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
about a compiler like LLVM that can target multiple backends,
some of which may not actually be hardware (like, say, eBPF).
Is any compiler that generates an intermediate laguage not a
Real compiler, since it's not generating executable object code
directly? What about a compiler that _only_ outputs an object
file and defers to an explicitly programmer-driven seperate link
step? The Plan 9 compiler suite works that way, and indeed,
actual instruction selection is deferred to the linker.
https://9p.io/sys/doc/compiler.html

Or consider the APEX compiler for APL, which generated output as
code in the SISAL programming language; the SISAL compiler, in
turn, output either C or FORTRAN. This was actually quite
useful; APL is great at very high-level optimizations ("multiply
these matrices this way..."), SISAL was great a medium-level
inter-procedural optimizations, and of course the system C and
FORTRAN compilers excel at low-level register-level
optimization. The effect was a program that was highly
optimized when finally distilled down into an executable image.
To assert that these weren't compilers is inane.

>>>Now you're just being silly.
>>
>>*shrug* Not my problem if you haven't dealt with many embedded
>>systems.
>
>I could bore you with the number I've actually "dealt with" including
>military hardware but whats the point.

Weird appeals to experience, with vague and unsupported claims,
aren't terribly convincing.

>You've probably programmed the
>occasional PIC or arduino and think you're an expert.

Ok, Internet Guy.

>>>Are they? Thats debatable these days. I'd say Linux is a lot closer to
>>>the philosphy of BSD and SYS-V than MacOS which is a certified unix.
>>
>>Yes, they are.
>
>I disagree. Modern linux reminds me a lot of SunOS and HP-UX from back in
>the day.

Then I can only guess that you never used either SunOS or HP-UX.

>Not something that can be said for MacOS with its role-our-own
>Apple specific way of doing pretty much everything.

Well, since we're talking about "standalone binaries" and my
example was the Unix kernel, I should confess that I was really
thinking more like the Unix kernel, or perhaps the standalone
installation program that came on the V7 tape.

>>>Standalone in the sense that the opcodes in the binary don't need to be
>>>transformed into something else before being loaded by the CPU.
>>
>>Yeah, no, that's not what anybody serious means when they say
>>that.
>
>Anybody serious presumably meaning you.

Sorry, you've shown no evidence why I should believe your
assertions, and you've ignored directly disconfirming evidence
showing that those assertions don't hold generally. If you want
to define the concept of a "compiler" to be what you've narrowly
defined it to be, you'll just have to accept that you're in very
short company and people aren't going to take you particularly
seriously.

>>>I'd say its a grey area because it isn't full compilation is it, the p-code
>>>still requires an interpreter before it'll run.
>>
>>Nope.
>
>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

Again, I bring up my earlier example of a CPU simulator.

>>>Compiling is not the same as converting. Is a javascript to C converter a
>>>compiler? By your definition it is.
>>
>>Yes, of course it is. So is the terminfo compiler, and any
>
>So in your mind google translate is a "compiler" for spoken languages is it?

To quote you above, "now you're just being silly."

>>number of other similar things. The first C++ compiler, cfront
>>emitted C code, not object code. Was it not a compiler?
>
>No, it was a pre-compiler. Just like Oracles PRO*C/C++.

Nope.

>>>Only heard of one of them so mostly irrelevant. Mine come from the name of
>>>tools that compile code to a runnable binary.
>>
>>It's very odd that you seek to speak from a position of
>>authority when you don't even know who most of the major people
>>in the field are.
>
>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.

In that case, let's just take a look at an authoritative source
and see what it says. From Chapter 1, "Introduction to
Compiling", section 1.1 "Compilers", first sentence of
"Compilers: Principles, Techniques, and Tools" (1st Edition) by
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."

In the second paragraph, those authors go on to say, "...a
target language may be another programming language, or the
machine language of any computer".

Note "any computer", could also be a kind of virtual machine.
And of course, if the target langauge is another programming
language, that already covers what is under discussion here.

So it would seem that your definition is not shared by those who
quite literally wrote the book on compilers.

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.
But as usual, in its full generality, the world is just messier
than whatever conceptual boxes you've built up here.

- Dan C.

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?

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

[lots of waffle snipped]

>>I could bore you with the number I've actually "dealt with" including
>>military hardware but whats the point.
>
>Weird appeals to experience, with vague and unsupported claims,
>aren't terribly convincing.

So its ok for you to do that but nobody else?

>>You've probably programmed the
>>occasional PIC or arduino and think you're an expert.
>
>Ok, Internet Guy.

I'll take that as a yes. Btw, you're some random guy on the internet too
claiming some kind of higher experience.

>>I disagree. Modern linux reminds me a lot of SunOS and HP-UX from back in
>>the day.
>
>Then I can only guess that you never used either SunOS or HP-UX.

"I disagree with you so you must be lying". Whatever.

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

Likewise.

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

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

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

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

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

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

Muttley@DastartdlyHQ.org writes:
>On Sat, 12 Oct 2024 16:36:26 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
>>In article <vee2b1$6vup$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>>>Unlikely to be running *nix in that case.
>>

>>*shrug* Not my problem if you haven't dealt with many embedded
>>systems.
>
>I could bore you with the number I've actually "dealt with" including
>military hardware but whats the point. You've probably programmed the
>occasional PIC or arduino and think you're an expert.

Dan isn't unknown in the field of computer science, particularly
Unix and Plan 9. You, on the other hand....

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.

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.