Re: HLA Stdlib v2.2 is now available.

On Sep 30, 5:07 am, Betov <be...@xxxxxxx> wrote:
Herbert Kleebauer <k...@xxxxxxxxx> écrivait news:46FF88FC.DF9D9187
@unibwm.de:

Do you think RosAsm is any better?

I don't care of what you think about RosAsm.

So, then, why do you think anyone cares of what you think of any other
product? Certainly you've figured out that almost no one around here
cares about your opinions. The mere fact that you often tell us that
only you and a few select others (typically Wannabee and Wolfgang) are
true "Asmers" and everybody else are "idiots" suggests that even *you*
are aware of the fact that no one respects your opinions on this
subject around here.


Just because you use the
magic word "preparse" makes it all different?

Yes. "Pre-Parser", in the case of "HLL Pre-Parsers",
means *HLL*. This point is 100% clear.

Someday, when you figure out the difference between the definition of
a language and an implementation of a language, you'll be embarassed
that you've made such claims.

In the meantime, here is something to ponder:
You are really big on claiming that the *implementation* of a language
has a lot to do with that language. For example, the fact that HLA is
written in a LLL, a HLL, and a couple of VHLLs somehow "disqualifies"
it from being an assembler. You argue that the fact that the HLA
compiler itself processes macros directly disqualifies it as an
assembler. Let me ask you this question: suppose I wrote all my
"internal macros" in a VHLL of my own design rather than in Flex/Bison/
C? Would that magically transform HLA into an "assembler"? No doubt,
you would say no (simply because you *must* argue that HLA is "not an
assembler" so your own product doesn't have to compete against it --
yeah, we understand that part). However, what is a "macro language"
other than a VHLL? Now, you like to argue that the difference is that
the "user" can write their own macros and this makes all the
difference in the world. It makes no difference at all. Consider the
fact that most users of your *own* product use the macros *you* wrote
rather than writing their own versions of them. They use them as
black boxes, without really understanding what they are doing. Of
course, you can claim that they can "right-click" and see the macro
definition in the code, but I could use the argument that a C
programmer can use the "-S" command-line option and see the assembly
code that GCC generates. The fact that they can see that C code no
more makes GCC an "assembler" than the fact that a RosAsm user can
look at a macro definition using right-click.

The bottom line is that any code-generating statement in an assembly
language program that is *not* a machine instruction is an
abstraction. This is true for macros; this is true for high-level
assembly statements. You can argue about the relative "level of
abstraction" but you cannot argue that some of it is "assembly
language" and the rest is not. Once you abstract away from the machine
code (your infamous "1:1 correspondance") you've got something that is
higher level.

It doesn't matter *who* wrote the abstraction. Your argument that a
user can write their own macros doesn't make sense. Does this mean
that if a user writes some HLL-like construct with a macro *you* wrote
that they are "not programming in assembly" but if they write an exact
copy of that macro themselves they "are writing assembly?" What
nonsense. Does this, then, mean that HLA users are "not assembly
language programmers" but I *am*, when we both write the same HLA
source code, simply because *I* wrote the macros you're calling
"HLL"? As usual, your argument is completely illogical.

It doesn't matter *what* language the abstraction is written in. It
could be written in assembly language, it could be written in C, it
could be written in a VHLL like Flex/Bison, it could be written in a
VHLL like the HLA compile-time language. Regardless, the abstraction
presented to the user is exactly the same; the underlying
implementation is irrelevant.

Ultimately, it is the code that the user writes that determines the
abstraction level of their program.
They could write something like this:

procedure fileio.putu32( Handle:dword; d:dword ); @noframe;
@nodisplay;
begin putu32;

sub( 4, esp ); // Make room for width
push( (type dword [esp+4]) ); // Copy return address, make room for
fill
mov( 0, (type dword [esp+8])); // Width = 0
mov( ' ', (type dword [esp+4]));// fill = ' '
jmp fileio.putu32Size;

end putu32;

and be fully justified in calling this "assembly language code", or
they could write something like this (from the RosAsm source code):

