Re: Definitions - What are yours?

On Jul 30, 11:21 pm, Betov <be...@xxxxxxx> wrote:
"cr88192" <cr88...@xxxxxxxxxxx> écrivait news:b73cf$46ae6bcb$ca83a8d6
$4...@xxxxxxxxxx:

it also converts general abstract constructions,

Not exactly. It depends entirely on *HOW* it does it.

And that's where you're absolutely wrong.
The implementation of a language has nothing to do with the language
itself.
You can implement the exact same language in many different ways; that
does not change the definition of the language.

I'd like to say that you are just incredibly stupid and you fail to
grasp this point that has been made over and over again for the past
several years, but the truth is you're just lying, swindling, whatever
you want to call it, in a losing attempt to try and create a
definition for "assembler" that excludes the products you'd prefer not
to have to compete against.



deals with finding the
right/best encoding,

No. This does not belong to the definition. If an Assembler
does not make any choice (example, Herbert Assembler), it is
still an Assembler. I should say... it is MORE of an Assembler
than the other Assemblers around.

You're statement is logically inconsistent. First of all, you say it
does not belong in the definition. Then you turn around and say that
an assembler is "more" of an assembler if it doesn't do this kind of
stuff.

The interesting point here is that you're arguing that the
implementation of the assembler doesn't belong in the definition. This
runs completely contrary to just about every other post you've made.


You miss the *HOW* again. MASM, not outputing what the programmer
writes, cannot be an Assembler, even if everybody calls it so, by
facility.

Funny, everybody calls MASM an assembler but you. Therefore, because
*you've* claimed it cannot be called an assembler, it cannot be called
an assembler.

My, what an ego you've got if you think that your opinion trumps the
opinions of everyone else.


It is a "Compiler for Assembly Language".

Which, by definition, is an assembler.


An Assembler
CANNOT have internal hidden Macros.

Sure it can.
I could make the same argument that an assembler cannot have hidden
predefined symbols. It is *exactly* the same argument. That
immediately means that RosAsm is not an assembler on the basis of that
equates file (which defines a bunch of "hidden" symbols).

Furthermore, let's consider something else present inside RosAsm (and
most other x86 assemblers): synonyms. What are instruction synonyms
other than "hidden" macros? Consider jb and jc. Same exact
instructions. Clearly there is not a 1:1 correspondance to the
underlying machine instruction (which is jc). Therefore, I claim that
"jb" is a "hidden macro" and any assembler that compiles jb cannot be
called an assembler by your definition.

