Re: Command Languages Versus Programming Languages

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.