Re: Command Languages Versus Programming Languages

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.