Moving right up the list, let's consider what the wikipedia entry
calls "pseudo-instructions". For example, some CPUs don't support
certain instruction (they give an example like "bge", "branch if
greater or equal"). So if an "assembler" provides a hidden macro like
"bge" that compiles into *two* instructions to simulate bge (say, bg
and be), by your claim it would no longer be an assembler.

Before you trot off and claim "that's right", consider the fact that
this is pretty much exactly what happens with many of the SSE
comparison instructions.

As said so many times, when
you see a line like:

If eax = 0

It will be Assembly, if it is build through user defined Macros.
If the very same HLLism is build by the grace internal hidden
Macros, this is no more an Assembler.

Again, you confuse implementation with language.
It really doesn't matter what the source of the macro is. The macro
could be provided by the end user, by some third party, or by the
assembler's author. The macro could be provided as part of a text file
that you have to cut and paste into your source code, as part of an
include file that you include in your source file, as part of a hidden
"equates" file, or as part of the compiler's source file. It doesn't
really matter -- it's just an implementation detail.

Let's consider a real-world case.

HLA has built-in macros for things like an IF statement. So by your
defintion, HLA is "no more an assembler". However, I can, with a
single statement (#id("if")) disable that reserved word and write a
macro in the user's program that does exactly the same thing as HLA's
built-in IF macro. Does this mean that, with absolutely no changes to
the code, HLA is now an assembler rather than a compiler?

Obviously, you haven't thought this through very well. You're just
hell-bent on trying to remove products like TASM, MASM, and HLA from
the "assembler" category so you don't have to compete with them on a
feature-by-feature basis.



It all depends on the *HOW*.

No, it doesn't depend at all on the how. Only on the *WHAT*.

At some extreeme absurd extension,
if you had, in a given Assembler, the capacity of implementing
entirely C++ by user defined Macros, and compile entire C++
existing sources, the tool would still be an Assembler, and not
a C++.

Wrong. The implementation language does not define the target
language. This is another concept you've had a lot of problems with
over the years.

I can write a C++ compiler with any language I choose. That could be
assembly, macros, flex/bison/lex/yacc, C/C++, Perl, whatever. As long
as that compiler accepts input source code that is part of the C++
language and translates it to something else, I can call that a C++
compiler. The fact that I wrote that C++ compiler in Perl does not
mean that the result is a Perl compiler. Likewise, the fact that I
wrote the C++ compiler in some assembler's macro language does not
mean that the result is an assembler.


What would create a C++ would be the User Defined Macros,
and in no way the Assembler.

Most likely, the assembler would be responsible for handling the low-
level machine code that the macros produced, so most certainly the
assembler would be involved in the C++ compiler. You *do* realize,
don't you, that native code generation is typically considered to be
part of the compiler?


That is, at any time, the programmer
could modify the "C++" !!!

That's true of any implementation language, be it macros, pure
assembly, C/C++, Perl, flex/bison, whatever. If the source code is
there, the programmer can modify the compiler and produce a different
language, should they desire to do that. This has nothing to do with
your argument about assemblers and macro assemblers.




As opposed, when *MASM* creates one single trivial HLLism, this
is no more an Assembler, because the user never created this.

The user didn't create the translation to machine code.
The user didn't choose which opcodes to select when the selection is
ambiguous.
The user didn't choose a lot of things.
That really has nothing to do with whether MASM is "no more an
assembler".

This is out of his control.

Wrong.
The user can elect not to use those HLL control structures, if that
type of control is what they want.
The user can elect to encode specific opcodes in binary if they don't
want to use the ones that MASM selects when there is ambiguity.
The user has fairly good control over this stuff. The few things that
the user has no control over are problems that exist with most x86
assemblers.



And there exist plenty of other reasons why MASM is not an
Assembler. Like RET inside Proc, Stack Data managements, and
so on...

IOW, MASM is not an assembler because it supports more features than
your own product. Shame on you from trying to swindle people this way.



We are used to call it an Assembler, because it is used as
such.

Wow, imagine that. People call it an assembler because they use it as
an assembler.


That is, you *can* use it as an Assembler,

Wow. Imagine that. You can use it as an assembler. But it's *not* an
assembler! Have fun explaining that one.


if you know
of the traps. Though, most the the MASM users use it as a
Compiler for Assembly Language.

Just like FASM users use FASM as a compiler for an assembly language.
And NASM users use NASM as a compiler for an assembly language.
And so on.

Remember, an assembler is just a special type of compiler that
processes assembly language as its source language.


We have seen example of a
MASM programmer, who was estonished, after one year of
usage, of hearing that "Invoke" was not a Mnemonic !

Yeah?
I'd bet there are people who think the same thing about "DB". What
does that prove? I'm sure you can find people other there who think
that "C" is some sort of assembly language. However, the fact that
some people are ignorant of certain things (such as your ignorance of
the difference between a language and the implementation of a
language) doesn't change a product's category.

For example, you exhibit considerable ignorance whenever you try to
call MASM a "compiler, not an assembler". That doesn't change what
MASM is, or what people use it for, one iota. It's just the ignorant
rantings of someone who (1) doesn't know what he's talking about, or
(2) does known, but is trying to swindle people into believe his own
product is better than it really is.
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: i disagree
    ... assembly language source file must match the machine instructions 1:1 ... One such short-cut we are used to is simply dropping "macro" when ... language maps to three machine instructions. ... powerful enough Macros system, implemented inside a Macro Assembler, ...
    (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)