Re: HLA v1.93 is now available

On May 4, 2:34 pm, Betov <b...@xxxxxxx> wrote:
"r...@xxxxxxxxxx" <r...@xxxxxxxxxx> écrivaitnews:1178311602.051087.187850@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:

Well, it *might* take your 8200 byte application and turn it into an
8190 byte application.

Too bad that under, say, Win32, the difference would likely
be... zero, isn't it, clown?


If you think so, then it's no wonder you don't believe in branch
displacement optimization.
For the rest of us, who do understand the effects of granularity on
program size, we are concerned about such things.

It is interesting how you constantly preach about how the "best
optimization" is to do nothing at all. 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.


All without any effort on the part of the
programmer. And this last sentence is what's important. If by doing
other other than using an appropriate tool the program becomes
smaller, who's to complain?

Your bullshits and wind still does not tell the reason why one
would like to eventually save a couple of bytes, admitting the
Application would be big enough.

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".

The fact that you are arguing against this point demonstrates your
complete ignorance of what assembly language programming is all about.



As you seem unable to read the question, here is it again:

Why on earth would one want to save a couple of bytes with your
HLL?

I don't know. I'm not talking about a HLL here.



For example, we could imagine a guy having only a floppy on his
computer, and no hard disk. Is it this, clown? :)

So let me get this straight -- you're advocating burning up memory
just because it's there? You sound a whole lot like Microsoft to me.

So, if you are really igorant of everything, under Win32, the
Section are aligned on 01000h boundaries. How amaizing isn't it
of having the OS "burning up memory" by such impressive metrics,
whereas your stupidities would be trying to save a couple of byte.

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. You might try learning a little mathematics before you
set down and try to program in assembly again. In particular, learn
about multiplication. As in: "four bytes times the number of optimized
jump instructions in your program."



* Solution two:

One would believe that short jumps are faster than long jumps.

Yes, they are. Any time you reduce the size of the application by a
signficant amount, you speed it up. That's because more code fits in
cache at one time, you get less page thrashing, and other ill effects
that go along with larger programs. Automatically shrinking all 6-byte
jumps to 2-byte jumps that are possible is a good way to reduce the
size of the program and speed it up. This is particularly a no-
brainer if the compiler can do all the work for you.

You should write one another pdf of bullshits on that topic, clown.
I see that absolutely nothing can stop you from spreading bullshits,
and that your insities have no limit. Congratulations.

Care to provide a link that suggests that shorter programs are not
faster? Go ahead, deny that fact. I'd love to see you go on record as
saying that shorter programs always execute as fast as larger programs
that are doing exactly the same amount of work. While you're at it,
feel free to explain to us why CPU manufacturers go to all the trouble
and expense to put ever-larger caches on their CPUs. Granted, you're
probably still using that old 1.5 GHz Celeron chip and you probably
don't realize how much of an impact it has on program performance to
keep as much of your working set in cache as possible, but I would
hope that if you're such the assembly language programmer you intimate
that you are, you would at least understand the basics of memory
organization.


But, when you will have written that, you will still have to explain
the reason why a programmer, who would be stupid enough for buying
such bullshits, would choose to do it with with an HLL, instead of
doing it with an Assembler, where the jumps sizes are under the
control of the programmer.

Hmmmm...
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?

In a *very few, and rare, cases* the programmer might want to execise
control over the size of the displacment (specifically, forcing a jump
that could be short to be a long jump). Largely, this would have to do
with adjusting the code that follows the branch down in memory so that
some label happens to fall on a nice boundary (e.g., to speed things
ups). Such code is utterly unmaintainable (and, indeed, if the problem
weren't NP-Complete and it's not possible to quickly compute even a
common solution, this would be another example of something that
should be done by the computer). Occasionally, you might want to
reserve four extra bytes this way for object-code patching. Other than
that, there's very little need for the programmer to control this.

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?




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. Perhaps you should learn the
basics of computer architecture and memory organization/caching before
opening your mouth.


Since when did macros have anything to do with my choice of rejecting
NASM as a back-end to HLA?

Nothing, clown, other than the fact that _YOU_ claimed that,

Really? I claimed this? Why don't you provide a link to such claims?


before you made up your diseased mind that the claim itself
was a demonstration of the absurdity of your HLL Preparser.

Been drinking again? This statement makes no sense at all.



Other than some trivial macros in FASM to
make up for the fact that it doesn't have the equivalent of a global
or externdef directive (as MASM, TASM, and Gas possess), HLA doesn't
emit any macros to be processed by the back-end assembler. Indeed,
HLA's output is generally quite trivial assembly language output.
Stuff even low-end assemblers would normally be able to handle.

