Re: HLA StdLib2 criticism


Herbert Kleebauer wrote:

Suppose, somebody makes some extensions to the C specification
and calls it High Level C (HLC) and then writes a program (HLC.EXE)
which converts a HLC program to a normal C program. Finally he bundles
HLC.EXE with an already existing C compiler and calls it HLC system.

Can the HLC language be called C? Because HLC is an extension to
C, any valid C program also is a valid HLC program, but this
doesn't make HLC = C.

Suppose someone creates a new language and calls it "High Level
Assembler" (HLA). And then writes a couple of programs (HLA.EXE and
HLAPARSE.EXE) that takes a source file in the HLA language and
translates it to FASM and then calls FASM to produce an object code
output. Can that person call this the "FASM language?" Of course not.
Then again, I don't see anyone doing this.


Can HLC.EXE be called a compiler? HLC.EXE converts HLC source code
to C source code, the final compilation is done by the back end C
compiler. Therefore HLC.EXE can't be called a compiler.

You don't know what you're talking about. There are lots of compilers
implemented exactly this way. Like Rene, you confuse a language with
the implementation of the language. Try posting your nonsense to
comp.compilers sometime and see how far you get with your explanation.


Can the HLC system be called a C compiler?

No, it cannot. "C" has a very standardized meaning and unless HLC
compiles unmodified C programs, you could never get away with this
claim.

OTOH, there is no standardized "assembly language." Assembly language
is a nebulous term encompassing a wide range of different languages
(indeed, across different processors). "Assembly Language" is in the
same category as "High-Level Language" for all intents and purposes. It
describes a class of languages, not a specific language. You may most
certainly refer to HLC as a high-level language, just as you can refer
to C, Pascal, C++, C#, D, Python, BASIC, and Ruby as HLLs. Likewise,
you can refer to HLA as an assembly language, just as you can refer to
FASM, NASM, MASM, TASM, Gas, and even that product of your's as
assembly languages.

No doubt, the HLC
system is a compiler which converts HLC source code to object
code (a different question is, whether the system should use
the name HLC when the most work is done by the back end C
compiler).

How do you know that "most of the work" is being done by the back-end C
compiler. In the case of HLA, I can assure you that this is *not* the
case. All the backend assembler is doing in HLA's case is producing an
object module format that is compatible with the underlying OS. Indeed,
a fair number of the instructions that HLA processes are encoding
already by the time the underlying assembler sees them (because not all
assemblers HLA produces code for support the entire x86 instruction
set). Now granted, if *your* assembler produced output for some other
assembler, that other assembler would wind up doing most of the work in
the assembly process. But you've got a rather trivial product; HLA is
just a *bit* more complex that what you're used to dealing with. And
it's a bit more complex that the underlying assemblers it uses to
process the *simplified* source code that it emits.


And because C is a subset of HLC, the HLC system
can compile any valid C program (HLC.EXE just passes the source
code unmodified to the C compiler). But this doesn't make the
HLC system a C compiler, it still is a HLC compiler which also
can compile C programs.

And that's where your analogy fails. HLA will not compile any FASM,
MASM, TASM, or Gas program. HLA is a completely different language. It
is not a superset of one of these other languages, at all. It is a
*different* language. That language happens to be classified as an
assembly language, because you have all the machine instructions
available to you.



Can the HLA language be called an assembly language?

Not only can be called an assembly language, it *is* an assembly
language.

Because
HLA is an extension to assembly language,

No, it is *not* an extension. That's like saying "C is an extension to
high-level language." Your statement makes no sense. You could claim
(incorrectly) that "HLA is an extension to the MASM language" or "HLA
is an extension to the FASM language" but you can't use the term
"assembly language" as though it described a single language. It does
not.

a valid assembly
program also is a valid HLA program, but this doesn't make
HLA an assembly language.

That statement makes no sense at all. If a valid assembly language
program (that is, the syntax of the source file corresponds to some
grammar for an assembly language) and the HLA compiler processes that
language, of course HLA is an assembly language.



Can HLC.EXE be called a compiler?

By every definition of the term, yes.


HLA.EXE converts HLA source code
to assembly source code, the final conversion is done by the back end
assembler. Therefore HLA.EXE can't be called a compiler.

GCC converts C/C++ source code to assembly source code. The final
conversion is done by the back end assembler (Gas). Therefore GCC can't
be called a compiler.

Yeah, right.



Can the HLA system be called an assembler?

It is a compiler for an assembly language. That's the only reasonable
definition I've come across. That is, it takes an assembly language
source file (in the HLA assembly language) and through magic (internal)
means, produces an object output file. What more is needed than that.

No doubt, the HLA
system is a compiler which converts HLA source code to object
code.

No doubt. And again, a compiler that accepts some sort of assembly
language input and produces object code output is called an
"assembler".


And because assembler code is a subset of HLA,

Actually, you've got it backwards. The HLA language is a subset of all
the assembly languages out there. If "assembler code" were a subset of
HLA, then HLA would be able to compile any assembly source file out
there, including MASM source code, FASM source code, IBM\360 source
code, 6502 source code, Z8 source code, and so on. Obviously, this is
not the case. Indeed, as others are quick to point out around here, the
HLA language is syntactically quite different from other (x86) assembly
languages. So there is no way you can use this "superset" or "subset"
classification.

