Re: Release of RosAsm V.2.025a

Betov wrote:
> >
> > Just for your information, this *is* a multi-pass algorithm. Your
> > argument that you're doing a single-pass is incorrect.
>
> Ass-hole, as it is one another, well know, good old trick
> of yours, to attribute to others, statements that never
> existed but in your diseased mind, i will just Copy&Paste,
> all of the sentences of mines, in the whole thread, having
> any relation****p with this discussion, at the attention of
> the readers. First the only words of the annoucement that
> fired the whole discussion:
>
> * Jumps Size Optimizations.
>
> :))))
>
> Then, all of the sentences of mines, where i did any usage of
> the "Multi-Pass" considerations (or similar considerations):
>
> * "And, if i may add, anyone wi****ng to develop an Assembler
>   doing Jumps Size Optimizations, - in one single and simple
>   additional Computation, taking almost no time , instead of
>   the traditional Multi-P***** -, can take a lesson from
>   RosAsm Source."

I think it was the line "in one Single and simple additional
computation", particularly the part about "single", where you make it
sound like you're making a single pass through the code. Now I
understand that English is not your primary language, but if you insist
on misusing the language and implying things you are not saying, then
you've got to take the abuse you're complaining about.


>
> * "In other words, the traditional Multi-Pass thingie, is
>   "emulated" by a flow of calculations, that take almost
>   no time."

And this is wrong. They *do* take time. They take a lot of time.
Granted, you may save some time over some assemblers that insist on
re-scanning the source file; but most smart (professional level)
assemblers like Gas and MASM don't do this. They create an intermediate
form (much like you're doing, and as HLA v2.0 is doing) and work on
that. Congratulations. You're actually doing something here that the
big boys do.  To bad (see another post of mine in this thread) that
you've still got a few kinks to work out.



>
> * "There is another logical way, boy, but implementing
>   the Optimization Multi-Pass is the simplest way"

There are lots of additional ways to do it. What do you think? You've
cornered the market on branch displacement algorithms?

>
> * "On a News Group devoted to Assembly and Assemblers,
>   i am founded to presume that the readers are supposed
>   to have heard of the differences between Mono-Pass and
>   Multi-Pass(ses) Assemblers"

Why would you assume this? The fact that you can expect most people
around here to *use* an assembler does *not* imply that they understand
the internal operation. Indeed, you've used this fact in the past to
make all kinds of ridiculous statements knowing that most people
wouldn't catch you in such claims.


>
> * "There is no magic, in the method. The Multi-Pass is just
>   _emulated_ by the Tables calculations"

You are making multiple p***** through an encoding of the source file.
No, you're not processing the original source file (and few
professional level assemblers would do this), but you are making
multiple p***** through some representation of the source file. Trying
to claim that this is not "multi-pass" is either ignorance on your
part, or an intellectually dishonest attempt to make it seem like you
are doing something special that no other assemblers do. You could
claim that you don't read the *original source* file multiple times but
you cannot claim that this is a single pass algorithm.

>
>
>
> > Indeed, if I interpret the above correctly, this is a typical O(n**2)
> > algorithm with the limitation (and not a bad one, I might point out)
> > that once a branch is shortened, it is never again considered (that
is,
> > you won't lengthen it once it has been shortened).  Fast, but doesn't
> > guaranteed optimal code (and no *tractible* algorithm will guaranteed
> > optimal code, so again, this limitation isn't that bad).
>
> Ass-hole, too bad that you could not implement, in your HLL
> Pre-Parser, written in Flex, Bison, and C, an Optimization
> that would turn the Short Jumps Long, as long as your HLL Pre-
> Pareser written in Flex Bison, and C, has no control on what
> the obfuscated back-end Assembler does with the passed-down
> Source:

???
The reason I require certain assembler for use as the HLA v1.x back end
is because they provide this facility already. Why waste time
reinventing the wheel if my back-end does this for me already?

But fear not, HLA v2.0 is certainly going to sup****t this feature
(indeed, that's the next thing I'm working on). And HLA v2.0 uses a
"multi-phase segmented algorithm" to really speed things up. It also
uses a "start small, extend long" algorithm to produce better results
(usually much faster) than the "start long, optimize small" approach
that RosAsm uses.

So complain all you want about HLA v2.0. But if I were you, I'd get
busy and fix your code because you wouldn't want HLA v2.0 to beat it
when HLA v2.0 appears now, would you?
Cheers,
Randy Hyde