Re: HLA v1.93 is now available

On May 5, 1:03 am, Betov <b...@xxxxxxx> wrote:
"r...@xxxxxxxxxx" <r...@xxxxxxxxxx> écrivaitnews:1178327857.562521.71560@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:

It is interesting how you constantly preach about how the "best
optimization" is to do nothing at all.

Where did i say this, clown? What i have said was that Code Level
Optimizations were most time absurd, and that the real Assembly
Optimization is Strategy Optimization.

So why don't you explain to us what "Strategy Optimization" is, then?


Why does that not apply to size
optimization as well. That is, the best size optimization is to *not*
emit those extra, unneeded, displacement bytes in all the branches in
a program.

In an HLL this is absurd. Admitting a programmer would care of
his code side, for whatever absurd reason, he would do it in
Assembly, and evidently not with an HLL, nor with an HLL Preparser.

Funny. You're claiming that an assembly language programmer using HLA
wouldn't be concerned about this. Yet it seems that RosAsm was the one
late to the party with branch displacement optimization and *you* were
(and still are) the one arguing against it all these years. Do RosAsm
users not care about size optimization? Does this mean that RosAsm
users aren't assembly language programmers?



Perhaps you should try counting the number of branches in your program
sometime. Assuming the vast majority of them would be two bytes long
instead of six bytes long (as is the case in most programs), I think
you'll find that it's more than a "couple of bytes".

Why would one be stupid enough for making _all_ jumps long, with
an Assembler, clown? In Assembly, the jumps sizes are under the
control of the programmer.

Only in *your* assembler.
Most of the other assemblers I know about handle this automatically
for you. You are a bit behind the times. Because your assembler has
this design defect that forces "short" or "long" jumps based upon
whether you're using local or global symbols (a glaring defect, I
might point out), you're trying to cover up your mistake by arguing
that this feature should be under the control of the programmer. Sorry
dude. That attitude is *soooooo* 1980s. Modern assemblers take care
of this grunt work for the programmer.



Again, if you don't understand the impact of saving *four bytes* per
conditional jump on *most* of the conditional jumps in your programs,
it's no wonder you don't think highly of branch displacement
optimization.

Why on earth would an Assembler have to save that room, if the
programmer defined them long, clown?

jmp toSomeLabel;

Explain to me where they are defining this jump as a "long" jump.
Forcing the programmer to put "short" or "near" (or whatever) in front
the the label is criminal. It's this type of attitude that results in
the tiny user base that RosAsm has.


Care to provide a link that suggests that shorter programs are not
faster?

I don't need to provide any link, clown. _You_ do.

Okay, try reading the AMD optimization manual. Or the Intel variant.
Both tell you that you should use the shorter variants of instructions
because this reduces cache thrashing.

Of course, if you knew the first thing about computer architecture,
you wouldn't be making such a big fool of yourself arguing against
this well-known concept.

You spread absurd
bullshits, instead of admitting that you never considered NASM because
of its license, even though it was the evident choice to do for your
HLL back-end.

You're the one spreading BS. Even Frank has called you on this one.



Let's see. MASM does branch displacement optimization. TASM does
branch displacement optimization. Gas does branch displacement
optimization. FASM does branch displacement optimization. From what I
understand, even NASM now does branch displacement optimization. Why
would anyone want to use an assembler that forces *them* to do this
grunt work which is clearly in the domain of the computer? Indeed, as
much as you hate the subject, why did you attempt to add this feature
to RosAsm other than because of the fact that you perceived that users
were demanding it?

Nobody ever demanded it, but, considering that there exist programmers
stupid enough for believing in such bullshits, this has been implemented
as pure propaganda, for the fun of it.

Again, it's attitudes like this that cause people to reject your
product.


Not even yet really finished,

Yes, the existing implementation is broken. We know that. Furthermore,
you still have the glaring design defect of associating branch size
with the completely independent notion of local vs. global symbol
scope.

by
the way, as i still have a part of the job to do, to enable it with
Align statements. In an Assembler where the jumps sizes are under the
control of the programmer, this does not make any sense.

An assembler that forces the programmer to make these decisions does
not make sense in this day and age. You're trying to push a 1980s
assembler onto the assembly community which has long ago chosen
automatic branch displacement optimization.



Let me put it to you this way -- you automatically optimize immediate
operand sizes for instructions like CMP, PUSH, ADD, etc. You don't
force the programmer to manually choose such sizes. If you do this in
your assembler for those types of instructions, without arguing about
it, why would you make such ridiculous claims against branch
displacment optimizations. One more example: if you automatically
choose the smallest displacement size for the mod-reg-r/m byte and
don't make the programmer manually select this, what argument do you
have to offer for not optimizing branch displacements, too?

When Encoding an Instruction having several forms, the choice is
to output the smaller one, if the Assembler does not give the
opportunity, to the programmer, to define by himself whatever form.

Well, are not jump instructions examples of instructions having
different forms? Isn't the choice to output the smaller one?
Obviously, if the programmer wants to emit the larger one it would be
nice if the assembler gave the user that kind of control, but by
default it should always emit the smaller version. That applies to
jumps as well as to any other variable-length instruction.


For jumps sizes, an Assembler lets this choice on the programmer
decision.

Why jumps? Why not pushes, cmps, and any other instruction that has a
variable-sized encoding? Talk about "Swindling" and "Bullshits"!



What stupdities are those? Do you honestly think that long jumps
*don't* affect program performance? You should study the Intel
architecture a little more closely if you possess this mistaken
opinion.

You should learn the basics of Assembly, before stating such amaizing
bullshits.

I see you're avoiding the question.

No, clown. The time of a short jump and of a long jump are equal.