the HLA
system can compile a valid assembly program (HLA.EXE just
does syntax transformation but otherwise passes the source code
unmodified to the back end assembler).

Actually, if you're going to talk about specific programs, HLA.EXE does
not do what you're describing at all. The HLA.EXE program is a "shell"
that runs all the other programs in the HLA package. Those other
programs include HLAPARSE.EXE, ML.EXE (or whatever), LINK.EXE (or
whatever), and RC.EXE. Surely an old-timer such as yourself can accept
the fact that a compiler needn't consist of a single executable file.


But this doesn't make
the HLA system a compiler for assembly language, it still is
a HLA compiler which also can compile assembly programs.

???
An HLA compiler compiles HLA programs. The HLA language is one of many
assembly languages, so in a very loose sense your statement is correct
(though it doesn't say anything useful). However, one could easily take
your statement to mean that HLA will compile any assembly program. This
certainly isn't the case (sorry to be redundant, but you keep making
this same mistaken claim over and over again).



Maybe next time you invent a High Level Keyboard (HLK) with
some additional keys. Then you can connect this keyboard to an
already existing PC and call it the HLK system. I don't care
about names if it is obvious for anybody what's behind this
names. But if you promote this system as a PC for teaching
students how to work with computer systems and the new keys
on your High Level Keyboard are labelled: "press to get the
solution for test1", "press to get the solution for test2",

Completely irrelevant analogy. Try again.

....., then this can't be tolerated anymore. Sure, the
students get much better exams when using this PC's, as
they get better exams when using HLA instead of an assembler, but
they didn't learn what they should have learned.

If you're trying to claim that students are learning assembly language
using HLA, then you're dead wrong. I've got the classroom experience to
back up the HLA approach. I've actually got *projects* (not exams) that
demonstrate the students have a better understanding of assembly
language when they take the course with HLA rather than MASM. What do
you have? Nothing, of course. Then again, your preferred pedagogy is to
tell people to read the manufacturer's data sheets and write their own
assembler. Obviously, you don't know the first thing about teaching
assembly language to people.


And it doesn't
help if you say, but the didn't have to press this key, they
also could have entered the solution themselves or, they didn't
have to use the HLA extensions, the also could have used the
HLA system to compile assembly code by bypassing HLA.EXE.

I guess they could manually run HLAPARSE, ML, and LINK :-)
How would that make them better assembly programmers?



No doubt, it also wouldn't be tolerateable if somebody
would convince the students that assembler is an alternative
to HLL's for writing applications.

Guess it really depends upon what type of applications we're talking
about here, right?

The big difference is,
that nobody will take somebody seriously who tries this

Oh, I'm sure *some* people around here would :-)


(so maybe you should better stop either to call HLA an assembler
or to use HLA to implement HLA2).

I'm using HLA to implement HLA v2.0 for some very good reasons that
have little to do with perceptions about assembly language's
applicability to creating large applications. Indeed, one of the main
reasons for doing so is for the same reason that is often used to argue
against using assembly language -- training. If you can't see the
issue, consider this: the largest group of people who will be
interested in playing around with HLA sources are the HLA user
community. The *one* language I can count on them knowing is HLA. Sure,
C/C++ or some other HLL might be a better choice to the software
engineering community, but there are a lot of HLA programmers who don't
know C (or don't care to use C). Ditto for Java. Ditto for *any other
language* you can come up with. HLA is the one common denominator
amongst HLA programmers. Therefore, as a software engineer, I've
chosen an assembly language (HLA) for HLA v2.0 development because that
will maximize the number of people who will be able to deal with the
source code.

There are other reasons for choosing HLA as the development language.
Amongst them is the fact that I don't want anyone playing around with
the source code to the compiler who *isn't* an accomplished HLA
programmer. It helps to know the language, at a programmer's level,
before you muck around with the compiler for that language.

As a general rule, these two reasons are why I feel almost *any*
(general-purpose) language should be implemented in itself.

Cheers,
Randy Hyde

.

Relevant Pages

  • Re: What is an assembly language?
    ... HLA is an assembler. ... So what is this essential ability of an assembly language that is ... > that Randy-HLA isn't an x86 assembler. ...
    (alt.lang.asm)
  • Re: HLA StdLib2 criticism
    ... Assembler" (HLA). ... Can that person call this the "FASM language?" ... but also of course not he can call it an assembler ... Therefore HLC.EXE can't be called a compiler. ...
    (alt.lang.asm)
  • Re: I think i finally got a definition of an Assembler!
    ... definition - you can _never_ have an assembler for that system. ... production of an object file, ... A compiler that produces a object file from transalting the source ... I was refering as Randallīs HLA as he hole system...It does not ...
    (alt.lang.asm)
  • Re: Why no C++ in Windows itself?
    ... >Do you mean that C is faster executing? ... I wasn't trying to start a language war. ... compiled by a C++ compiler). ... you have to "deobjectify" any data you want to access from assembler ...
    (microsoft.public.windowsxp.general)
  • Re: Why no C++ in Windows itself?
    ... >Do you mean that C is faster executing? ... I wasn't trying to start a language war. ... compiled by a C++ compiler). ... you have to "deobjectify" any data you want to access from assembler ...
    (microsoft.public.vc.language)