Path: ...!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Sat, 12 Oct 2024 16:36:26 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vee8ia$hkq$1@reader1.panix.com>
References: <uu54la$3su5b$6@dont-email.me> <vedcjc$3mqn$1@dont-email.me> <vedv1k$idp$1@reader1.panix.com> <vee2b1$6vup$1@dont-email.me>
Injection-Date: Sat, 12 Oct 2024 16:36:26 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="18074"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 4178
Lines: 84

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.