From: Betov on
"KiLVaiDeN" <kilvaiden(a)gmail.com> ?crivait news:1161332769.186816.71070
@k70g2000cwa.googlegroups.com:

> Look I don't have that much time to expand interminable posts on usenet
> about my beliefs concerning HLA, and to quote your quotes of my quotes
> which were quotes of your own words.

Now, you know why he is a "Books Writer".

:)

Betov.

< http://rosasm.org >


From: randyhyde@earthlink.net on

Betov wrote:
> "randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> écrivait
> news:1161302686.606123.138670(a)h48g2000cwc.googlegroups.com:
>
> > If they decide to continue using the
> > HLL-like statements in HLA, how is that any different than, say, people
> > using Rene's macros for the HLL statements in RosAsm?
>
> Two points, here:
>
> 1) On the Assembler side, providing a Macros System
> powerfull enough for assuming the needed HLLisms
> is _WAY_ more work, than providing Pre-Parsers
> doing the same task.

Well, if you had a decent macro facility in RosAsm, this wouldn't be
the case at all. Take a look at the implementation of the HLL-like
statement via macros in HLA sometime. Fairly easy to do. *MUCH* easier
than the code inside the HLA compiler.

Of course, there are *many* advantages to handling the processing of
these statements inside the compiler rather than via macro
interpretation:

1) Processing the statements within the compiler is much faster than
processing them via interpretive macros.
2) You can generate better code because the macros aren't aware of many
other things going on during the compilation.
3) The result is more robust. You get better error messages when the
programmer makes a syntactical (or other) mistake.


>
> [This was the reason why deffective Assemblers, like
> MASM propose internal hidden Macros, making them
> Compilers for Assembly Language, instead of real
> Assemblers]

You really don't know much about compiler design, do you?

>
> 2) On the Programmer side, the 1:1 correspondance is
> preserved, as absolutely required, for diserving
> the name of _Assembler_, and everything is kept
> under the control of the Programmer, as long as
> the Macros are _his_ Macros.

Total BS. Once you use a macro, the mythical 1:1 correspondance is
gone. Not that it ever existed on the x86 anyway (there is no 1:1
correspondance, even with pure machine instructions, because the
instruction set encoding is ambiguous).

I notice that you have finally implemented a weak conditional assembly
facility in RosAsm. This means that a macro invocation, say ".if", can
produce wildly different code expansions. Hardly 1:1.


>
> This is all of the difference in between an HLL and
> Assembly: The 1:1 correspondance, and as soon it is
> broken, we evidently are no more dong any Assembly.

Therefore, when you write code the way you've written the RosAsm source
code, you're not doing assembly.


>
> I did not invent the name "Macro Assembler", mind you,
> clown.

You didn't invent the name "assembler", either. But you seem to want
everyone around here to think that you did.

>
> So, definitively, indeed, when one writes:
>
> If eax > 80
> Output CRLF
> End_If
>
> ... with RosAsm, this is, for sure, real Assembly,

No, it is not. It is an abstraction away from the machine code. If you
want to call the above source code "real assembly", then the following
is most certainly "real assembly" as well:

if( eax > 80 ) then

Output( CRLF);

endif;

Again, you make the mistake of confusing a language with the
implementation of the language. The IF statements above are an example
of a (non-assembly) language. Whether they are implemented via macros
or internal to some compiler is irrelevant. The *LANGUAGE* is *not*
pure assembly. Assembler, for better or worse, consists of machine
instructions and data declaration statements. If you want to play the
1:1 game, then RosAsm doesn't come close, and certainly the RosAsm
source code is not assembly language.



> whereas, the exact same statement computed by a tool
> designed for _hiding_ Assembly, can, much evidently,
> have no relationship, at all, with any known form of
> Assembly.

Yes,
> If eax > 80
> Output CRLF
> End_If

makes the assembly perfectly obvious, while

if( eax > 80 ) then
stdout.newln();
endif;

completely obfuscates it. You're making perfect sense here.
Cheers,
Randy Hyde

From: randyhyde@earthlink.net on

KiLVaiDeN wrote:
>
> Look I don't have that much time to expand interminable posts on usenet
> about my beliefs concerning HLA, and to quote your quotes of my quotes
> which were quotes of your own words.

Could have fooled me :-)

>
> Maybe I'm wrong after all in my opinion about HLA, I am always ready to
> step back when i'm obviously mistaken, but it looks like you are never
> ready to do such introspection about yourself on your own. Everytime
> you talk to someone, you _MUST_ be right about _ANYTHING_. Nobody is
> perfect dude.

No, there are lots of areas where I don't have the experience or
knowledge and I tend not to get involved in such discussions. But let
me point out that I *have* studied programming language design, I
*have* taught the subject (as well as compiler design and
implementation) at the University of California and at Cal State
University. So I *do* know a little bit about this subject. When
someone, such as yourself, comes in speaking based on their emotions
rather than on fact, you'll forgive me if I slap some wrists a little
bit and offer a correction. Note that when it comes to things like the
definition of a programming language, I actually *do* know what I'm
talking about most of the time.


>
> I will just say, that I believe HLA is a nice piece of software, I
> haven't denied that at any time. It's probably even good, accompagnied
> with the book, to learn about the way the machine works, and eventually
> about assembly. I have *read* it, but really fast, I haven't really
> taken the time to do a detailed reading and testing, and I didn't read
> the source code that much either, because I hate the line breaks
> inserted between every single line of code, and couldn't bare them. I
> couldn't clean it as well to have a more readable source code because
> it was.. Not my favorite thing to do.