mov eax D@Message

...If eax = &WM_PAINT
.If D$CodeSource > 0
call TextPos
mov eax D@Adressee
If eax = D$EditWindowHandle
call PrintColorText
Else_If eax = D$BpWindowHandle
call PrintBp
End_If

If B$MovingBlock = &TRUE
call SetBlock | call AskForRedraw
End_If

call StatusBar

mov B$RedrawFlag &FALSE
.End_If

mov eax D$EditWindowHandle | On D@Adressee <> eax, jmp
NoClient

...Else_If eax = &WM_CHAR

and not be justified in calling it "assembly language". It doesn't
matter that there are all these macros for things like "...Else_if"
You've created a HLL using a VHLL (the RosAsm macro language) and
you've abstracted the language away from the base machine language.

Now of course, you're going to argue that this is all well and good.
And you are absolutely correct. There is a reason why almost every
major assembler since the 1960s has provided (minimal, at least) macro
facilities. Macros are a good thing. High-level assemblers are just
the next step in the evolution of assemblers, providing those commonly-
used macros built into the language. You cannot argue that a high-
level assembler is "not assembly" while simultaneously arguing that it
is possible to "write assembly" in a high-level assembler like HLA (as
you've done in the past). You cannot argue that an assembler like
RosAsm is a "true assembler" (as opposed to something like MASM or
HLA) when your own source code uses HLL constructs like the above.

Please don't tell use about "preparsers or macros make this 100%
obvious." Anyone who knows x86 assembly language *knows* that
statements like the code above are *not* assembly language. Just as
they know that comparable statements in a high-level assembler such as
MASM or HLA are *not* assembly language.

In the end, your distiction is irrelevant anyway. You can carp all you
want about high-level language features in assemblers like HLA and
MASM (even, all the time, using comparable constructs in your own
source code). But has it ever occurred to you that, just perhaps,
people *want* these constructs in an assembly language? Look at 90%
of the Win32/MASM source code out there -- it all uses the high-level
assembly constructs of MASM. You, yourself, claim that using high-
level assembly constructs makes your code more readable and that
people should use high-level language constructs in their assembly
code. Does it really matter, as far as readability is concerned,
whether that macro is written in a VHLL such as the RosAsm macro
language or is written in a language like C? AFAICT, it makes *no*
difference whatsoever at all in the source code of the assembly
language program -- an IF statement is an IF statement, regardless of
the language you use to implement that IF statement with. And as long
as your assembly language source code contains such IF statements, you
are not justified in calling *your* source code "assembly language"
while calling someone else's source code that also contains IF
statements "not assembly".




I don't care of what you think Assembly programming means.
I have my own meaning of it.

Yes, we know that. Your definition seems to be "anything but HLA" :-)

Seriously, though, it's fine that you have your own definition.
However, at some point in time you've got to realize that everyone
else has a definition that is *different* from your's, so trying to
argue that one product "is an assembler" while another "is not an
assembler" is a waste of time, as your definition isn't the one people
accept. And after all these years, it's not like you've been able to
convince people to accept your definition.
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: What is an Assembler
    ... >> converts a HLA source to an executable. ... > knows the first thing about formal language design. ... convert an assembler source file to an executable (comparable ... it is a full compiler in every sense of the word. ...
    (alt.lang.asm)
  • Re: Hey, what is all this off topic posting?
    ... >>> that's all you're using macros for, I can see why you don't much like ASM. ... > PL/I language constructs though. ... >> write the macros using some arcane assembler to do that on a new ...
    (sci.electronics.design)
  • Re: "We Never Use Assembly Language"
    ... too bad that I expect the same from macros that I use. ... I guess Rosasm is no longer written in assembly. ... does not detract from a tool being an assembler. ... it raises HLA some levels. ...
    (alt.lang.asm)
  • Re: HLA StdLib2 criticism
    ... The macros in HLA are optional, ... You have frequently claimed that HLA is the best "assembler". ... compiles into a single machine instruction. ...
    (alt.lang.asm)