Re: Release of RosAsm V.2.025a

Betov wrote:
> >
> > More than one pass, then?
>
> Well, if RosAsm Simplified Syntax is over your head,

Then the "simplification" must not be all that simple, considering Alex
is quite capable of dealing with more "complex" syntax, eh?

> i doubt
> that you could understand the explanations,

Sure.


> but, in case
> some readers would be interrested with the envolved Methods,
> here they are [Explanations supposing that the readers knows
> of what a Long of Short Jump, and Jumps Sizes Optimizations"
> - downward called "JSO" - are]:
>
> * All Assemblers i know about, that do JSO, do it by parsing
>   again and again, until all Jumps Scopes are resolved.

Yes, this is because branch displacement optimization is an NP-Complete
problem. Most assemblers don't really do true branch displacement
optimization (because compilation of a typical program would take
longer than the lifetime of the universe), so they use a greedy
algorithm instead. But the sample code I've given demonstrates some
issue why such an optimizer would take more than one pass.

>
> * RosAsm does it in one simple Computation, by analysing and
>   modifying the Tables in charge of storing the Declarations
>   and Evocations Reference.

Won't work in all cases. Period.

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

But doesn't work for a large number of cases.

> Of course,
> to achieve such a simple computation, in an Assembler Source,
> this requires, first, that the References Tables are correctely
> implemented since day one of the Developements.

And each time you change the lengths of your jump instructions, the
references all change, which could then cause other jump instructions
to change their size, which causes the references to change, which
could cause other jumps to change their size, which...  Sorry, a
multi-phase approach is the only solution here.


> With a traditional
> Implementation, this would be, evidently, impossible to do, as a
> "second thought", and ass-holes like our famous swindler, who
> claim to be experts in SoftWare design, have of course it easier
> by stating that this is impossible to do [Therefore the attack].

No. I had no idea that you did not truly implement branch displacement
optimization. I suspected there would be bugs in your implementation,
no doubt about that, but I didn't realize it was so broken. Too bad. It
would have been nice to actually *compare* the performance of your
assembler against the likes of MASM and FASM on an equal footing (as
they do branch displacement optimization properly). Too bad, we still
can't do that.

>
> Now, the reasons why i implemented this JSO:
>
> * It has always been planed as a "Last days Job", but everything
>   was ready for implenting this, in the same way that the "Unused
>   Symbols" Feature, - That Half implemented in two days... - was
>   ready to implement since day one.

Well, I guess the "last days" have not arrived yet, because you've
still not implemented branch displacement optimization. Your
implementation strategy is akin to that of your disassembler -- you
rush into coding without really understanding the problem and you wind
up with a solution that doesn't quite work right. And announce what a
"genius" you are for solving the problem that no one else could solve.
Sadly, you don't even realize that there are problems with your
approach.


>
> * The JSO is a no use feature, in an Assembler like RosAsm, where
>   the Jumps Sizes are entirely under the control of the Programmer.

I agree here. Your branch displacement optimization doesn't work
properly. So it's of little use to a RosAsm programmer.


>
> * It came out that some Assemblers (Namely FASM) use the JSO, as
>   a promotion argument, and that the beginners cannot understand
>   why this is nothing but a _promotion_ argument, with absolutely
>   nothing real behind, but a faultive implementation choice.

Sure, having the assembler handle the tedium is nothing but a
"promotion" argument. You may as well claim that having the assembler
convert mnemonics to machine opcodes is a "promotion" argument as well,
and make all your users type in hex opcodes. :-)


>
> * A recent extension to the RosAsm Macros capability achieved to
>   a point where it became wishable, for the Macros Developements,
>   to declare _all_ of the Conditional Jumps... Long.

No, it's "wishable" to have the assembler automatically pick the right
size for you. I've been telling you for years that forcing the user to
use those stupid "local labels" (which are forced to a short
displacement) in RosAsm was a bad idea. I guess you've finally figured
out *why* I've been making this claim.

> [It also became
>   evident that the users do _not_ like to have to make use of the
>   "...If" forms to take in charge the Sizes and the Levels of
>   imbrications of the HLL Constructs... So, at this point of the
>   various Developements, it was the right time to implement the
>   JSO, instead of waiting for the end of the Developements.

You've still got work to do, I'm afraid.


>
> * The way i choose to implement it, at a practical point of view
>   (for the user), was to make it as heavy and as noisy as possible,
>   as long as this is, first, a "Propaganda Argument".

And what have you been calling this?  "Chest-thumping?"

> I could have
>   made it silent, but i choosed to make it _visible_, through one
>   another Menu Item, that runs the compilation once, if the PE is
>   ready to Run, and _twice_, if the PE is not ready to run, in
>   order to save me from having any Error Case to implement in the
>   JSO Computations. Nevertheless, all of this, _is_ One Pass, and
>   the two compilations (with / without JSO) is about the same.

Uh, if they've got to run it a second time, that's a second pass. The
fact that you make the user manually do the second pass doesn't change
that fact.

>
> Now, the Method.
>
> When Encoding with the JSO wanted, i declare a Table of the
> same Size as the Encoded Code, where each Long Jump is "Flaged",
> to keep track of each possible occurence Location.
>
> Then, for the JSO Computation, i scan this table and keep only
> track of the negative and positive Displacements that could be
> made Short instead of Long.
>
> At that point, making a Long Jump Short is just a matter of
> overwriting and compacting the Declarations and Evocations
> Tables, and of compacting the Code Section. Quite trivial,
> but, as said above, this requires an implementation of the
> Assembler that is done since day one in a clever enough manner,
> so that 1) such Table could pre-exist and 2) could assume the
> manipulations.

Nothing amazingly clever about this. But it won't work without multiple
p***** over the code and table in question. And don't forget that
smaller jump instructions can change the size of *other* instructions,
too. E.g.,

add eax, (offset SomeLabel) - (offset SomeLabel2)

I'd be willing to bet that you don't even sup****t this facility in
RosAsm (as an assembler like MASM does), so maybe you wouldn't even be
able to optimize an instruction like this based on branch instruction
sizes. But other assemblers do.

>
> Notice that, as far as i can know, this is one more innovation
> coming with RosAsm, as i have never seen any Assembler doing
> the JSO that way,

No, it's one more example of a fundamental design flaw in your product.

> and that some ass-holes around said that
> this was impossible to do,

No doubt your scheme works for lots of simple examples; just like your
disassembler. But "theory" or otherwise, it's not going to produce the
shortest possible code in all cases. Now granted, *no* assembler
guarantees optimal code (it's too computationally intensive). But I'd
bet that assemblers like MASM and TASM produce *far* better code in
many non-trivial cases than does RosAsm.

> because the pretty Theorician
> had _proven_ that it was impossible.

Not impossible. Intractible.

> These ass-holes, just
> miss the point that the key of Assembly is the Strategy
> Optimization and that inventivity is way over any scolastic
> pedantism.

And the hacker/hobbyist assembler developer still doesn't realize why
his branch displacement optimization is inferior to other assemblers.
Cheers,
Randy Hyde