If I interpret this correctly, you think that code is more readable if
you cram a bunch of different statements together all on the same line,
right? If that's the case, I would suggest that you're in a group that
is a *very* small percentage of the population. Look at all the
programming books out there. How often do you see the authors cramming
multiple statements per line? The vast majority of people out there
don't do that.

As for inserting blank lines between statements, you might want to
study graphic arts, typography, and document layout sometime. Many of
the principles that make text easy to read apply to programs as well.
My goal is to make the source code readable for the majority of
programmers out there, not please someone who has convinced themselves
that cramming lines together is more readable.


>
> I understand though your point of view : you say HLA is an assembler,

An "assembler" is a compiler for an assembly language. HLA certainly
fits that definition. Ergo, it is an assembler. Any attempt to
otherwise eliminate HLA from the set of assemblers also winds up
eliminating products like MASM or TASM, which are unquestionably
assemblers in most people's minds. Every attempt around here, by Rene,
yourself, and others, to exclude HLA as an assembler fails on this
basic litmus test. And trying to claim that MASM is not an assembler
(as Rene tries to do) is foolish. The majority of the assembly
programmers in the world would refuse to accept such a definition.

> because it has all the directives an assembler is supposed to provide,
> in order to produce machine code, and therefore someone *could* use it
> that way, as a pure assembler. Right.

Okay.

>
> Yet I believe that *MOST* HLA users don't use HLA that way. They use it
> with all the functions your library can provide.

Absolutely nothing wrong with calling library code from an assembly
program. RosAsm users, for example, do it all the time. If someone
decides to call "kernel32.wsprintf" in RosAsm, does this mean that
they're not writing assembly code?

I find it amusing that you seem to think that RosAsm users calling code
written in C (e.g., wsprintf) are writing "true assembly code" while
HLA users calling code written in assembly language (the HLA stdlib)
are not writing "true assembly".

Perhaps you are under the mistaken impression that assembly programmers
cannot call library routines? This is absolutely foolish. Assembly
programmers have been doing this since before the days of the first
assemblers (back when they worked in machine code). Claiming that HLA
programmers are not working in assembly language because they call
subroutines that are in the HLA stdlib (which, btw, is *not* a part of
the HLA language) is a very weak argument.


>
> And there is my point : an HLA user, who is using MOSTLY the directives
> of HLA, is NOT programming in assembly. He's programming in HLA.

What is assembly?
I could argue that someone who programs mostly in the syntax of FASM is
not programming in assembly, s/he is programming in FASM. FASM is a
language. Assembly is not a language. It is a generic term that
encompasses several different languages. FASM is one of those
languages. HLA is another. Yes, the programmer you mention is
programming in HLA. They are also programming in assembly.

Now you can argue that someone who programs using the HLL-like control
statements in HLA is not really programming in assembly. And I would
agree 100% with that. The same argument, however, applies to *anyone*
who is using macros in their assembly source file. Have you looked at
the RosAsm source code ever? Try and tell me that all those "IF" and
"WHILE" macros are "assembly language". Given that Rene (and others)
use those macros all over the place, if I were to believe your
statement, I would have to say that Rene is not writing assembly code,
he's writing ROSASM.



> That's
> what I'm trying to say from the beginning, but you twist my words all
> the time. It's just as simple as that.

Nothing to twist. You just haven't thought things through, that's all.


>
> You say I confused the language and the implementation of the language.

Yes, you have.

> Hmm who cares for the implementation ?

The RosAsm crowd sure does. You seem to. After all, you're the one who
pointed out that HLA generates source code for an underlying assembler.
That's an implementation detail that is totally irrelevant with respect
to the HLA language.


> I'm talking about the language
> fr
From: randyhyde@earthlink.net on

Betov wrote:
>
> Yes, clown. The ones interrested can take a look at:
>
> < http://www.szmyggenpv.com/RosAsm.htm >

Totally junk cut & paste code.

>
> ... which is the page of this "Wannabee". When seeing
> the quantity, quatity and originality of this fellow's
> productivity, everything is "proved", indeed.
>
> Just provide one single link, to one of your victims,
> having produced one tenth of that, clown.

Take a look at Sevag's stuff sometime.
Cheers,
Randy Hyde

From: Betov on
"randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> ?crivait
news:1161355279.950758.166450(a)h48g2000cwc.googlegroups.com:

> Of course, there are *many* advantages to handling the processing of
> these statements inside the compiler rather than via macro
> interpretation:
>
> 1) Processing the statements within the compiler is much faster than
> processing them via interpretive macros.

Probably the reason why RosAsm compiles huge Files in
no time, when your thingie takes a coffea time on small
ones...

:)

> 2) You can generate better code because the macros aren't aware of many
> other things going on during the compilation.

Last news from Randall Hyde: HLLs produce better Code
than Assembly. Hey! Hutch--, --, --! Are you asleep?

:)

> 3) The result is more robust. You get better error messages when the
> programmer makes a syntactical (or other) mistake.

No doubt, clown. How is it, that your victims ask so
much questions about how and why they fail on this and
that?

:)

Betov.

< http://rosasm.org >