Re: Help...

On Jul 29, 4:55 pm, "CodeMonk" <jas...@xxxxxxxxx> wrote:
What is "design time"?

That would be anything up to, but not including - run-time.

Okay, then allow me to correct you, that's not an appropriate use of
the phrase "design time". For a given application, "design time" is
generally what precedes "coding". "Coding" is what usually precedes
"compilation". Compilation precedes "link time" (for many systems),
which precedes "load time". And Load Time precedes "run time". Those
are the standard terms for a given application.


The design of the language?
The design of the assembler program?
The design of the application being processed?
I think I'm missing something in the translation.

It's just a guess, but I'm thinking you enjoy this debate also.

Actually, it's largely a waste of time. But I've seen what happens
when I'm not diligent and I ignore it.


I assume you mean "compile time" based on the remaining definitions
you've provided.

Compile-time would certainly be an element within design time.

Well, it's nice to know what you're talking about, but the use of
"design time" in this context, at least in English, is incorrect.


Of course, as you point out, this definition is hardly satisfactory,
because assemblers process a lot of things beside "CPU specific
mnemonics". There are data pseudo-opcodes, macros, assembler
directives, and all sorts of other things that are not CPU
mnemonics.

An assembler's purpose, from it's inception, is exactly what I said in
the definition.

No, it is not exactly what you said. You said it's purpose is to
process CPU mnemonics. *EXACTLY* would mean that it processes CPU
mnemonics and *nothing else*. That is incorrect. Assemblers process
lots of things beside mnemonics.


Like I said in my reply to santosh, just because DOS
includes a batch file interpreter, didn't mean it stopped being an
operating system.

While I agree with what you're trying to say (that is, just because an
assembler processes things besides mnemonics doesn't mean it's not an
assembler), your lack of precision in your definition simply means
that you're providing an opening for the argument to continue on and
on and on.

I appreciate the fact that you're trying to say what I've said all
along -- adding stuff to an assembler doesn't mean it's no longer an
assembler as long as it does all the stuff one expects an assembler to
do (which, BTW, is *more* than just processing CPU mnemonics).
However, all you're trying to do is restart the debate at the point it
was six years ago, and if you stick around you'll soon discover that
people will poke all kinds of holes in your "definition".



Compiler: Converts HLL statements into CPU specific machine
language
at design time.
Now, of course, we get to the crux of the debate. What is a HLL
statement?

Let's say I create my own HLL and have a statement called FART. In
the standards for my language the defined behavior of FART is to cause
the specific platform to flatulate in some meaningful way to the user.
On some platforms, that might imply hearing a sound from the speaker,
and on other platforms might be the console displaying a message or
otherwise indicating that there is an offensive odor emanating from
one of the ports.

And what if there is a machine operation that does the exact same
thing, and you've just renamed that operation to FART? That's not high-
level. Simple isomorphisms do not create a high-level language from a
low-level language. Trivial syntactical details do not do this.
Abstraction is the key. If FART is an abstraction that has similar low-
level operation, then it's high-level. But if it maps to something at
the machine level, then it's low-level. That's pretty much the
definition of "high" vs. "low" level. Not the fact that you've changed
the name or syntax of some machine operation.



That's why the statement "an assembler is a compiler for an assembly
language" is so clean and useful. It completely avoids the argument
of
what an assembler is and is not based upon the implementation of
that
particular assembler, and deals directly with the real question,
which
is "what is the difference between an assembly *language* and a
high-
level *language*."

The *language* of assembler, by definition, is processor specific.

Duh!

I
base what an assembler is, or is not, on the historical origin of the
word.

That's not what you posted earlier.


And again, like I said before, just because one of the tools
might include a macro facility or provide some other whiz-bang
feature - doesn't change it's definition.

Again, don't think I'm arguing with you about what you believe an
assembler to be. I'm in complete agreement. I'm just saying that
you're new to this debate and you're rehashing arguments that haven't
worked in the past.

The nice thing about claiming that an assembler is a compiler for an
assembly language is that the definition is nice and concise, and it
pushes the argument for what is and what is not an assembler to where
it belongs -- defining what is and what is not an assembly language.
An assembler just provides an implementation of an assembly language.
How an assembler is written, what steps it goes through, etc., etc.,
have nothing to do with it's definition. Indeed, you seem to be
confused about the difference between an implementation of an assembly
language (that is, an assembler) and the assembly language itself.
Issues concerning what statements the "assembler" process are really
questions about what statements are valid in the assembly language.
How some program (the "assembler") processes those statements in the
language is really irrelevant. I realize (after seeing people have
problems with this concept in this newsgroup) that differentiating a
language and the implementation of that language is not a trivial
concept to grasp. But as you've indicated that you know the difference
between, say, compile time and run time (another concept that many
people have trouble grasping), I would expect you to be able to figure
out the difference with a little thought.



The silliness around here occurs because certain individuals cannot
differentiate a language from the implementation of that language.

Just like MASM isn't a language. It's a tool.

There most certainly is a MASM language. The grammar for that language
appears in the MASM manuals (it may not be entirely correct, or up to
date, but they have provided a formal grammar for the language). You
might seem confused because Microsoft hasn't given that language a
different name from the program that implements the language, but rest
assured that there *is* a difference. The program ml.exe is an
implementation of the MASM language. There is no reason (other than a
lack of desire) that someone couldn't create a second program that
processes the exact same language. Borland, for example, came
relatively close with TASM. Ignoring extensions and other obvious
differences, we can roughly say that MASM and TASM are two different
implementations of the *same* language. Of course, both of those are
attempts at implementing the Intel Syntax Assembly Language. Again,
from a pure language point of view, they really are three separate
languages, but compared with the other assemblers out there, they all
all three different implementations of the same language.


An assembler tool
which happens to provide macro facilities. But that doesn't change
the fact that MASM is an assembler.

No. Nor does the fact that MASM contains HLL-like control structures.
Again, this argument is nothing new. Yet Rene has been calling MASM a
"compiler" (and "not an assembler") for as long as he has been posting
to this newsgroup. If you think you can convince him otherwise, good
luck.


C is a language. A compiler is a
tool. A C Compiler is a tool that compiles C (HLL) statements into
platform specific machine language.

And an assembler is a compiler that compiles (LLL) statements into
machine code.
(BTW, there is no requirement that a compiler translate its statements
into machine code. It can translate them into assembly or even some
HLL; e.g., CFront converted C++ code into C code).


I also left a linker completely out of the equation, but it is also a
tool. One which can take the output of an assembler and a compiler
and munge those outputs together into a platform specific executable.
Linking would also happen in design-time after assemble-time and/or
compile-time, but before run-time.

See my corrections on your mis-use of the phrase "design time"
earlier.



One of my favorite acronyms from school was K.I.S.S. Perhaps the
debate in here is a consequence of over analyzing seemingly simple
concepts. Not to worry though, I personally, won't revisit this
debate.

And that's what's so great about the definition I've provided all
along: "An assembler is a compiler for an assembly language." It
simple. And it pushes all the complexity where it belongs -- in
defining what is and what is not an assembly language.

hLater,
Randy Hyde

.

Relevant Pages

  • 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: 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)
  • 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.dotnet.general)
  • Re: Evolution
    ... > inline assembler and larger parts by linking to an assembler ... in the HLL. ... language, particularly in smaller projects. ... > or two instructions if you ...
    (alt.lang.asm)