Sure, clown... but not NASM.

Just those three problems in the way of NASM. And actually, the branch
displacements wouldn't prevent the program from working, it would only
mean that the code would be incredibly bloated. Boy, you'd love that,
wouldn't you?


:)

Actually, HLA has *three* requirements for a back-end assembler:

1) Automatic branch displacement optimization,

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).


and are
utterly absurd, even more than absurd for an HLL.

Again, your statement doesn't make sense.


2) The ability to forward reference an EQU symbol before it is defined
(including chains of forward references), and

Whatever you say. Who cares?

HLA cares. If this feature is not available, the code that HLA emits
will not compile. I don't know if NASM supports this capability today,
but it was one of the failure points I ran into when playing around
with NASM code emission in the past.


3) A syntax that is reasonably close to MASM so that the MASM strings
that HLA emits could be tweaked reasonably easily enough to produce
acceptable output.

Unfortunately for you, on the important syntaxic points, FASM
is _WAY_ closer to NASM than to MASM. So, go on, insane liar.

Having written a code generator for MASM and FASM, and having played
around with doing it for NASM (yup, check out some older source code
for HLA -- there used to be lots of IFDEF'd code for NASM in there), I
can state without hesitation that it's far easier to generate FASM
code from a MASM base than it is to generate NASM code. Superficially,
to *you* FASM might look closer to NASM than MASM, but where it counts
-- semantics -- FASM is an easier language to deal with from HLA's
perspective. When *you've* written a translator that takes RosAsm code
and produces FASM, MASM, and NASM output, come back and tell me about
how easy it all was. Oh, and make sure you write the MASM translator
*first*. We are talking, here, about modifying a MASM code generator
to produce FASM or NASM output.



GPL, PD, and other license issues had nothing to do with it. After
all, my first back-end was MASM.

Yes. We all know that the word "ethic" has no meaning counter-part
in your brain.

Spoken by the man who claims he'll say anything and do anything to
destroy another's reputation.


At one point, I did care to be able
to produce an HLA package that was freely distributable (free as in
beer), unencumbered by MASM (or TASM) EULAs. FASM provided that. Once
I had that, there was no need for NASM or any other assembler.

Don't twist the history, clown. Everybody knows of it: As long
as you were perfectly aware that the redistribution of MASM32
was illegal, as expressively stated in the EULA, you had no
choice but to protect your ass,

You are confusing MASM with Hutch's MASM32 package.
Though MASM32 is a convenient way for people to obtain the MASM
assembler, keep in mind (and quit twisting history) that HLA was
conceived and mostly written before the MASM32 package was ever
developed. Indeed, at the time, MASM was still a commercial product
that you could buy. It was the #1 assembler in use at schools, where
HLA was being targetted. MASM made the most sense. Your concept of
'ethics' (as in, anything you can say against Microsoft) had nothing
to do with the choice.

Also note that NASM wasn't a product at the time, only wishful
thinking on the net.


by 1) promoting MASM, and,

Actually, it was the fact that MASM was already in use at all the
schools that convinced me to go with MASM first. Had some other
assembler been the principal one, I would have used that other
assembler. You've got it backwards here.

2) by distributing with FASM... without any shame.

Distributing FASM is shameful? I think it's a pretty good product.
That's why I've built it into HLA. No shame in that.


Shame is
a feeling you completely ignore, isn't it?

I guess, for whatever bizarre definition of shame it is that you're
using.


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?
Are you saying that FASM's syntax is not closer to MASM's than NASM's
is to MASM?



3) It had automatic branch displacement (NASM still didn't at the time
I ported FASM as HLA's back end).

And then?
'
And then I had my freely distributable version.


4) FASM had on-going support.

Whereas... what?

NASM did not.



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?


(or
provide me with the macros to do the same tasks I needed when there
were some holes in FASM's capabilities).

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.
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.


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.

Mind you, when a user has given a try to
_ANY_ Assembler, you have no more any chance for selling your
bullshits to him. Didn't you switch your self-selling toward
beginners, the day you understood that no Asmer on earth would
ever admit that your HLL Preparser could be an Assembler?

Oh well.
Give your limited definition of what an "Asmer" is, I have no doubt of
this.



Why would I waste time on a side
project that doesn't help the HLA user base at all when I could be
doing something else such as developing the HLA stdlib v2.x or porting
HLA to FreeBSD? Those are useful projects that *will* improve the HLA
user base.

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

You've been given the links. You refuse to acknowledge them.
Oh well.
hLater,
Randy Hyde

.

Quantcast