Re: Release of RosAsm V.2.025a

"randyhyde@[EMAIL PROTECTED]
" <randyhyde@[EMAIL PROTECTED]
> écrivait 
news:1126447973.199069.165040@[EMAIL PROTECTED]
> 
> Betov wrote:
>> 4) Yes, of course, in the "Multi-Pass-Emulation", all of
>>    the Tables (and the Code Section, and all) are entirely
>>    compacted, before scanning the Map Table again, in the
>>    Main Loop, which is a trivial as:
>>
>>     JmpsOptimize:
>>         call ScanShortenJmpsTable
>>
>>         While D$NumberOfLongToShort <> 0
>>             call CompactLabelListAndCodeRef
>>             call CompactCodeList
>>
>>             call CompactShortenJmpsTable
>>
>>             call ScanShortenJmpsTable
>>         End_While
>>     ret
>>
> 
> 
> 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."

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

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

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

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



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

That would be quite funny.

:)

Betov.

< http://rosasm.org
>