Re: Command Languages Versus Programming Languages

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.