If you're going to play that game, then I'd argue that the time of a
short displacement (for mod-reg-r/m) and a long displacement are also
the same. So why don't you force the programmer to choose those
encodings, as well?

Period. Now, if for whatever reason, a programmer want a short
jump, in Assembly, he defines it as such, whereas, in an HLL
like yours, this would not make any sense.

Great. You still haven't answered why this same principle doesn't
apply to other instruction encodings.



Why? Your "explanations" do not stand one second,

Why?
Simple. HLA v1.x doesn't do the branch displacement optimization and
relies, instead, on the back-end component to handle this. That's
called putting off work for a future version (v2.x, in this case).

Well, if your HLL Preparser was an Assembler, it would offer the
choice to the programmer.

Not necessarily. I don't see you offering the choice of displacement
sizes for mod-reg-r/m encodings, for example.

So, your HLL is not an Assembler, and,
therefore, who care of saving a couple of bytes in an HLL?

So this means that RosAsm is not an assembler because it doesn't let
the programmer choose instruction lengths for all the variable-length
instructions? I guess that means that NASM is the *only* assembler out
there because (IIRC) it's the only assembler I know of that gives you
this choice for all instructions.


FASM is a far better choice for a "freely distributable" back-end to
HLA.
1) It's faster.
2) Its syntax is closer to MASM than NASM's is.

Absolutely false, liar.

Are you saying that FASM is not faster than NASM?

No, clown. FASM is way faster than NASM, and everybody perfectly
knows of this.

Okay, so (1) is the truth.


Are you saying that FASM's syntax is not closer to MASM's than NASM's
is to MASM?

Yes, clown. FASM syntax is as close to the NASM syntax as RosAsm's
syntax is.

So, IOW, you started posting away without even understanding what was
being said. Go back and re-read what I said. As you're not a native
speaker, let me help you out a little.

I did *not* say FASM's syntax is closer to MASM's syntax than FASM's
syntax is to NASM's (which is what I believe you're trying to claim I
said).

What I said was that FASM's syntax is closer to MASM's syntax than
NASM's syntax is to MASM's syntax. How close FASM and NASM happen to
be is irrelevant to HLA, which started out emitting MASM code. What's
important to HLA is how easy it was to modify the MASM code generator
to generate NASM or FASM output. As FASM is closer to MASM than NASM
is, FASM was the better choice.

Perhaps, along with learning some computer architecture, you ought to
learn a little *English* as well.



4) FASM had on-going support.

Whereas... what?

NASM did not.

:)) No comment...

Too late. You've already made lots of comments on the subject. But
thanks for admitting you were wrong.



5) Tomasz was willing to make adjustments to FASM to support HLA

Liar.

Hmmmm...
Aren't you the very person who blasts Tomasz in this very newsgroup
for supporting me?

I am saying that Thomasz never did any "adjustments to FASM to
support HLA", and that you are a liar when saying the reverse.

Hmmm...
Well, for the record, Tomasz did make some adjustments with the way
global/public/externals worked. If you don't believe me, why don't
you ask him?

And, pray tell, what made *you* an expert on what Tomasz has and has
not done in FASM?




Now, the fact that this guy has no ethical concern, and had no
problem compromissing and dihonnouring himself aside a criminal
like you is another story.

It's understandable why he doesn't take any of *your* suggestions
seriously. But for people who actually *use* his product in ways he
intended (e.g., as back-ends to compilers), I've found Tomasz to be a
fairly responsive guy. This type of support is exactly what I'm
talking about when I said I chose FASM over NASM because of on-going
support.

The support could be something as simple as providing me a macro that
lets me declare global objects, or something as simple as tweaks to
the code because I encountered a problem with the way FASM generated
code.

Just proving one another time that you are a fucky liar, by
having just said right above that you don't need FASM Macros
for your HLL.

Uh, reread what *you* wrote. *You* said NASM, not FASM.

No. Learn how to read.

No?
Provide the link, please.



And, technically speaking, I don't need those macros (after all, a
"HLL-preparser" is just a giant macro processor, right?") They were
just a convenient example.

Was just one another big lie. Period.

???
You do realize that I don't need those *macros* because HLA could
simply emit the corresponding code in-line, right? I realize your
English skills seem to be on the weak side today, but you're really
pushing the boundaries here.


You did not know how to do
something, and what Thomasz did was to show you the macro you where
unable to write. Period.

Yes, Tomasz provided a macro that let me declare global symbols. No,
at the time (even today) I don't know the FASM programming paradigm
well enough to have generated that macro on my own (and I'm not alone,
I doubt that 99% of the FASM user base would have been able to come up
with that solution, it's one of those things that only the assembler's
author would come up with). This is exactly the type of support I'm
talking about when I said I chose FASM over NASM because of on-going
support. If I'd had the same problem with NASM, exactly who would I
have gone to with the problem?




And what Assembly "translator" did add a single victim to your
list of victims, clown?

FASM, actually.
Several people got excited about HLA once they could use it without
having to use MASM as a back-end unit under Windows.

One example, of _one_ FASM user, who would have switched to your
HLL Preparser, clown?

Uh, where did I say that a *FASM user* switched? Now you're making
things up. I realize you're having lots of comprehension problems
today, but you might try reading the statement over more than once
before coming up with this nonsense. If "jumping to conclusions" was
an Olympic event, you'd, no doubt, get a gold medal.



Which is? Still waiting for examples of Applications written
with your HLL... Since...

You've been given the links. You refuse to acknowledge them.

Still waiting, clown.

Search back with Google, dude.
Frank, myself, and many others have posted the link to the
AoAProgramming page many times.
hLater,
Randy Hyde

.