Release of RosAsm V.2.025a
Betov
* New version of the Equal Pre-Parser.
* New release of the Disassembler, with first implementation
of Map File.
* New release of the Debugger. Review of the WatchPoints, of
the Interface (ToolBar,...)
* Review of the Conditinal Macros, with generalisation of the
'#N' Key.
* Jumps Size Optimizations.
* Enable multiple Clip Files.
* Restart the LibScanner from scratch
* Implement the Tag Menu ID (for Instant Edition).
* New version of the Form Wizard, with Treeview display for
styles, Grid, ...
* Assembler: Speed-up pre-computation of the nested Equates.
Up to 25% saved on files making some heavy usage of
imbricated Equates (Typically OOP Style).
_____________________________________
RosAsm is a Bottom-Up PEs Assembler for ReactOS (ReactOS,
WINE, Windows 95/98, NT/2000, XP,...). It is a free, GPLed,
auto-compilable Assembler, and is the only Assembly
Environnement coming with full integration of all its
components:
* Assembler: The fastest of the actual assemblers, (1.5
Mega/second on a Celeron 1.3 Ghz...) directly outputting
PE files on a simple click, with a very powerful macros
system (a macros unfolder is available by a double-click,
through a float menu). Simplified Intel syntax. Does not
need any include, prototype or header companion file.
Nothing but a single simple source. Complete implementation
of the mnemonics set, up to SSE2. RosAsm Bottom-Up Assembler
is a true low level Assembler, enabling HLL writing styles
by user defined macros and/or by HLL pre-parsers selections.
* Disassembler: To date, RosAsm is the one and only two-clicks-
disassembler-reassembler ever seen. It is, actually, fully
effective on most small files and on many middle size
applications: The dream tool for study and/or for porting
your works to assembly.
* Debugger: Source level Debugger with a state-of-the-art
memory inspector and very advanced features, like the
dynamic break-points, that can be set/removed by simple
clicks, as well as at write-time and/or at run-time, like
with the most advanced HLLs. To run the Debugger, You
simply click on [Run] and your application is running
through the debugger. Any error (or watch-points, or
break-point, enabling advanced stepping modes) is pointed
out directly in your source code. Accurate messages are
delivered on errors cases.
* Sources Editor: Real Sources Editor with tons of unique
features, specificaly devoted to secure editions and to
huge mono-files assembly sources: Tree-view, instant
jump to any type of declaration by simple right-click,
division of the mono-files into TITLEs, advanced
IncIncluder pre-parser, and so on...
* Resources Editors: Original Resources Editors, with
control of matching styles, outputting as well resources,
files, and memory templates.
* Wizard for visual design.
* Clip file system, for templates reuse.
* Integrated OS Equates, and Structures files, saving from
any boring include.
* Integrated Help system, with a complete 32 bits Assembly
Tutorials, Opcode help, and RosAsm Manual (1.5 mega of
documentation, grouping close to 600 organised rtf files).
... and much more...
Betov.
rand...@earthlink.net
Betov wrote:
>
> * Jumps Size Optimizations.
>
This might be a cool feature and welcome addition to RosAsm if it
actually worked. I assume that choosing "Optimize Jump Sizes" from the
compile menu is how you activate this feature (sorry, but all the
documentation says is that you don't support branch size optimization,
no other instructions on it's use). Cut and paste the following test
code into a simple RosAsm program:
jmp lbl1; // 2/6 bytes
jmp lbl2;
jmp lbl3;
jmp lbl4;
jmp lbl5;
jmp lbl6;
jmp lbl7;
jmp lbl8;
jmp lbl9;
jmp lbl10;
jmp lbl11;
jmp lbl12;
jmp lbl13;
jmp lbl14;
jmp lbl15;
jmp lbl16;
jmp lbl17;
jmp lbl18;
jmp lbl19;
jmp lbl20;
jmp lbl21;
jmp lbl22;
jmp lbl23;
jmp lbl24;
jmp lbl25;
jmp lbl26;
nop;
nop;
nop; // The "Magic" NOP.
lbl1:
nop; nop; nop; nop; nop;
lbl2:
nop; nop; nop; nop; nop;
lbl3:
nop; nop; nop; nop; nop;
lbl4:
nop; nop; nop; nop; nop;
lbl5:
nop; nop; nop; nop; nop;
lbl6:
nop; nop; nop; nop; nop;
lbl7:
nop; nop; nop; nop; nop;
lbl8:
nop; nop; nop; nop; nop;
lbl9:
nop; nop; nop; nop; nop;
lbl10:
nop; nop; nop; nop; nop;
lbl11:
nop; nop; nop; nop; nop;
lbl12:
nop; nop; nop; nop; nop;
lbl13:
nop; nop; nop; nop; nop;
lbl14:
nop; nop; nop; nop; nop;
lbl15:
nop; nop; nop; nop; nop;
lbl16:
nop; nop; nop; nop; nop;
lbl17:
nop; nop; nop; nop; nop;
lbl18:
nop; nop; nop; nop; nop;
lbl19:
nop; nop; nop; nop; nop;
lbl20:
nop; nop; nop; nop; nop;
lbl21:
nop; nop; nop; nop; nop;
lbl22:
nop; nop; nop; nop; nop;
lbl23:
nop; nop; nop; nop; nop;
lbl24:
nop; nop; nop; nop; nop;
lbl25:
nop; nop; nop; nop; nop;
lbl26:
With the "Magic" NOP in the code, each jump instruction should be five
bytes long. With the "Magic" NOP commented out, each jump instruction
should be two bytes long. When I disassemble your code (after using
the "optimize jump sizes" option), with the magic NOP missing, it shows
that all the jumps are five bytes long, with displacement values that
are less than $80.
I suspect you've not tested this feature very well as it doesn't seem
to produce results any different from a standard compilation. Then
again, with no documentation on its use, perhaps I'm doing it wrong.
Feel free to enlighten me if this is the case.
Cheers,
Randy Hyde
P.S. Looking forward to the "this is an insane program and nobody
writes code this way, so this is not a bug and I won't fix it..."
response we've come to expect from you.
rand...@earthlink.net
Excuse me, the syntax above is for HLA, which I used to get the code
working to verify the size optimizations. Substitute a "|" for the ";"
symbols between the nops. Sadly, even with only one NOP per line,
RosAsm doesn't seem to be generating the smaller jumps, which should
have been a no brainer.
Sorry,
Randy Hyde
Betov
news:1126241564.1...@g44g2000cwa.googlegroups.com:
Ass-hole, anyone wishing to see the effect of the Jumps
Size Optimizations can easily create of CopyOfRosAsm.exe,
recompile it with the Optimization, and read both sizes.
And, if i may add, anyone wishing to develop an Assembler
doing Jumps Size Optimizations, - in one single and simple
additional Computation, taking almost no time , instead of
the traditional Multi-Passes -, can take a lesson from
RosAsm Source.
One more enlightning innovation on the RosAsm side.
Betov.
Alex McDonald
>
> And, if i may add, anyone wishing to develop an Assembler
> doing Jumps Size Optimizations, - in one single and simple
> additional Computation, taking almost no time , instead of
> the traditional Multi-Passes -, can take a lesson from
> RosAsm Source.
>
Backward jumps are trivial; the distance is known because the code has
been generated. But how do you assess the jump distance for forward
jumps without a second pass? This;
jmp B
...code...
jmp A
...code...
B: ...code...
A: ...code...
requires that the jump to B is dependant on the length of the jump to A
opcode. Can you describe how you optimise this in one pass?
--
Regards
ALex McDonald
Betov
@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com:
Before giving any kind of credit to the insanities of our
famous swindler, Alex, you'd better take a look at how the
things are implemented in RosAsm Source, by following, for
example, the 'ShortenJumpsWanted' Flag, with the various
Double-Click and Right-Click Features.
You would then see that the Optimizations are done backward
and forward.
You would also see that these optimizations apply upon the
Jcc Instructions, which are, at a logical point of view, the
only one where this kind of Optimization can have any real
effect.
Plus, if you knew a bit of 1) RosAsm Syntax, and of 2) the
PE format, you would know that the size of a PE cannot be
reduced under the range of the File Alignment Sections, and
that RosAsm _never_ implements Short Jumps on Plain Labels,
which would not make any sense, but only on Local Labels.
Betov.
Alex McDonald
I'm afraid that I find the RosAsm syntax quite difficult, and I'm not
sure I know where to look in the source for the routine that does this.
I was looking for a brief description of how you did it, not the code
itself.
>
> You would then see that the Optimizations are done backward
> and forward.
More than one pass, then?
>
> You would also see that these optimizations apply upon the
> Jcc Instructions, which are, at a logical point of view, the
> only one where this kind of Optimization can have any real
> effect.
IF/THEN/ELSE generates one Jcc and one JMP instruction;
IF: test, jcc ELSE:
THEN section
JMP ENDIF
ELSE: ELSE section
ENDIF:...
Will either get optimised? The JMP ENDIF could be a short jump.
>
> Plus, if you knew a bit of 1) RosAsm Syntax,
No, not comfortable with it.
> and of 2) the
> PE format, you would know that the size of a PE cannot be
> reduced under the range of the File Alignment Sections,
The question was more about how RosAsm does it in one pass, not whether
it was worth doing from the perspective of size or performance.
> and
> that RosAsm _never_ implements Short Jumps on Plain Labels,
> which would not make any sense, but only on Local Labels.
What are plain labels and local labels?
--
Regards
Alex McDonald
Betov
@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com:
Well, if RosAsm Simplified Syntax is over your head, i doubt
that you could understand the explanations, 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.
* RosAsm does it in one simple Computation, by analysing and
modifying the Tables in charge of storing the Declarations
and Evocations Reference.
In other words, the traditional Multi-Pass thingie, is "emulated"
by a flow of calculations, that take almost no time. 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. 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].
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.
* The JSO is a no use feature, in an Assembler like RosAsm, where
the Jumps Sizes are entirely under the control of the 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.
* 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. [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.
* 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". 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.
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.
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, and that some ass-holes around said that
this was impossible to do, because the pretty Theorician
had _proven_ that it was impossible. 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.
Betov.
Alex McDonald
>
> 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.
C: ...code...
jmp A
jmp B
...code...
jmp B
A: ...code...
jmp C
B: ...code...
jmp A
(The jumps could be jcc or jmp; I've just shown jmp.)
Do you compact from top to bottom, or bottom to top?
Any jump you didn't compact first time round might now be compactable;
do you try to re-compact after the first pass? For instance, the first
jmp B may be too far away first time, but close enough once other jumps
later on have been compacted.
Each time you compact a jump, the labels elsewhere in the code move. For
instance, compacting the first jump causes A and B to move, and _all_
the jumps need recaculated. The same is true of the second. How do you
tell that A and B have moved? How do you recalculate the jump offsets?
>
> 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,
The technique is not new; peephole optimisers that do this have been
around for many years. It might be the only assembler that does this.
> and that some ass-holes around said that
> this was impossible to do, because the pretty Theorician
> had _proven_ that it was impossible. 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.
You're not optimising fully, hence you don't hit the problem (as far as
I can see) because of the limited optimisation you're doing.
--
Regards
Alex McDonald
rand...@earthlink.net
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
passes 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 support 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
rand...@earthlink.net
Alex McDonald wrote:
>
> C: ...code...
> jmp A
> jmp B
> ...code...
> jmp B
> A: ...code...
> jmp C
> B: ...code...
> jmp A
>
> (The jumps could be jcc or jmp; I've just shown jmp.)
>
> Do you compact from top to bottom, or bottom to top?
I bet he doesn't even understand what you're talking about and why it
makes a difference.
>
> Any jump you didn't compact first time round might now be compactable;
> do you try to re-compact after the first pass? For instance, the first
> jmp B may be too far away first time, but close enough once other jumps
> later on have been compacted.
He doesn't seem to understand this.
Worse, wait until he learns that *optimal* code may require certain
jumps to be long, even though they jump only a short distance, in order
to minimize the size of several other jumps. Admittedly a rare case,
and mostly a degenerate case, but a case nonethless; few assemblers I'm
aware of handle this case [because this is the case that leads to
intractibility], but I still bet that he's not even aware that this
situation exists.
>
> Each time you compact a jump, the labels elsewhere in the code move. For
> instance, compacting the first jump causes A and B to move, and _all_
> the jumps need recaculated. The same is true of the second. How do you
> tell that A and B have moved? How do you recalculate the jump offsets?
He doesn't. That much is clear. With one pass he can optimize the jumps
whose displacements are immediately optimizable, and that's it. Unless
he doesn't understand what a "pass" is.
>
> >
> > 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,
>
> The technique is not new; peephole optimisers that do this have been
> around for many years. It might be the only assembler that does this.
Not even the only assembler.
Gas works this way (though it does it correctly).
>
> You're not optimising fully, hence you don't hit the problem (as far as
> I can see) because of the limited optimisation you're doing.
Obviously he is not.
Cheers,
Randy Hyde
Betov
@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com:
> Each time you compact a jump, the labels elsewhere in the code move.
Of course. Don't you understand the word 'emulating'?
There is no magic, in the method. The Multi-Pass is just
_emulated_ by the Tables calculations, and after one
"compacting" is done, the Map Table (where the Long
Displacements are "Flaged"), is scan again, for new
possible Long Jumps that could be made shorter, as it
says in:
While D$NumberOfLongToShort <> 0
... Too bad that you can't read.
:))
Betov.
Betov
news:1126269249.7...@g47g2000cwa.googlegroups.com:
>> * 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.
Ass-hole, all the things, i wrote above, are at the
intention of the occasional readers, who could be more
interrested with innovation for such an implementation,
than with your smoking pedantism.
:)
Betov.
Alex McDonald
> Alex McDonald <alex...@btopenworld.com> écrivait news:dfruf9$ojr$1
> @nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com:
>
>
>>Each time you compact a jump, the labels elsewhere in the code move.
>
>
> Of course. Don't you understand the word 'emulating'?
Yes. That was a statement. The questions were;
How do you tell that A and B have moved?
How do you recalculate the jump offsets?
I did have a spot of bother with the words below though;
>
> There is no magic, in the method. The Multi-Pass is just
> _emulated_ by the Tables calculations, and after one
> "compacting" is done, the Map Table (where the Long
> Displacements are "Flaged"), is scan again, for new
> possible Long Jumps that could be made shorter, as it
> says in:
>
> While D$NumberOfLongToShort <> 0
So it's "emulating" multi-pass? By doing more than one pass?
> ... Too bad that you can't read.
My reading's fine, thanks. What I'm trying to understand is how it does
it (the algorithm), not how it's implemented (RosAsm). You're
explanation isn't informative as a consequence. I'll try again;
RosAsm builds a parallel table to the code it's optimising (actually,
it's just a chunk of memory the same length as the generated code with
flags and branch offsets). This table contains information about the
jumps _only_. Meanwhile, somewhere in the symbol table are the labels.
They contain offsets or pointers into the generated code.
When the code generation is complete (presumably for a procedure only; I
don't think you can be globally optimising), there is interaction
between the parallel table and the symbol table.
Each time you compact a jump, the labels elsewhere in the code move. How
do you tell that A and B have moved? Do you update the symbol table? How
do you recalculate the jump offsets? Are they all recaculated on every
pass? Do you pass the table from bottom to top, or top to bottom?
--
Regards
Alex McDonald
Betov
@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com:
>> ... Too bad that you can't read.
>
> My reading's fine, thanks. What I'm trying to understand is how it does
> it (the algorithm), not how it's implemented (RosAsm). You're
> explanation isn't informative as a consequence. I'll try again;
>
> RosAsm builds a parallel table to the code it's optimising (actually,
> it's just a chunk of memory the same length as the generated code with
> flags and branch offsets). This table contains information about the
> jumps _only_. Meanwhile, somewhere in the symbol table are the labels.
> They contain offsets or pointers into the generated code.
>
> When the code generation is complete (presumably for a procedure only;
I
> don't think you can be globally optimising), there is interaction
> between the parallel table and the symbol table.
>
> Each time you compact a jump, the labels elsewhere in the code move.
How
> do you tell that A and B have moved? Do you update the symbol table?
How
> do you recalculate the jump offsets? Are they all recaculated on every
> pass? Do you pass the table from bottom to top, or top to bottom?
Let me tell you that it sounds a bit strange to me, that you
could ask questions about the details of the Implementation,
whereas the Source is GPLed, extreemely readable, and offered
in the context of an IDE where pointing anything out is always
a matter of "Click"...
1) The Map Table (parallele to the Code Section) holds nothing
but 0 and 1. ['1' at each Location, where a Long Displacement
has been Encoded].
2) When Encoding, RosAsm manages several separated Tables. For
examples, the Labels Table, the Equates Table, and so on...
It also manages a References Table, that holds the various
references encounted while encoding the Instructions, and
the real Displacements are only written at the very end of
all computations (even later than the JSO thingies).
3) Therefore, analysing if a Long Jump could be made short
is just a matter of analysing the substraction of the
Evocation Reference by the Declaration (Label Table...)
Reference.
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
But, maybe, you are going to ask me to discribe what is
called, exactely... For the one interrested by the method,
the Source is provided, and for the ones not able to read
RosAsm unified and simplified Syntax, go and play football.
Betov.
Betov
news:1126269552.3...@o13g2000cwo.googlegroups.com:
> I bet he doesn't even understand what you're talking about and why it
> makes a difference.
> ...
> He doesn't seem to understand this.
> ...
> He doesn't.
> ...
> Not even the only assembler.
> ...
> Obviously he is not.
Congratulation, ass-hole: Your arrogancy succeeds
to amaize me, one more time.
I must apologize that, from an unsignificant clown,
unable to do anything but to write an HLL Pre-Parser
with Flex, Bison and C, your insane attacks against
a product, that is way over your head, are quite
impressive.
:)
Betov.
Paul Dunn
Yes, but he does seem to understand where and how you're going wrong with
your little assembler. Alex also seems to understand it better than you are
doing - I suspect a langage barrier thing going on here.
Betov
news:_IhUe.5912$oq4....@newsfe5-win.ntli.net:
Hopefully for Master Pdf, Paul, there really exists
guys like you. What is one another amaizing thing,
on an Assembly News Group, but on that point, our
famous swindler might be right on, when betting on
stupidity.
:)
Betov.
Paul Dunn
> Hopefully for Master Pdf, Paul, there really exists
> guys like you.
I doubt it - I'm not real, just a figment of your imagination :-)
> What is one another amaizing thing,
> on an Assembly News Group, but on that point, our
> famous swindler might be right on, when betting on
> stupidity.
This is exactly what I mean. I think that your being french and Randy being
american is conflicting somewhat - while you mean one thing, it comes across
as something else, and when Randy says something you mis-translate and fly
off the handle somewhat.
For example, when you say "single pass optimisation" you really mean (at
best) "peephole optimisation", or "multiple pass optimisation" since that's
what your explanations seem to describe. What Randy means by "single pass
optimisation" is that you start from one end of the source, step through
each instruction, optimise where you can and then finish. No backtracking,
no jumping around the source etc. Your table sounds awfully like you're
doing some jumping around, optimising when the chances to do so become
available. In that way, you can do a lot more, and better, optimisation than
a single pass ever could.
Alex McDonald
>
> Let me tell you that it sounds a bit strange to me, that you
> could ask questions about the details of the Implementation,
> whereas the Source is GPLed, extreemely readable, and offered
> in the context of an IDE where pointing anything out is always
> a matter of "Click"...
Well, I've looked at it, and I'm none the wiser. Let's leave it there;
the syntax of RosAsm has defeated me (along with the lack of comments),
and the description you give of how it does the work hasn't cleared it
up. The learning curve is too steep and long for me to work out what
technique you're using. It's not that important anyhow.
>
> But, maybe, you are going to ask me to discribe what is
> called, exactely... For the one interrested by the method,
> the Source is provided, and for the ones not able to read
> RosAsm unified and simplified Syntax, go and play football.
That'll be most people playing football, I suspect.
--
Regards
Alex McDonald
Betov
news:GJiUe.5259$zw1....@newsfe2-gui.ntli.net:
> This is exactly what I mean. I think that your being french and Randy
> being american is conflicting somewhat - while you mean one thing, it
> comes across as something else, and when Randy says something you
> mis-translate and fly off the handle somewhat.
>
> For example, when you say "single pass optimisation"
I did not make any usage of this expression.
> you really mean
> (at best) "peephole optimisation", or "multiple pass optimisation"
> since that's what your explanations seem to describe.
Then, if this is what my explanation describe, why are
you saying that i am saying otherwise?
> What Randy means
> by "single pass optimisation" is that you start from one end of the
> source, step through each instruction, optimise where you can and then
> finish. No backtracking, no jumping around the source etc.
What a nobody like Master Pdf can say has the exact
value of _zero_.
> Your table
> sounds awfully like you're doing some jumping around, optimising when
> the chances to do so become available. In that way, you can do a lot
> more, and better, optimisation than a single pass ever could.
There is another logical way, boy, but implementing
the Optimization Multi-Pass is the simplest way, at
an implementation point of view, and as it does not
take any real time in the whole Compilation Process,
i keep happy with it.
Betov.
Paul Dunn
> "Paul Dunn" <paul....@ntlworld.com> écrivait
> news:GJiUe.5259$zw1....@newsfe2-gui.ntli.net:
>> For example, when you say "single pass optimisation"
> I did not make any usage of this expression.
No, what you actually said is:
"And, if i may add, anyone wishing to develop an Assembler doing Jumps Size
Optimizations, - in one single and simple additional Computation, taking
almost no time , instead of the traditional Multi-Passes -, can take a
lesson from RosAsm Source."
Which I kind of took to mean that you (having written the rosasm source) had
implemented a single-pass jump optimisation routine - when you say "instead
of traditional multi-passes" then that indicates that you don't so multiple
passes, which leaves you only one pass to do it in. Single-pass, if you
will.
Apologies if my reading isn't up to scratch there.
>> you really mean
>> (at best) "peephole optimisation", or "multiple pass optimisation"
>> since that's what your explanations seem to describe.
>
> Then, if this is what my explanation describe, why are
> you saying that i am saying otherwise?
See above - I honestly thought you were claiming one thing and then *doing*
another. I now see that you meant something completely different and the
rest of us, in our ignorance, didn't quite understand what you meant. I
really do think that a lot of your blowing off is just the result of this
language barrier that you're fighting against. Still, your English is
doubtless better than my French, so I shall try harder in future.
> What a nobody like Master Pdf can say has the exact
> value of _zero_.
I think we can dismiss that as having no relevance.
>> Your table
>> sounds awfully like you're doing some jumping around, optimising when
>> the chances to do so become available. In that way, you can do a lot
>> more, and better, optimisation than a single pass ever could.
>
> There is another logical way, boy,
Thanks :-)
At my age, that's quite the compliment.
> but implementing
> the Optimization Multi-Pass is the simplest way, at
> an implementation point of view, and as it does not
> take any real time in the whole Compilation Process,
> i keep happy with it.
And so you should! The simplest way is often the best, and if it works then
why fix it? Common sense, no?
Betov
@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com:
> [...]
You know, i don't discuss with you in any hope that
you could have the required intelligency, competency
and intellectual honnesty: I well know that you are
just a troll.
The only real thing that matters to me, here, is that,
after one another insane attack of Master Pdf against
RosAsm, about one of the new things in the last release,
his level of stupidity could be made public one more
time.
So, all of the neo-nazi friends of Master Pdf can come
along and simulate not understanding a word about my
explanations, their own stupidities will have the hard
time at obfuscating reality, and i have just played
with you, above, like a grand'pa with a child.
:)
Same has it always been, for each RosAsm innovation,
like with the famous "RosAsm Symbols Table Bug", the
attacks against the Two-Clicks-Disassembler-ReAssembler,
against the speed of RosAsm, against its security in
Developement, against its unified and simplified Syntax
and so on..., and so on..., so that i can now rely quietly
on the attacks to make the facts public, which are that:
* RosAsm Symbols Table is a Model to take for any such job.
* RosAsm Two-Clicks-Disassembler-ReAssembler is the first
ever seen such Tool.
* RosAsm is the most secure Environnement ever seen in
matter of Assembly Developements.
* RosAsm Syntax is the very cleanest ever seen around.
* RosAsm is the fastest of the actual Assemblers.
Not all readers are not completely stupid, mind you, and
facts are robust enough to resist by themselves.
:)
Betov.
Betov
news:4kjUe.5264$zw1....@newsfe2-gui.ntli.net:
>> Then, if this is what my explanation describe, why are
>> you saying that i am saying otherwise?
>
> See above - I honestly thought you were claiming one thing and then
> *doing* another. I now see that you meant something completely
> different and the rest of us, in our ignorance, didn't quite
> understand what you meant. I really do think that a lot of your
> blowing off is just the result of this language barrier that you're
> fighting against. Still, your English is doubtless better than my
> French, so I shall try harder in future.
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, which is the acception in
which i made use of this formulation. That is, what
is Mono-Pass, is the Assembler Encoder. For the computation
in charge of the JSO, it is, evidently executed as many
times as needed until no more "Long to Short" possible
case could be found.
Would this additional Computation be made default, in
RosAsm Assembler, the whole Assembler would remain
Mono-Pass, and the Compilation speed would remain the
same, with this emulation.
Betov.
Alex McDonald
> Alex McDonald <alex...@btopenworld.com> écrivait news:dfsdj4$6d0$1
> @nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com:
>
>
>>[...]
>
>
> You know, i don't discuss with you in any hope that
> you could have the required intelligency, competency
> and intellectual honnesty: I well know that you are
> just a troll.
>
> The only real thing that matters to me, here, is that,
> after one another insane attack of Master Pdf against
> RosAsm, about one of the new things in the last release,
> his level of stupidity could be made public one more
> time.
>
> So, all of the neo-nazi friends of Master Pdf can come
> along and simulate not understanding a word about my
> explanations, their own stupidities will have the hard
> time at obfuscating reality, and i have just played
> with you, above, like a grand'pa with a child.
Given the opportunity to explain (and remember this; it was in response
to your advertisment of the feature), you point me at the source code! 3
megas of it, to use your words. This isn't an explanation, it's an
obfuscation. You can't explain in simple terms what the code does,
I don't want to spend the next six weeks learning RosAsm's syntax --
which is quite unlike any assembler I've come across before -- and now
I'm a neo-Nazi troll. So be it. Hey, here's a thought you might like to
recycle:
"The only real thing that mattars to me, after insane attacks by BlotOv
against all who oopose the new things in the last release, and
no-advertise specimin code that is the cleanest all around, his
stupidity will be made public all around.
So, all of the anarchist friends of ButtOff can come along and simulate
understanding a word about your Explanations, their own Stupidities will
have the hard time at understanding reality (all of Two-Clicks thingies
and syntax that ButtUp has Developemented), and I have just played with
you, below, like a child tugging the beard with a grand'pa."
You're intoxicated with the sound of your own Ideas and Thingies TwoClicks.
> Same has it always been, for each RosAsm innovation,
> like with the famous "RosAsm Symbols Table Bug", the
> attacks against the Two-Clicks-Disassembler-ReAssembler,
> against the speed of RosAsm, against its security in
> Developement, against its unified and simplified Syntax
> and so on..., and so on..., so that i can now rely quietly
> on the attacks to make the facts public, which are that:
>
> * RosAsm Symbols Table is a Model to take for any such job.
>
> * RosAsm Two-Clicks-Disassembler-ReAssembler is the first
> ever seen such Tool.
>
> * RosAsm is the most secure Environnement ever seen in
> matter of Assembly Developements.
>
> * RosAsm Syntax is the very cleanest ever seen around.
>
> * RosAsm is the fastest of the actual Assemblers.
>
> Not all readers are not completely stupid, mind you, and
> facts are robust enough to resist by themselves.
>
Thank the lord; we couldn't have it any other way, could we? Like for
instance, advertising features you can't even explain.
--
Regards
Alex McDonald
Paul Dunn
> 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, which is the acception in
> which i made use of this formulation. That is, what
> is Mono-Pass, is the Assembler Encoder. For the computation
> in charge of the JSO, it is, evidently executed as many
> times as needed until no more "Long to Short" possible
> case could be found.
Thanks, that's a little clearer. It's definitely a language thing then. So
to sum up, Rosasm has the ability to assemble in a single pass, but takes as
many passes as necessary to do the job.
> Would this additional Computation be made default, in
> RosAsm Assembler, the whole Assembler would remain
> Mono-Pass, and the Compilation speed would remain the
> same, with this emulation.
Can you explain to me what you mean by the term "emulation"? I have my own
ideas of what it means, but as has been the case before now, my
understanding is likely to be different to yours. By "emulation", I take it
to mean a process that behaves like a system, produces the same results as
that system, but comes to those results by a different method than that
system would employ. If a process uses the same methods as that system then
I take it to be a "simulation" rather than an "emulation".
(This is mostly because of my background in writing emulations of the Z80
processor, which behave like a real Z80 would, but obviously don't perform
the functions at the level of gates and signal routes through the
processor - they take the opcodes and produce the results of that opcode
through calculations).
Thanks.
Betov
@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com:
> Given the opportunity to explain (and remember this; it was in response
> to your advertisment of the feature), you point me at the source code!
3
> megas of it, to use your words. This isn't an explanation, it's an
> obfuscation. You can't explain in simple terms what the code does,
Thanks for having given me the oppotunity to explain to the
eventualy interrested readers, what the RosAsm JSO was about
and how and where to read more in RosAsm Source, Troll.
:)
... And, again, [Not for you, Troll], for the ones interrested,
just follow-up, by Search / Right-Click / Double-Left-Click,
the 'ShortenJumpsWanted' Symbols, for reading the concerned
parts of the Source. For example, you Double-Left-Click upon
'ShortenJumpsWanted', and choose [Search from Top], and from
the new Location, use Right-Click for moving across the
Routines of interrest.
:)
Betov.
sevagK
Betov wrote:
> While D$NumberOfLongToShort <> 0
>
> ... Too bad that you can't read.
>
> :))
>
> Betov.
>
No, no. That's not it at all. The problem is your tendency to make up
words that have meaning only to you in your vain attempt to make others
sound stupid so that you can then go on and insult them for not being
able to understand.
Paul obviously understands this tendency in you and wants to make sure
you're both on the same wavelength before proceeding. But since you
again
failed to impress anyone except yourself, you resorted to your insults
anyways.
On another note, congratulations on finally implementing the jump table
optimizations after Randall showed that RosAsm lacked this ability and
suffered because of it (even if you didn't do a complete job of it, we
have come to expect half finished features in RosAsm).
You can thank Randy for influencing yet another inovation for RosAsm
which may soon be able to match features with the other assemblers.
By the way, no one is going to buy your nonesence that this was
"planned
since day one."
-sevagK
www.geocities.com/kahlinor
Betov
@g49g2000cwa.googlegroups.com:
> On another note, congratulations on finally implementing the jump table
> optimizations after Randall showed that RosAsm lacked this ability and
> suffered because of it (even if you didn't do a complete job of it, we
> have come to expect half finished features in RosAsm).
> You can thank Randy for influencing yet another inovation for RosAsm
> which may soon be able to match features with the other assemblers.
> By the way, no one is going to buy your nonesence that this was
> "planned
> since day one."
You should stop smoking the curtains.
Betov.
rand...@earthlink.net
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.
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).
Cheers,
Randy Hyde
Betov
news:1126447973.1...@g47g2000cwa.googlegroups.com:
>
> 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 relationship 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 wishing to develop an Assembler
doing Jumps Size Optimizations, - in one single and simple
additional Computation, taking almost no time , instead of
the traditional Multi-Passes -, 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.
rand...@earthlink.net
long, optimize short" algorithm for branch displacement optimization.
This scheme has the advantage that if you ever prematurely stop during
the optimization process, the program will still run correctly.
However, this algorithm often produces results that are not as optimal
as they could be.
Consider the following (HLA) code:
program t;
#include ("stdlib.hhf")
static
lblCnt :uns32;
begin t;
B0: jmp L0;
B1: jmp L1;
B2: jmp L2;
B3: jmp L3;
B4: jmp L4;
B5: jmp L5;
B6: jmp L6;
B7: jmp L7;
B8: jmp L8;
B9: jmp L9;
B10: jmp L10;
B11: jmp L11;
B12: jmp L12;
B13: jmp L13;
B14: jmp L14;
B15: jmp L15;
B16: jmp L16;
B17: jmp L17;
B18: jmp L18;
B19: jmp L19;
B20: jmp L20;
B21: jmp L21;
B22: jmp L22;
B23: jmp L23;
B24: jmp L24;
B25: jmp L25;
// Magic statement
jmp L26;
L0: jmp B0;
L1: jmp B1;
L2: jmp B2;
L3: jmp B3;
L4: jmp B4;
L5: jmp B5;
L6: jmp B6;
L7: jmp B7;
L8: jmp B8;
L9: jmp B9;
L10: jmp B10;
L11: jmp B11;
L12: jmp B12;
L13: jmp B13;
L14: jmp B14;
L15: jmp B15;
L16: jmp B16;
L17: jmp B17;
L18: jmp B18;
L19: jmp B19;
L20: jmp B20;
L21: jmp B21;
L22: jmp B22;
L23: jmp B23;
L24: jmp B24;
L25: jmp B25;
L26:
end t;
If all of these statements are encoded as short jumps (even several
more, in fact), then all the branches are within range. However, if
they are all encoded as far branches, then no single displacement will
be within the +/- 128 byte range allowed by a single-byte displacement.
The problem with starting long and optimizing short is that an
assembler that scans through these instructions encoded long will never
see the opportunity to optimize these jumps -- they are all out of
range as far as the assembler is concerned.
However, an assembler that "starts short, extends long (as necessary)"
will produce the shortest form of this instruction code. This
particular code is "magic" insofaras the "optimal/unoptimal" versions
of the code can be selected by changing just one statement (the "magic"
statement). Make this jump a short jump (or replace it by two NOPs
which would take the same amount of space as a short jump) and all the
instructions get encoded in the short form by a typical "start long,
optimize short" assembler. Put in a long jump, and the assembler will
probably leave them all long (which is *not* optimized, obviously).
RosAsm uses a "start long, optimize short" branch displacement
optimizer, but interesting enough it won't even produce an optimal
version of this program if you sustitute a short branch for the jump.
Problem #1 is that RosAsm only optimizes conditional jumps, it does not
also optimize absolute jumps. But even if you change all these absolute
jumps to conditional jumps, RosAsm's arithmetic seems to be off and it
will not produce optimal code until you subtract a small number from
the displacements. For example, the RosAsm program:
Main:
B0: jc L0>>;
B1: jc L1>>;
B2: jc L2>>;
B3: jc L3>>;
B4: jc L4>>;
B5: jc L5>>;
B6: jc L6>>;
B7: jc L7>>;
B8: jc L8>>;
B9: jc L9>>;
C0: jc M0>>;
C1: jc M1>>;
C2: jc M2>>;
C3: jc M3>>;
C4: jc M4>>;
C5: jc M5>>;
C6: jc M6>>;
C7: jc M7>>;
C8: jc M8>>;
C9: jc M9>>;
D0: jc N0>>;
;jc N6>
L0: jc B0<<;
L1: jc B1<<;
L2: jc B2<<;
L3: jc B3<<;
L4: jc B4<<;
L5: jc B5<<;
L6: jc B6<<;
L7: jc B7<<;
L8: jc B8<<;
L9: jc B9<<;
M0: jc C0<<;
M1: jc C1<<;
M2: jc C2<<;
M3: jc C3<<;
M4: jc C4<<;
M5: jc C5<<;
M6: jc C6<<;
M7: jc C7<<;
M8: jc C8<<;
M9: jc C9<<;
N0: jc D0<<;
N6:
push 0
call 'Kernel32.ExitProcess'
Produces the following object code (disassembled by dumpbin):
00403000: 0F 82 7B 00 00 00 jb 00403081
00403006: 0F 82 7B 00 00 00 jb 00403087
0040300C: 0F 82 7B 00 00 00 jb 0040308D
00403012: 0F 82 7B 00 00 00 jb 00403093
00403018: 0F 82 7B 00 00 00 jb 00403099
0040301E: 0F 82 7B 00 00 00 jb 0040309F
00403024: 0F 82 7B 00 00 00 jb 004030A5
0040302A: 0F 82 7B 00 00 00 jb 004030AB
00403030: 0F 82 7B 00 00 00 jb 004030B1
00403036: 0F 82 7B 00 00 00 jb 004030B7
0040303C: 0F 82 7B 00 00 00 jb 004030BD
00403042: 0F 82 7B 00 00 00 jb 004030C3
00403048: 0F 82 7B 00 00 00 jb 004030C9
0040304E: 0F 82 7B 00 00 00 jb 004030CF
00403054: 0F 82 7B 00 00 00 jb 004030D5
0040305A: 0F 82 7B 00 00 00 jb 004030DB
00403060: 0F 82 7B 00 00 00 jb 004030E1
00403066: 0F 82 7B 00 00 00 jb 004030E7
0040306C: 0F 82 7B 00 00 00 jb 004030ED
00403072: 0F 82 7B 00 00 00 jb 004030F3
00403078: 0F 82 7B 00 00 00 jb 004030F9
0040307E: 0F 82 7C FF FF FF jb 00403000
00403084: 0F 82 7C FF FF FF jb 00403006
0040308A: 0F 82 7C FF FF FF jb 0040300C
00403090: 0F 82 7C FF FF FF jb 00403012
00403096: 0F 82 7C FF FF FF jb 00403018
0040309C: 0F 82 7C FF FF FF jb 0040301E
004030A2: 0F 82 7C FF FF FF jb 00403024
004030A8: 0F 82 7C FF FF FF jb 0040302A
004030AE: 0F 82 7C FF FF FF jb 00403030
004030B4: 0F 82 7C FF FF FF jb 00403036
004030BA: 0F 82 7C FF FF FF jb 0040303C
004030C0: 0F 82 7C FF FF FF jb 00403042
004030C6: 0F 82 7C FF FF FF jb 00403048
004030CC: 0F 82 7C FF FF FF jb 0040304E
004030D2: 0F 82 7C FF FF FF jb 00403054
004030D8: 0F 82 7C FF FF FF jb 0040305A
004030DE: 0F 82 7C FF FF FF jb 00403060
004030E4: 0F 82 7C FF FF FF jb 00403066
004030EA: 0F 82 7C FF FF FF jb 0040306C
004030F0: 0F 82 7C FF FF FF jb 00403072
004030F6: 0F 82 7C FF FF FF jb 00403078
004030FC: 6A 00 push 0
004030FE: FF 15 30 10 40 00 call dword ptr ds:[00401030h]
As you can see, the branch displacements are all well within the +/-
128 byte range, yet RosAsm *still* uses long displacements ($7b and
-$7b).
However, if I delete two JC instructions (at labels D0 and N0), then I
get the following:
00403000: 72 26 jb 00403028
00403002: 72 26 jb 0040302A
00403004: 72 26 jb 0040302C
00403006: 72 26 jb 0040302E
00403008: 72 26 jb 00403030
0040300A: 72 26 jb 00403032
0040300C: 72 26 jb 00403034
0040300E: 72 26 jb 00403036
00403010: 72 26 jb 00403038
00403012: 72 26 jb 0040303A
00403014: 72 26 jb 0040303C
00403016: 72 26 jb 0040303E
00403018: 72 26 jb 00403040
0040301A: 72 26 jb 00403042
0040301C: 72 26 jb 00403044
0040301E: 72 26 jb 00403046
00403020: 72 26 jb 00403048
00403022: 72 26 jb 0040304A
00403024: 72 26 jb 0040304C
00403026: 72 26 jb 0040304E
00403028: 72 D6 jb 00403000
0040302A: 72 D6 jb 00403002
0040302C: 72 D6 jb 00403004
0040302E: 72 D6 jb 00403006
00403030: 72 D6 jb 00403008
00403032: 72 D6 jb 0040300A
00403034: 72 D6 jb 0040300C
00403036: 72 D6 jb 0040300E
00403038: 72 D6 jb 00403010
0040303A: 72 D6 jb 00403012
0040303C: 72 D6 jb 00403014
0040303E: 72 D6 jb 00403016
00403040: 72 D6 jb 00403018
00403042: 72 D6 jb 0040301A
00403044: 72 D6 jb 0040301C
00403046: 72 D6 jb 0040301E
00403048: 72 D6 jb 00403020
0040304A: 72 D6 jb 00403022
0040304C: 72 D6 jb 00403024
0040304E: 72 D6 jb 00403026
00403050: 6A 00 push 0
00403052: FF 15 30 10 40 00 call dword ptr ds:[00401030h]
And now the assembler optimizes the branches to two bytes each (from
six). Also note that the displacement changes from $7b to $26 (and
their negatives). The difference between $7b and $26 is considerable.
We should be able to stick a *ton* of additional instructions in here
without forcing these jumps to go from two to six bytes each! Clearly,
RosAsm is not doing a very good job of optimization here.
I'm picking on RosAsm, but the truth is that this problem exists for
*any* assembler that uses a "start large, optimize small" heuristic.
Even MASM is not free from this problem (though it does a better job of
optimization than RosAsm does).
One *big* advantage of "start large, optimize small" is that you can
stop the optimization process at any time and *still* have a working
program. Because branch displacement optimization is inherently an
NP-Complete problem, there exist certain cases where the number of
iterations one would have to execute to optimize the code would be far
too great. An assembler that starts large and optimizes small could
have a loop counter and it could stop the optimization process when the
loop exceeds some value. This could limit the number of iterations
while still providing a reasonable level of optimization (do keep in
mind that the majority of the optimizations are going to occur on the
*first* pass of this algorithm).
In theory, a "start small, work larger" algorithm could be forced to
run (almost) forever optimizing some large programs. In practice few
optimization algorithms implement a truly NP-Complete algorithm and as
such, they complete in polynomial time (meaning even if they work
slowly, they are tractible solutions). They don't guarantee optimal
results, but they still tend to produce better results than "start
large, optimize small" algorithms and usually they run much faster
because most of the branches in a typical program *are* small.
Back to RosAsm's algorithms, I see a couple of problems that exist:
1) RosAsm only optimizes conditional jumps. It does not optimize JMP
instructions or any other variable-length instructions whose size can
change based on various factors.
2) There is a bug in the RosAsm algorithm -- it doesn't always
optimizes even when it has the chance (e.g., the example given
earlier).
3) RosAsm only applies the branch displacement optimization algorithm
to condition jumps whose target label is a local symbol. If you use a
regular target symbol, RosAsm always encodes this as a large
displacement instruction. This makes no sense at all. If you can
optimize one label type, why not both? Just a bad design decision on
Rene's part.
Cheers,
Randy Hyde
rand...@earthlink.net
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 relationship 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 wishing to develop an Assembler
> doing Jumps Size Optimizations, - in one single and simple
> additional Computation, taking almost no time , instead of
> the traditional Multi-Passes -, 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 passes 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 passes 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 support 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
Betov
news:1126462208.6...@g43g2000cwa.googlegroups.com:
> [... BlaBla... BlaBla... BlaBla...]
Shut up, and take a lesson, ass-hole.
:)
Betov.
Betov
news:1126462991....@g14g2000cwa.googlegroups.com:
> [... BlaBla...BlaBla... BlaBla...]
anonymous
Randy wrote:
> Elsewhere in this thread, Rene has mentioned that he uses a "start
> long, optimize short" algorithm for branch displacement optimization.
> This scheme has the advantage that if you ever prematurely stop during
> the optimization process, the program will still run correctly.
> However, this algorithm often produces results that are not as optimal
> as they could be.
<snipped>
> Back to RosAsm's algorithms, I see a couple of problems that exist:
>
> 1) RosAsm only optimizes conditional jumps. It does not optimize JMP
> instructions or any other variable-length instructions whose size can
> change based on various factors.
>
> 2) There is a bug in the RosAsm algorithm -- it doesn't always
> optimizes even when it has the chance (e.g., the example given
> earlier).
>
> 3) RosAsm only applies the branch displacement optimization algorithm
> to condition jumps whose target label is a local symbol. If you use a
> regular target symbol, RosAsm always encodes this as a large
> displacement instruction. This makes no sense at all. If you can
> optimize one label type, why not both? Just a bad design decision on
> Rene's part.
Who was this written for/to?
greetz
Jakob Wrigley
rand...@earthlink.net
Betov wrote:
>
>
> Shut up,
Telling me to shut up isn't going to do the trick. You've been told
many times how to get me to leave you and your product alone. It's
quite simple, really. All you have to do is stop insulting HLA users,
HLA, MASM, and other products and people around here. Concentrate on
your own product rather than everyone else's. Start behaving in a civil
manner. And I will quickly forget that you and your product even exist.
> and take a lesson,
As should be clear from the questions raised in this thread, and the
comments in reply, you're not exactly the best person to give lessons.
> ass-hole.
Again, there is that issue of civility.
Cheers,
Randy Hyde
Betov
news:1126528149.8...@o13g2000cwo.googlegroups.com:
> Telling me to shut up isn't going to do the trick. You've been told
> many times how to get me to leave you and your product alone. It's
> quite simple, really. All you have to do is stop insulting HLA users,
> HLA, MASM, and other products and people around here. Concentrate on
> your own product rather than everyone else's. Start behaving in a civil
> manner. And I will quickly forget that you and your product even exist.
Ass-hole, this is not a market place.
The fact that you are a nobody, a US Neo-Nazi, an
utterly incompetent programmer, a swindler and a liar
having nothing to sell but yourself, and so on, has
no relationship with RosAsm, and your attacks against
a product that is way over your head, will never make
you any money to buy any silence on your ass-hole case.
Also, as long as any of your insanities, in the form of
the now famous "RosAsm Symbols Table Bug", of "RosAsm
does-not-do-this and does-not-do-that", of "The Two-
Click Disassembler-Reassembler is impossible", and so
on... and so on... are so easily proven to be insanities
by any lurker giving a quick try to RosAsm, that those
insanities can have no final target but your own rat
face.
So feel free to go on pissing in the wind, Master Pdf.
:)
Betov.
Paul Dunn
[Some stuff that's not really relevant]
Betov, did you not read my last question? I'm interested in your definition
of "emulation", so I understand what you mean by it. I don't think it's the
same definition that I use.
Can you explain?
Annie
On 2005-09-12 Randy Hyde said:
> Betov wrote:
>
> > Shut up,
>
> Telling me to shut up isn't going to do the trick. You've been told
> many times how to get me to leave you and your product alone. It's
> quite simple, really. All you have to do is stop insulting HLA
> users, HLA, MASM, and other products and people around here.
> Concentrate on your own product rather than everyone else's. Start
> behaving in a civil manner. And I will quickly forget that you and
> your product even exist.
_____
Holy NetKKKop, 'Professor!' ((( `\
Hehe! _ _`\ )
(^ ) )
~-( )
_'((,,,)))
,-' \_/ `\
( , |
`-.-'`-.-'/|_|
\ / | |
=()=: / ,' aa
anonymous
"Betov" wrote:
> Ass-hole, this is not a market place.
>
> #### #### ####, a #### and a ###
> having nothing to sell but #####, and so on, has
> no relationship with RosAsm, and your attacks against
> a product that is way over your head, will never make
>
> Also, as long as any of your #####, in the form of
> the now famous "RosAsm Symbols Table Bug", of "RosAsm
> does-not-do-this and does-not-do-that", of "The Two-
> Click Disassembler-Reassembler is impossible", and so
> by any lurker giving a quick try to RosAsm, that those
> ####.
>
> So feel free to go on ##### in the wind, Master Pdf.
>
> :)
>
> Betov.
Doesn't all that anger cause you constipation? If you re-thought your
vocabulary you could save a lot of effort, and you and anyone reading what
you write would inevitably become happier in some/every way. For instance,
the above could have been expressed something like this:
"I generally disagree with you, so please do not make negative comments to
what I write, as this will not make me change the features anyway.
"As long as it can be proven that RosAsm is without those faults, that you
claim it has, I shall not fix them, afterall you can't fix non-existing
bugs.
"Feel free to do other more constructive things with your time"
This was merely a sample, naturally you would want to add your own unique
style to it. Have a go! Once you get started posting happier posts, you
won't be able to stop.
Best of Luck, :?]
Jakob Wrigley
rand...@earthlink.net
Betov wrote:
>
> Ass-hole, this is not a market place.
Really?
I could have sworn that this thread was promoting RosAsm v.2.025a and I
could have sworn that I remember you doing a little "chest-thumping"
(your words) in this very thread.
>
> The fact that you are a nobody, a US Neo-Nazi, an
> utterly incompetent programmer, a swindler and a liar
> having nothing to sell but yourself, and so on,
Remember the line about how I will quickly forget about you and RosAsm
when you stop the personal attacks? Hint: the above is a personal
attack.
> has
> no relationship with RosAsm, and your attacks against
> a product that is way over your head, will never make
> you any money to buy any silence on your ass-hole case.
What on Earth makes you think I'm trying to make money off of this? All
I'm doing is attempting to annoy you in retaliation for all your
personal attacks on HLA and MASM users as well as your attacks on those
products. From the tone of your responses, I'm being quite successful
at this. Hint: you're making my day when you respond like this.
>
> Also, as long as any of your insanities, in the form of
> the now famous "RosAsm Symbols Table Bug",
I'm sorry, but putting up a dialog box of the form "How are you Master
PDF" when someone supplies a syntactically correct program, to mask the
defect in your code, *is* a serious defect. Just fix the problem. Learn
how to allocate memory dynamically.
> of "RosAsm
> does-not-do-this and does-not-do-that",
Well, there is a lot of that. :-)
> of "The Two-
> Click Disassembler-Reassembler is impossible",
So you're now saying that your "two click disassembler-reassembler"
works perfectly? Have no fear, we'll return to the subject of the
state of your disassembler in a later sub-thread. It sure hasn't seemed
to progress very much this year, has it?
> and so
> on... and so on... are so easily proven to be insanities
> by any lurker giving a quick try to RosAsm,
That's generally why I post code, like the very code in this thread,
that demonstrates the problem I'm writing about.
> that those
> insanities can have no final target but your own rat
> face.
And that's your typical response, rather than coming back with a
reasonable defense of your product or fixing the problems outlined in
the code I post.
Cheers,
Randy Hyde
rand...@earthlink.net
I think I can explain it for you. Given Rene's recent attempts at
explaining his algorithms, I doubt his explanation will be
satisfactory. However, note that my explanation is based on what I
understand his explanations to say, I've not bothered wasting any time
trying to read his source code (see Alex's discussions for the problem
with that approach).
What Rene is doing is making multiple passes over some encoded
representation of his source code rather than multiple passes over the
source code itself. He believes this technique to be unique (because he
thought it up all by himself, I suppose). I guess that he's unaware
that this is how modern compilers all work.
Bottom line, though, is that he does make multiple passes (the correct
phrase is "multi-phase") over each of the conditional jump instructions
in order to shorten them down. His code is a bit immature and doesn't
do as good a job as assemblers such as Gas or MASM (which I've compared
his code to, I suspect FASM does a better job too, though I've not
tried this); worse, he only handles conditional jumps and doesn't
optimize unconditional jumps or other instructions whose size is
affected by the distance between labels in the code.
Fixing the problem with conditional jumps that I've described in an
earlier post is probably an easy fix. It probably won't take Rene more
than a couple of hours (if he hasn't fixed this already). OTOH,
allowing for other instructions than condition jumps sounds like a
whopper of a design defect, and unless he's lucky this fix could take a
lot more effort.
Cheers,
Randy Hyde
Betov
news:89e4e$4325f70a$3e3d8699$17...@news.arrownet.dk:
> Doesn't all that anger cause you constipation? If you re-thought your
> vocabulary you could save a lot of effort, and you and anyone reading
> what you write would inevitably become happier in some/every way. For
> instance, the above could have been expressed something like this:
>
> "I generally disagree with you, so please do not make negative
> comments to what I write, as this will not make me change the features
> anyway.
>
> "As long as it can be proven that RosAsm is without those faults, that
> you claim it has, I shall not fix them, afterall you can't fix
> non-existing bugs.
>
> "Feel free to do other more constructive things with your time"
>
> This was merely a sample, naturally you would want to add your own
> unique style to it. Have a go! Once you get started posting happier
> posts, you won't be able to stop.
:))
In real life, i would much prefer knocking on the face
of such an ####, with my hands of old home maker. This
would be way faster, and would make me way more happier.
:))
Betov.
rand...@earthlink.net
Betov wrote:
> RosAsm V.2.025a is released. Main new points since V.2.021:
Well, let's take a look at these, point by point:
>
>
> * New version of the Equal Pre-Parser.
Hopefully, it is *much* better than the last one.
>
> * New release of the Disassembler, with first implementation
> of Map File.
Where's the interactivity that is needed to make this thing practical
to use? It's amazing how *little* work has been done on this
disassembler this year. Last year at this time you were promising the
moon with respect to what the disassembler was going to do, not much
has really happened since then. You click once to disassemble, and on
the second click you still get lots of errors in the result. Sure, you
can spoon-feed it simple programs that disassemble properly, but on
real-world programs it's still a bit lacking. You've still got a *long*
ways to go to catch up with IDAPro; and at the rate you're going, it'll
be 2025 before you come close.
>
> * New release of the Debugger. Review of the WatchPoints, of
> the Interface (ToolBar,...)
More on this later in this post...
>
> * Review of the Conditinal Macros, with generalisation of the
> '#N' Key.
Why "conditional macros"? Why isn't this generalized to "conditional
assembly?" That is, why can't you use the conditional assembly
*outside* the macros, as you can with nearly every other assembler out
there in the world? And why don't you support arbitrary boolean
expressions in your conditional assembly #IF statements, like most
other assembler's conditional assembly directives support? While it's
great that you finally added conditional assembly last year (its
absense was painstakingly obvious), you're still *way* behind on the
feature curve on this important facility and you've got a ways to go to
catch up with other assemblers. Considering that, like your
disassembler, it's been a long time since you've introduced this
feature, it's sad that you've not improved it much over the past year.
Adding a '#N' feature, not withstanding...
>
> * Jumps Size Optimizations.
Lots of bugs. But I'll give you time for this one as it is a brand-new
feature. However there are a couple of basic flaws in your design:
1. You only optimize conditional jumps. You do not optimize
unconditional jumps or other instructions whose size can vary based on
the distance between two statement labels.
2. You only optimize conditional jumps that refer to local labels, you
do *not* optimize conditional jumps to standard (non-local) labels.
This is particularly bad as you require a separate assembly option to
do branch displacement optimization.
3. You use a "start long, optimize short" algorithm which doesn't
provide as good of an optimization as "start short, deoptimize long"
approach (though you're in good company as many other assemblers share
this same design flaw).
As for the other arguments, they've been argued over and again in this
thread already...
>
> * Enable multiple Clip Files.
One more small step towards the power of programmer text editors like
Code Wright and UltraEdit32. Maybe by 2025 you'll have all their power
:-).
>
> * Restart the LibScanner from scratch
???
>
> * Implement the Tag Menu ID (for Instant Edition).
???
>
> * New version of the Form Wizard, with Treeview display for
> styles, Grid, ...
When are you going to have all these "wizards" you've been promising
for the past several years? Remember when you were promising how your
"visual assembler" would usher in the "assembly rebirth?" We're still
waiting. Form Wizard may be a cute demo, but I don't see it fulfilling
the vaporware that you've been promising.
>
> * Assembler: Speed-up pre-computation of the nested Equates.
> Up to 25% saved on files making some heavy usage of
> imbricated Equates (Typically OOP Style).
>From the guy who clearly doesn't know what OO is or even what the term
means.
>
>
> RosAsm is a Bottom-Up PEs Assembler for ReactOS (ReactOS,
> WINE, Windows 95/98, NT/2000, XP,...). It is a free, GPLed,
Or RPL'd, which is hardly free... :-)
> auto-compilable Assembler,
Which has good and bad points...
> and is the only Assembly
> Environnement coming with full integration of all its
> components:
>
> * Assembler: The fastest of the actual assemblers,
So you claim, but you've yet to offer any proof of this. Indeed, some
simple tests of comparable programs being compiled with FASM and RosAsm
indicate that FASM is 2.5x faster than RosAsm, proving your claim to be
false.
> (1.5
> Mega/second on a Celeron 1.3 Ghz...)
A completely meaningless number. 1.5 MB/sec of what? Comments? NOPs?
RosAsm source code? The only possible use this number could serve is in
some "contest" with respect to the speed of other assemblers, and then
this number would only have meaning if you provided numbers for those
other assemblers when processing roughly identical source code. You're
just drawing numbers out of thin air here.
> directly outputting
> PE files on a simple click,
So? Other IDEs do this. What's the big deal? The real question is "what
work is involved in getting up to the point of that 'simple click'?"
> with a very powerful macros
> system
"Powerful" is a relative term. Powerful compared to what? An assembler
that doesn't support macros at all? As best I can tell, the only
assemblers with macro facilities at all, that are less powerful than
RosAsm's, are GoAsm and Gas. The other assemblers beat you hands down
(and by a *very* wide margin). Perhaps you should explain what you
mean by "powerful" because your concept of "powerful macros" seems to
be quite a bit different from what advanced assembly programmers have
come to expect when someone says "very powerful macros system."
> (a macros unfolder is available by a double-click,
> through a float menu).
Most assemblers provide a listing option, something that RosAsm doesn't
provide, that lets you easily see the *complete* code all the macros
expand into. Right-clicking is useful for "programming in the small"
but a full assembly listing is even better for those who want to
analyze exactly what code the assembler is producing. This is a
facility you *should* add to RosAsm. Given RosAsm's "monolithic source
file approach," creating an assembled listing should be fairly easy for
you.
> Simplified Intel syntax.
Repeat after me: "RosAsm is *not* Intel syntax." Not in any way, shape,
or form. The *only* two things you have in common with Intel syntax are
the mnemonics and the operand ordering. Everything else is completely
different. And hardly "simplified". Whether or not your syntax is
*better* is a good question to ask (and I'm sure all the RosAsm users
think so, and most non-RosAsm-users probably think not). But it is
*not* Intel syntax; simplified or otherwise (not to mention the fact
that the phrase "simplified Intel syntax" is logically inconsistent;
it's either "Intel syntax" or it is not "Intel syntax").
> Does not
> need any include, prototype or header companion file.
Nor does it allow them. It doesn't allow library code to be linked in.
It doesn't allow the creation of code that can be linked with other
programs. You cannot write assembly language subroutines for use by
HLLs with RosAsm. You cannot use (statically linked) code produced by
HLLs with RosAsm applications. Nor can you use code written with other
assemblers with RosAsm (or RosAsm code with other assemblers). This, in
fact, is the prime reason most people reject RosAsm out of hand.
The good news is that you've added conditional assembly, after swearing
you wouldn't do it. You've added branch displacement optimization after
swearing you wouldn't do it. Maybe someday you'll finally realize that
people aren't going to use RosAsm if they can't (statically) link in
object files or produce object files that can be linked with other
code, and you'll finally figure out some way to support this critical
facility in RosAsm.
And your claims that people can use the disassembler to generate source
code from other object code sources is completely laughable. First of
all, the disassembler isn't even close to working. And even if it were
100% perfect, hand-massaging disassembled code into something people
would want to maintain is much more work than hand-coding the library
code in the first place. The disassembler is *not* a substitute for
library support, no matter how badly you want to prove that "libraries
are incompatible with assembly."
> Nothing but a single simple source.
Yes, no support for multiple compilation modules. No support for team
projects. Poor support for code reuse.
> Complete implementation
> of the mnemonics set, up to SSE2.
Okay, that's a no-brainer (though we are up to SSE3 and 64-bit
instructions these days, of course; but that's not an issue for most
people).
> RosAsm Bottom-Up Assembler
> is a true low level Assembler,
The only "low-level assembler" I know of to support statements like
"eax = ebx*i - ecx/edx" -- definitely an interesting concept of
"low-level assembler."
> enabling HLL writing styles
> by user defined macros and/or by HLL pre-parsers selections.
IOW, it's a high-level assembler?
>
> * Disassembler: To date, RosAsm is the one and only two-clicks-
> disassembler-reassembler ever seen.
It doesn't work, but it is the only one ever seen. :-)
> It is, actually, fully
> effective on most small files
That are easy to disassemble.
> and on many middle size
> applications:
That are easy to disassemble.
> The dream tool for study and/or for porting
> your works to assembly.
That's a nightmare, not a dream.
People do *not* port code to assembly language by disassembling other
code. It's easier just to hand-code the stuff. This is particularly
true when you consider the fact that RosAsm's current disassembler can
rarely produce source code that is free of syntax errors. And without
any interactive abilities to allow the user to guide the disassembly
process (and save the "hints" so they can work on their disassembly
over a period of time, as IDAPro allows), the user is stuck fixing all
the disassembly problems that the "automatic" disassembler emits into
the source file. Too much manual work for anything of any realistic
size.
>
> * Debugger: Source level Debugger with a state-of-the-art
> memory inspector and very advanced features, like the
> dynamic break-points, that can be set/removed by simple
> clicks, as well as at write-time and/or at run-time, like
> with the most advanced HLLs. To run the Debugger, You
> simply click on [Run] and your application is running
> through the debugger. Any error (or watch-points, or
> break-point, enabling advanced stepping modes) is pointed
> out directly in your source code. Accurate messages are
> delivered on errors cases.
Wow. You're bragging about features that have been present in just
about every debugger since CodeView.
>
> * Sources Editor: Real Sources Editor with tons of unique
> features, specificaly devoted to secure editions and to
> huge mono-files assembly sources: Tree-view, instant
> jump to any type of declaration by simple right-click,
> division of the mono-files into TITLEs, advanced
> IncIncluder pre-parser, and so on...
Code Wright, UltraEdit32, and other programmer's editors are *far*
better. The real crime is that RosAsm uses a proprietary source format
that pretty much forces the user to use the RosAsm editor, whether they
like it or not. And given that the RosAsm editor doesn't follow CUA
guidelines, I suspect you'll find that most Windows users find the
facilities in your "sources editor" quite annoying.
>
> * Resources Editors: Original Resources Editors, with
> control of matching styles, outputting as well resources,
> files, and memory templates.
I've never used your resource editor, so I can't personally comment on
it other than to say that what I've *heard* about it isn't very
encouraging. It's too bad you don't allow people to link in object
files from precompiled resources; that way if your resource editor
doesn't handle something as well as one of the other products out
there, people could use one of those other resource editors to get the
job done. No doubt, you'll claim that your resource editor has no bugs
and does everything people need done, but your past "chest-thumping"
about RosAsm's feature set doesn't lead much creedence to such a claim.
>
> * Wizard for visual design.
Which seems to be more vaporware/demo than anything else.
>
> * Clip file system, for templates reuse.
Something real programmer's editors (e.g., CodeWright) have had for
years. Too bad it isn't easy for someone to use their favorite
programmer's editors with RosAsm -- they'd have been able to take
advantage of features like this for years.
>
> * Integrated OS Equates, and Structures files, saving from
> any boring include.
Which is important, because RosAsm can't handle standard Windows
equates. Interesting, don't you think? You have to put the Windows
equates in a special namespace to prevent problems (e.g, use of "_" in
symbols). Did it ever occur to you that maybe someone might have those
same problems in the normal symbols space?
And another question -- suppose the user *wants* to include a header
file with a bunch of equates like the Windows equates? Is it going to
work? Nope. You claim the assembler will report some funny message
about "Master PDF" (in my past experience the assembler just crashed;
but I'll assume you've gotten past that). Why *can't* your assembler
handle a large set of equates, like the Windows equates file? Other
assemblers do this with no problems.
>
> * Integrated Help system, with a complete 32 bits Assembly
> Tutorials, Opcode help, and RosAsm Manual (1.5 mega of
> documentation, grouping close to 600 organised rtf files).
Does this mean we should start calling you "Master RTF"? :-)
>
> ... and much more...
Yeah, like tons of bugs... :-)
Rene- continue insulting HLA users, HLA, MASM, MASM users, and so on,
and I'll continue to pick apart that pile of crap you call RosAsm. It's
such an easy target, there's no sport in it. But it's fun to watch you
get mad and resort to profanity all the time :-)
Cheers,
Randy Hyde
Betov
news:1126924991....@o13g2000cwo.googlegroups.com:
> [... 20 Pages of bullshits...]
Congratulation, ass-hole: You are more and more
ridicoulous.
:)
Betov.
rand...@earthlink.net
Betov wrote:
> "rand...@earthlink.net" <rand...@earthlink.net> écrivait
> news:1126924991....@o13g2000cwo.googlegroups.com:
>
> > [... 20 Pages of bullshits...]
>
>
> Congratulation, ass-hole: You are more and more
> ridicoulous.
>
Perhaps I am. Even considering RosAsm is certainly a ridiculous
concept. But even still, there are a lot of serious issues with RosAsm
that you need to address, whose design and promotion you clearly cannot
defend.
Cheers,
Randy Hyde
Betov
news:1127055326.5...@g49g2000cwa.googlegroups.com:
> Even considering RosAsm is certainly a ridiculous
> concept. But even still, there are a lot of serious issues with RosAsm
> that you need to address, whose design and promotion you clearly cannot
> defend.
I don't need to, ass-hole:
There is only a nobody attacking RosAsm.
:)
Betov.
Richard Cooper
> There is only a nobody attacking RosAsm.
Perhaps, but reading Randy's post, I found many reasons I wouldn't want to
use RosAsm.
Now if he'd just write a similar post for all of the other assemblers then
it'd be a lot easier for me to decide which ones I'd like to have a closer
look at.
Betov
news:op.sxa7e...@sucks.airplane.fire:
> Perhaps, but reading Randy's post, I found many reasons I wouldn't
> want to use RosAsm.
I did not really read it, but if you can see any interrest
in reading the insanities of this ass-hole, you should not
do any Assembly before having bought yourself a brain.
:)
Betov.
Richard Cooper
> I did not really read it, but if you can see any interrest
> in reading the insanities of this ass-hole, you should not
> do any Assembly before having bought yourself a brain.
He did have some good points in there:
> why can't you use the conditional assembly *outside* the macros
> > Does not need any include, prototype or header companion file.
> Nor does it allow them. It doesn't allow library code to be linked in.
> It doesn't allow the creation of code that can be linked with other
> programs. You cannot write assembly language subroutines for use by
> HLLs with RosAsm. You cannot use (statically linked) code produced by
> HLLs with RosAsm applications. Nor can you use code written with other
> assemblers with RosAsm (or RosAsm code with other assemblers). This, in
> fact, is the prime reason most people reject RosAsm out of hand.
> > Nothing but a single simple source.
Guga
Randalk said so, i presume ;)
I strongly advice you to stick in HLA then. If you take Randall´s
advices serious, you really should use his product, either it is not
considered an assembler. (not only by me)
Best Regards,
Guga
Betov
news:op.sxbbr...@sucks.airplane.fire:
> On Sun, 18 Sep 2005 13:52:45 -0400, Betov <be...@free.fr> wrote:
>
>> I did not really read it, but if you can see any interrest
>> in reading the insanities of this ass-hole, you should not
>> do any Assembly before having bought yourself a brain.
>
> He did have some good points in there:
???!!!...
You understand it or not, RosAsm is a collective effort of
volunteers working for free. To date, the 18th of September
2005, there are _7_ volunteers working on something for the
Project:
* Ludwig, Debugger
* Betov, Guga, the LibScanner
* Scarmatil, the Equal Pre-Parser and the Form Wizard
* Toto, the B_U_asm Viewer
* James, the IVT and the Docs proof-readings.
* YeoH, .hlp Tutorials
So, the aggressions of such an ass-hole, as Randall Hyde,
who never did anything but selling himself, are certainaly
not any base for talking about what RosAsm is, and how it
does (or does not) do this or that, and it is evidently
_NOT_ my job to "defend" RosAsm against this unsignificant
ass-hole:
The Product _exist_ and does not need any "defense". I do
not "sell" RosAsm. I simply post annoucements from time to
time (way less than what we release, by the way...), and i
list the new implementations. Period.
Betov.
Guga
"either it is not considered an assembler. (not only by me) "
If i´m not mistaken....you are also one more who don´t consider it an
assembler ;)
Guga
Guga
Translations ;) and Fabricio with the portuguese translation of the
B_U_asm.
Richard
The development team is working hard to improve the product, and we
don´t have the tendence to keep on the path of "self-promotion at any
cost".
I guess i already answered that here, but, if you (Or anyone else, who
is using or wants to use RosAsm) have questions, comments, criticts,
ideas, methods, etc. about RosAsm, this NG is not the proper place for
commenting technical aspects of it.
The questions, comments, requests about the product should be done in
the proper board at:
http://www.quanta-it.com/easbell/RosAsmForum/index.php
Currently we are only 7 working at the same time on different aspects
of RosAsm. Anyone who wants to join and try to improve, can post on
RosAsm board, and contact us. We still need to develop things like a
good (If not perfect) H2Inc, the Interface for the ApiViewer (Which the
internal data i already collected since sometime ago), a delphi form to
asm, a VB form to asm, or any other features that people may feel
necessary to improve. Just contact us, to we all discuss the ways to be
done, or how it can be implemented.
This is how we try to work. We try to work as a team. Everyone of us,
before implement something big or meanfull in RosAsm, post it there and
talk to each other. This is a way to we help on the development.
So, if you have any idea or know how to implement or improve something,
contact us at RosAsm board ;)
Best Regards,
Guga
sevagK
Guga wrote:
> And this is a problem, because ....... ?
>
> Randalk said so, i presume ;)
>
Not really. 50 years of software engineering technology said so.
> I strongly advice you to stick in HLA then. If you take Randall´s
> advices serious, you really should use his product, either it is not
> considered an assembler. (not only by me)
>
> Best Regards,
>
> Guga
Besides HLA, there are also other fine choices; FASM, NASM, MASM,
GOASM.
MASM is probably the best choice as there is the most sample software
for it, and Bogdan's game is written in MASM compatible mode I believe,
which would be a great help.
-sevagK
www.geocities.com/kahlinor
Richard Cooper
> If i´m not mistaken....you are also one more who don´t consider it an
> assembler ;)
Nope, and there's no way I'd ever use an assembler (or preprocessor in
this case) that gets "dest, src" backwards, no matter how good it was.
Doesn't mean that Randy can't make a valid point now and then.
rand...@earthlink.net
It's a bit out of date at this point and needs some serious updating
(especially to address changes in FASM and with respect to a discussion
of assembler speeds), but you might want to browse through
http://webster.cs.ucr.edu/AsmTools/WhichAsm.html
The discussion of RosAsm is also out of date, but my points in this
thread should cover the issues there. RosAsm simply isn't at the same
level as the other assemblers mentioned in the article, even today.
Still, I'd be a *lot* more friendly towards RosAsm if Rene would learn
to keep his mouth shut and simply promote his own product rather than
attacking other people and other products. His unwarranted attacks on
you are a classic example of his problem; combined with death threats
and incessant use of profanity around here, it's pretty clear that he
needs some serious psychological help. Whatever. I just take the
approach of pointing out problems with his own products every time he
decides to go on tirades insulting other newsgroup posters or other
products around here. Whether the product deserves it is immaterial;
it's the most appropriate punishment one can dish out to Rene. It's too
bad other RosAsm developers get caught in the crossfire, but they
refuse to reign Rene in and continue to support him even when he makes
his outlandish attacks, so they're far from neutral in this little
"jihad" of Rene's.
Don't feel singled out, btw. Rene has attacked many a good person
before you came along, and no doubt he will continue to attack other
newcomers in the future. That's just his personality.
Cheers,
Randy Hyde
rand...@earthlink.net
Exactly whom are you responding to?
I think that Richard has made it very clear that he is not an HLA user
and has no interest in HLA.
I think you've been hanging around with Rene too long and you've let
his paranoia affect you too much. Believe it or not, *few* serious
assembly language developers would *ever* consider a product that does
not support linking of static object modules (e.g., libraries). This
one omission alone will guarantee that RosAsm never garners any
reasonable level of success. I think you'll find that *few* people
who've used *any* kind of assembly language over the years would ever
be tempted to switch to RosAsm; we're not just talking HLA users here.
Cheers,
Randy Hyde
Annie
On 2005-09-18 spamand...@xersedefixion.com said:
> Betov wrote:
>
> > There is only a nobody attacking RosAsm.
>
> Perhaps, but reading Randy's post, I found many reasons I
> wouldn't want to use RosAsm.
>
> Now if he'd just write a similar post for all of the other
> assemblers then it'd be a lot easier for me to decide which
> ones I'd like to have a closer look at.
_____
The problem with this scenario ((( `\
is that it assumes Randy is some _ _`\ )
kind of ultimate "authority"... (^ ) )
which, as we all know, can be a ~-( )
highly questionable assumption. _'((,,,)))
Remember, we're talking about ,-' \_/ `\
the guy who wrote HLA. Hehe! ( , |
`-.-'`-.-'/|_|
Truth is, many of Hyde's criti- \ / | |
cisms of RosASM are matters of =()=: / ,' aa
personal style or preference.
Betov sometimes deviates from the bureaucratized
'traditional' way of doing things in his coding
of RosASM. This, in itself, is not necessarily a
valid basis for criticism...since RosASM *does*
generate perfectly functional WinDoze apps.
Randy's criticism of RosASM's functionality con-
cerns, in large part, matters of a highly esoteric
technical nature. Despite what Randy says, not one
programmer in a million would ever experience any
problems using RosASM to write an application. And
once a programmer becomes totally familiar with the
RosASM style of programming, he'd literally NEVER
experience a problem.
Every assembler has its own little eccentricities
which a programmer must become accustomed to. If
someone were to delineate for you all of the glitches
and hacks in MA$M, you'd be scared to use MA$M, as
well. Hehehe!
The bottom line is: don't take Hyde's assessment of
RosASM as gospel. Randy has his own ax to grind,
both personally and professionally, and it can color
his critique of other people's work.
RosASM is free, for #%@& sake. So download that sucker,
try it out for YOURSELF, and make your OWN decision
about it.
Don't be a stereotypical WinDoze weenie, and unques-
tioning accept what someone else TELLS you.
You know what happens to lemmings who blindly follow a
'leader,' don't you? Hehe!
---
"HLA.EXE is not an assembler. Indeed, it's not even a compiler,
pre-processor (or "preparser", whatever that is), though it
*might* qualify as [a] 'text converter.'"
- Randy Hyde, author of 'HLA,'
in ALT.LANG.ASM newsgroup --
August 11, 2004
Richard Cooper
> If someone were to delineate for you all of the glitches
> and hacks in MA$M, you'd be scared to use MA$M, as well.
No one has to talk me out of using MASM.
Is Randy wrong when he says that RosAsm only allows a single source file,
and doesn't allow you to link to external code? Most of what he had to
say I didn't pay much attention to, but those two issues are rather
important.
> RosASM is free, for #%@& sake. So download that sucker,
> try it out for YOURSELF, and make your OWN decision
> about it.
I'm back in Linux, so it's out of the question now.
> Don't be a stereotypical WinDoze weenie, and unques-
> tioning accept what someone else TELLS you.
I'm not unquestioning. For example:
> "HLA.EXE is not an assembler. Indeed, it's not even a compiler,
> pre-processor (or "preparser", whatever that is), though it
> *might* qualify as [a] 'text converter.'"
That's just taking him out of context, don't you think?
Betov
news:1127090150....@g14g2000cwa.googlegroups.com:
> http://webster.cs.ucr.edu/AsmTools/WhichAsm.html
>
> [...]
>
> That's just his personality.
I also recommand to the readers to take a look at
your above linked Page of insanities, and to draw
by themselves the conclusions, about your own
personality, ass-hole: As a professional swindler
and liar... you are the king.
:)
Betov.
Betov
@z14g2000cwz.googlegroups.com:
> Ren‚, donļt forget GertFaller and his current work on the BCX
> Translations ;) and Fabricio with the portuguese translation of the
> B_U_asm.
Indeed...
:)
Betov.
Betov
news:op.sxb44...@sucks.airplane.fire:
> [...]
> Is Randy wrong when he says that RosAsm only allows a single source
> file,
No, he is not _wrong_. He is just introducing a _HUGE_
ADVANTAGE as an implicit inconvenient.
> and doesn't allow you to link to external code?
Idem. Mind you, any "Home made Assembler" Author can
easily output obj files and rely on an external Linker,
in 1% of the time that we are investing at developing
way more serious ways.
Betov.
wolfgang kern
Betov answered Richard Cooper:
| > Is Randy wrong when he says that RosAsm only allows a single source
| > file,
| No, he is not _wrong_. He is just introducing a _HUGE_
| ADVANTAGE as an implicit inconvenient.
| > and doesn't allow you to link to external code?
Perhaps not in the traditional way, but I already explained with my
HEXTUTOR.exe that RosAsm can easy load KESYS-binaries and run it as
if it were made for windoze (which they are for sure not) without any
need for relocation or linking processes at all.
| Idem. Mind you, any "Home made Assembler" Author can
| easily output obj files and rely on an external Linker,
| in 1% of the time that we are investing at developing
| way more serious ways.
Linking to or include a library would make sense if the libraries would contain
really useful things only.
I haven't found any real good code in any yet.
__
wolfgang
Betov
news:dgm8sm$ep$1...@newsreader1.utanet.at:
>| Idem. Mind you, any "Home made Assembler" Author can
>| easily output obj files and rely on an external Linker,
>| in 1% of the time that we are investing at developing
>| way more serious ways.
>
> Linking to or include a library would make sense if the libraries
> would contain really useful things only.
> I haven't found any real good code in any yet.
In the team, everybody is in this opinion too. The (demential)
work, we are actually doing on the LibScanner - that will take
all of this in charge, anyway... - is, first, designed to create
a complete D.I.S. system, for the Disassembler. Another story...
;)
Betov.
Richard Cooper
> No, he is not _wrong_. He is just introducing a _HUGE_
> ADVANTAGE as an implicit inconvenient.
I don't see now not being able to do something can be an advantage.
When I write a really nice function, I like to be able to use it in every
program that I write, simply by making the file it's in part of the set of
source files that make up the program, or by using an include directive.
With RosAsm, I'd have to go and copy and paste it into RosAsm, because
apparently being able to keep it as a seperate file would be a huge
disadvantage.
I also don't link to external object code often. Currently the only time
I do it is with my "quick little assembly programs" folder that I write
simple little programs in. In there I've got my register dump code
compiled into an object file, and my script to assemble files links them
with that object file. That way I've got all of the debugging support
I've developed in every program without having to copy all of that code
into every program. However, like you've said, doing it that way is a
huge disadvantage. I'd be much better off to just copy and paste that 546
lines of code into every program that I write, that way if I later come up
with a better idea for some of the debugging stuff that's in there, I have
to go through every program I've made that uses it and update the
debugging code seperately. Being able to update them simply by updating a
single object file and a single include file would be a huge disadvantage.
Betov
news:op.sxcq9...@sucks.airplane.fire:
> On Mon, 19 Sep 2005 05:56:48 -0400, Betov <be...@free.fr> wrote:
>
>> No, he is not _wrong_. He is just introducing a _HUGE_
>> ADVANTAGE as an implicit inconvenient.
>
> I don't see now not being able to do something can be an advantage.
Having a Tool that does not push the user to bad programming
practice _is_ in _HUGE_ advantage.
> When I write a really nice function, I like to be able to use it in
> every program that I write, simply by making the file it's in part of
> the set of source files that make up the program, or by using an
> include directive. With RosAsm, I'd have to go and copy and paste it
> into RosAsm, because apparently being able to keep it as a seperate
> file would be a huge disadvantage.
Utterly wrong. With RosAsm, we store the "nice function" into
the Clip File, what is _WAY_ better and _WAY_ more intelligent
than going the "Blind-Box" programming way.
> I also don't link to external object code often. Currently the only
> time I do it is with my "quick little assembly programs" folder that
> I write simple little programs in. In there I've got my register
> dump code compiled into an object file, and my script to assemble
> files links them with that object file.
With the RosAsm methods, you don't _have to_ do it
this stupid way.
Betov.
Guga
Richard
____________________________________________________
About the single (Unique) source, this is not a problem. In fact, it
helps to you assemble your source when you don´t have the other(s)
external file(s).
It is usual (common) when you try to assemble your file, sometimes you
get an error message from your assembler (example: masm) saying that it
is missing one of the include files (.inc, .asm, or .lib etc).
On masm board or win32 asm board for example, many times when i was
trying to assemble a project i couldn´t be able to assemble a given
source, because the file that were uploaded did not contained one (or
more) of the necessary files to be used.
If your project have few multiple files..let´s say 02, 3, 5 ...this
problem _tend_ to don´t happen that offten (but it surelly happens) ,
but when you have dozens or hundreds of different sources to be
"included" it is easy to happen those kind of errors.
So, multiple files are not the proper answer for everything. This is
the major disadvantage of having multiple files.
On the other hand, with a single file, this problem would never exists.
All it needs is someone pass to you his single asm file to you
assemble. You don´t need anything more then it.
In RosAsm if your source gets big, or if you want to organize the
functions on your code, all you need to do is "split" your code
internally. I mean, all you need is use the command TITLE to you be
able to internally separate your source inside the source editor. So
you can actually read in one Tab (Title) a certain function, and in
another Tab you can see another function.(Or any other part of the code
you want to be separated)
________________________________________________________
Library files and linkage have some problems that we must consider.
a) When you think in library files that can be linked to your
application you get the risk of restrict the capabilities of your own
program. Let me try to explain :)
We all know that a library file is fixed. So far, the object code
cannot be, in general, modifiable. (Except for one or two tools called
obj2asm that you are supposed to be able to retrieve back the contents
of a given .obj to asm code.)
If you build your library files (.obj or .lib) on C or C++, and wants
to link it with an common assembler, this is not - generally speaking -
a good idea. This is not a good way to go, because when you are dealing
with those object files produced by a C/C++ compiler you don´t have
access to the internal data, i mean, you can´t modify the code as
needed (if it is needed). So if, for some reason the library file is
bloated, you will disseminate bloated code all over the other apps
from whom you were linking your object file.
It get worst when you don´t have the C or C++ source...imagine that
you got the object file from a friend, or somehow you don´t have the
source code. All you have is the object file.
Again, if the obj file have bloated code, you are doomed to use it as
it is, like it or not.
It could be an good idea importing and linking object files that where
produced by C or C++ for example, except for the fact that you are
restricted to use them and not _modify/fix_ them.
Also, if you want let´s say to use on your C/C++ app a library made
with Delphi, for example, or with any other object file that is OMF
(and not Coff), you can´t use it, unless you convert the OMF to Coff
with another tool. (And yet..you don´t have access to the internal
data as well)
So, the reason why linking _for me_ is not a good idea is basically
because you can´t fix the object code, and you can´t use the source
code (specially, if it came from C or C+ sources..i mean...when you
don´t have the asm source).
b) However, exporting an object file (.lib or .obj from an asm source)
to be used in your other C/C++ applications could be usefull because
since you wrote them in assembly, it means that you have more control
of the code and, by consequence, the quality of the data stored inside
the object file. - Again...assuming you have the source code in asm.
The only question here is..Why ? If you are building your app in
assembly, why would you want that the object code produced by it,
should be used or linked on a C or C++ compiler ?
You may argue: well....Sometimes i want a routine or library built in
asm on my C/C++ projects....Well..if is that it...so, use inline
assembly, it is way better when you are used to your compiler syntaxes,
and don´t have to learn how to use another asembler just to produce an
object code, when you own compiler can do that with the routines you
built inline.
One reason that it can be usefull is portability to other assemblers.
For example i have a object code produced in masm, and want to use this
on my fasm project (I don´t know if fasm allow linking, but..i guess
you got the idea).
But..again..this is only usefull..assuming you have the source code
that produced that object file, so if something is wrong, you can
modify it with your assembler, and fix the object code to be used in
another assembler.
So, in both cases (Importing and exporting) it is better that you have
the source code or some representation of it.
What we are currently doing with the LibScanner can also be used to
solve those situations, even when you don[t have the source.
It is primarilly designed for a tool we are working with called DIS
System to be used with the disassembler as we already told here many
times...But also, it can be used to you translate the source inside a
given object file, and fix it !!!.....Not that it will produce any
object code for now...it will produce the source code to you
use/modify/fix it.
So, if you have a C or C++ object code (Coff for now, but
later...Delphi, or Borland OMF, DCU, CVL libraries), you don´t need a
linker. All you need is the source code. When you suceeded to
retrieve/translate the source code, all you need to do is store it on
the clip features, for example.
This is what the clip feature is for. You can save your functions to be
reused later with other apps you want to build.
Best Regards,
Guga
Guga
CVL Libraries ? Sorry.. I mistyped
(Coff for now, but later...Delphi, or Borland OMF, DCU, VCL
libraries),
Guga
Richard Cooper
> About the single (Unique) source, this is not a problem. In fact, it
> helps to you assemble your source when you don´t have the other(s)
> external file(s).
Well, if I lose some of my source, then I certainly don't expect to be
able to assemble the code. I also wouldn't expect to be able to assemble
RosAsm code if half of the file turned up missing.
> It is usual (common) when you try to assemble your file, sometimes you
> get an error message from your assembler (example: masm) saying that it
> is missing one of the include files (.inc, .asm, or .lib etc).
I've never had that happen. I never include files that I don't have.
> On masm board or win32 asm board for example, many times when i was
> trying to assemble a project i couldn´t be able to assemble a given
> source, because the file that were uploaded did not contained one (or
> more) of the necessary files to be used.
Well, that's a problem with the person not having given you the entire
source then. If I gave you half a RosAsm source, then you wouldn't be
able to assemble that either.
Granted, it's typical for some people to just assume that your system has
the same files that theirs does, some programmers do that all of the time
with DLL files, like VBRUN45.DLL or whatever it was.
I don't see the logic in enforcing restrictions on yourself as a way of
dealing with other people's mistakes.
> If your project have few multiple files..let´s say 02, 3, 5 ...this
> problem _tend_ to don´t happen that offten (but it surelly happens) ,
> but when you have dozens or hundreds of different sources to be
> "included" it is easy to happen those kind of errors.
Then you need a better tracking system for your files.
Besides, if you want to eliminate that problem by combining all of those
files into one, that's always an option, but it shouldn't be a requirement.
> So, multiple files are not the proper answer for everything. This is
> the major disadvantage of having multiple files.
The major disadvantage of allowing multiple files is that you don't
believe they are the proper answer for everything? What about the things
for which you do believe they are the proper answer? What about the
things for which other people believe they are a proper answer?
Hell, what about making software that serves the user instead of yourself?
It's fine if you want to make your program not support multiple files,
it's your program and you can make it do whatever you want. However, to
claim that it's a universally beneficial feature is just a lie. It may
help you, since you don't want to use multiple files, and you don't want
other people to be able to use them either, but it certainly does nothing
to help someone who does want to use multiple files.
> In RosAsm if your source gets big, or if you want to organize the
> functions on your code, all you need to do is "split" your code
> internally.
I really wish I could find a text editor (for a linux console) that
supported that feature. It was great to have in QuickBASIC, it made
dealing with large sources very easy. However, it's no substitute for
multiple sources. Even in QuickBASIC I used multiple sources occasionally.
> a) When you think in library files that can be linked to your
> application you get the risk of restrict the capabilities of your own
> program.
Even so, shouldn't it still be my choice?
> We all know that a library file is fixed.
Not if it's my library.
> So far, the object code cannot be, in general, modifiable.
Short of a recompile.
> If you build your library files (.obj or .lib) on C or C++, and wants
> to link it with an common assembler, this is not - generally speaking -
> a good idea. This is not a good way to go, because when you are dealing
> with those object files produced by a C/C++ compiler you don´t have
> access to the internal data, i mean, you can´t modify the code as
> needed (if it is needed). So if, for some reason the library file is
> bloated, you will disseminate bloated code all over the other apps
> from whom you were linking your object file.
Again, it should be my choice to do that if I so desire.
If a library isn't working out for me, wether it's because I don't like
the size of it's code or some other reason, I'm always free to simply not
use the library. Libraries don't have to be unsupported for me to be able
to decide that I don't want to use one.
> It get worst when you don´t have the C or C++ source...imagine that
> you got the object file from a friend, or somehow you don´t have the
> source code. All you have is the object file.
In that case I wouldn't using the library unless I didn't have any other
choice.
> Again, if the obj file have bloated code, you are doomed to use it as
> it is, like it or not.
However, all that a 'you can't link to external code' feature does to help
me out with this problem is make it so that I can't write a program that
uses that object code at all. At least without the 'you can't link to
external code' feature I could write a bloated program that used that
object code. A bloated program is much better than no program at all.
I also assume that you're overestimating when you talk about bloated.
Most assembly programmers tend to consider anything larger than a few
kilobytes to be bloated. No consideration is ever made for what the code
does, and in fact features such as comprehensive error messages and error
checking in general are frequently left out of assembly programs because
those things cause bloat.
There's a similar deal with code execution time, anything that takes
longer than half the time an equivelant C program takes is slow. So by
definition, all C programs are slow. Again, assembly programs frequently
have to dump features in order to avoid being slow.
When I write programs, I'm interested in making a good program, not a
small program or a fast program. So the fact that some piece of object
code may not be as good as the equivelant written in assembly isn't of
much importance to me. If the object code is good enough for me, then
I'll use it.
> It could be an good idea importing and linking object files that where
> produced by C or C++ for example, except for the fact that you are
> restricted to use them and not _modify/fix_ them.
Again, I'm free to simply not use the library if I don't like it, and I
don't need a 'you can't use libraries' feature to allow me to do so.
> So, the reason why linking _for me_ is not a good idea is basically
The important key phrase there is "for me", linking is a good idea for
pleanty of other people.
> b) However, exporting an object file (.lib or .obj from an asm source)
> to be used in your other C/C++ applications could be usefull because
> since you wrote them in assembly, it means that you have more control
> of the code and, by consequence, the quality of the data stored inside
> the object file. - Again...assuming you have the source code in asm.
You might also want to link your object code from one assembler to object
code from another assembler. You might even want to link object code from
one assembler to object code from that same assembler. This is done quite
frequently, since it speeds up recompiles. When a source file isn't
modified, the object code to that source file doesn't need to be
reassembled, and so the compilation script only has to reassemble just the
one file which was modified and then link all of the object code together
again, as opposed to running all of the source code through the assembler
again.
> You may argue: well....Sometimes i want a routine or library built in
> asm on my C/C++ projects....Well..if is that it...so, use inline
> assembly, it is way better when you are used to your compiler syntaxes,
> and don´t have to learn how to use another asembler just to produce an
> object code, when you own compiler can do that with the routines you
> built inline.
What if someone likes RosAsm better than the inline assembler? Inline
assembly doesn't offer you any extra features if you're writing the entire
function as inline assembly, so in that case you're better off if you
write the function in real assembly and just link it, as that lets you use
the assembler of your choice, assuming, of course, that the assembler of
your choice isn't RosAsm.
> One reason that it can be usefull is portability to other assemblers.
> For example i have a object code produced in masm, and want to use this
> on my fasm project (I don´t know if fasm allow linking, but..i guess
> you got the idea).
>
> But..again..this is only usefull..assuming you have the source code
> that produced that object file, so if something is wrong, you can
> modify it with your assembler, and fix the object code to be used in
> another assembler.
No, it's also quite useful if that's just the way that I want to do it.
Just because you don't like to do certain things doesn't mean that those
things aren't useful for other people.
> So, in both cases (Importing and exporting) it is better that you have
> the source code or some representation of it.
Certainly, but like I've said, even if you don't have the source, it's
still better to at least have the option of using object code.
> What we are currently doing with the LibScanner can also be used to
> solve those situations, even when you don[t have the source.
>
> It is primarilly designed for a tool we are working with called DIS
> System to be used with the disassembler as we already told here many
> times...But also, it can be used to you translate the source inside a
> given object file, and fix it !!!.....Not that it will produce any
> object code for now...it will produce the source code to you
> use/modify/fix it.
Automatic disassembly? That'll never work.
What happens when your disassembler comes across the bytes "89C2" and
"8BD0"? It's going to disassemble them both as "mov edx, eax", because
that's what they are. However, when RosAsm reassembles the two resulting
"mov edx, eax" instructions, it's going to encode them both as either
"89C2" or "8BD0" because "mov edx, eax" contains no information about
which of the origional two byte codes may have disassembled into the
instruction.
Now that's not really a problem for instructions, but what if the bytes
were actually data that the disassembler mistakenly thought was
instructions? When it reassembles, it's going to create different data,
and so the code will no longer function. (It is possible to have data in
the code segment.) So the code that reads that data is now going to read
something else, and so the disassembly-reassembly process isn't going to
work.
Like Randy said, being able to disassemble object code into source code is
no substitute for being able to use the object code.
> This is what the clip feature is for. You can save your functions to be
> reused later with other apps you want to build.
I shouldn't be tied down to the RosAsm editor though. I've never met an
IDE that I liked (unless you count the QuickBASIC editor), and I doubt
RosAsm's IDE would be any better. After leaving the QuickBASIC world, I'm
far too used to having my choice of source editor to be tied down to a
editor which someone else has decided is the one that is best for me.
Betov
news:op.sxecv...@sucks.airplane.fire:
> [...]
>
> Well, if I lose some of my source, then I certainly don't expect to be
> able to assemble the code. I also wouldn't expect to be able to
> assemble RosAsm code if half of the file turned up missing.
This is simply impossible Troll:
The ony way we know of, for having "half of the file turned
up missing", in a RosAsm Produced PE, is to take a big hammer
and to knock hard and repetitively upon the Hard Disk.
> [...]
>
> Well, that's a problem with the person not having given you the entire
> source then. If I gave you half a RosAsm source, then you wouldn't
> be able to assemble that either.
This is simply impossible, Troll:
You cannot remove half of a Source from a RosAsm
produced PE.
>> We all know that a library file is fixed.
>
> Not if it's my library.
This would be impossible with RosAsm, Troll:
RosAsm does not do Libraries.
> Automatic disassembly? That'll never work.
The reverse is proven true by RosAsm Disassembler, Troll.
> Like Randy said, ...
Ah! That explains a lot, Troll... :))
> I shouldn't be tied down to the RosAsm editor though. I've never met
> an IDE that I liked (unless you count the QuickBASIC editor), and I
> doubt RosAsm's IDE would be any better.
If you never took any look, what tree are you barking at,
Troll?
:)
Betov.
Richard Cooper
> The ony way we know of, for having "half of the file turned
> up missing", in a RosAsm Produced PE, is to take a big hammer
> and to knock hard and repetitively upon the Hard Disk.
Actually, that's definately not the only way we know of. For example:
Take a small hammer and to knock hard and repetitively upon the hard disk.
Take a big hammer and to knock lightly and repetitively upon the hard disk.
Take a big hammer and to knock hard just once upon the hard disk.
You see, there's really quite a few ways it could happen.
> You cannot remove half of a Source from a RosAsm produced PE.
What about just removing half of the source code from a RosAsm source? Or
does RosAsm not support source files too, as you might want to compile
someone's program but they forgot to give you the source file?
>>> We all know that a library file is fixed.
>>
>> Not if it's my library.
>
> RosAsm does not do Libraries.
So RosAsm does not do libraries because RosAsm does not do libraries?
That seems to be where we're at. RosAsm does not do libraries, so the
library is not my library, and so the library is unmodifiable, and so I
don't want to use the library, and so RosAsm does not do libraries. Not
only is that circular logic, but not a single step in that chain of logic
makes any sense.
>> Automatic disassembly? That'll never work.
>
> The reverse is proven true by RosAsm Disassembler, Troll.
So how do the RosAsm Disassembler and the RosAsm Assembler work together
to handle things such as "89C2" and "8BD0"? Does it always properly guess
wether bytes are code or data, and therefore never make such a mistake? I
find that hard to believe.
Randy says that the disassembler creates normal disassembly output, that
is, that the disassembly it creates cannot be magically reassembled into a
working program for anything other than the easiest to disassemble
programs. I find that much easier to believe.
>> Like Randy said, ...
>
> Ah! That explains a lot, Troll... :))
Is he wrong?
By the way, what exactly is the intended meaning when someone calls you a
troll and then follows it up with a smiley? I don't get it.
> If you never took any look, what tree are you barking at, Troll?
Ok, first of all, dogs bark, not trolls. Second, dogs don't typically
bark at trees, or anything else that doesn't move for that matter. Now
dogs do occasionally bark up trees, but that's only because they're
barking at something that is up in the tree that does move.
> :)
So ambiguous...
Paul Dunn
> This is what the clip feature is for. You can save your functions to
> be
> reused later with other apps you want to build.
So if I were to build an app with some clip library functions, are they
copied directly into your source, or simply referenced? If I were then to
later update the clip library with superior functions, will rosasm
automatically make those changes to my source, or would I have to manually
locate the function, remove it, and re-paste the new clip library code?
Betov
news:e3UXe.10283$ws4....@newsfe5-win.ntli.net:
Feel free to use an inferior technology, that will
foolish you, if this is what you prefer to the Asm
ways of programming, Paul:
Assembly is not for guys who believe in baseless
Mythologies.
Betov.
Frank Kotler
> You cannot remove half of a Source from a RosAsm
> produced PE.
Wanna bet?
Best,
Frank
Bertrand Augereau
>>they copied directly into your source, or simply referenced? If I were
>>then to later update the clip library with superior functions, will
>>rosasm automatically make those changes to my source, or would I have
>>to manually locate the function, remove it, and re-paste the new clip
>>library code?
>
>
> Feel free to use an inferior technology, that will
> foolish you, if this is what you prefer to the Asm
> ways of programming, Paul:
Why don't you answer the questions? This is the occasion to prove the
superiority of the clip technology!
And other questions : How do you do concurrent work on a project with
RosAsm if the project is one file?
Do you use a file revision system?
Do you merge modifications by hand by copying blocks in the main RosAsm
version?
Do you have to wait somebody has finished working to begin modifying the
project?
I really suspect that multiple files is mandatory when working with a
large team on the same project.
Betov
h...@comcast.com:
> Betov wrote:
>
>> You cannot remove half of a Source from a RosAsm
>> produced PE.
>
> Wanna bet?
:))))))
No, i can't compete, in matter of bets, with an
Hexa Editor.
:))))))
Betov.
Guga
they copied directly into your source, or simply referenced?"
At the actual stage of the developments, if you use the clip feature,
they are copied.
"If I were then to later update the clip library with superior
functions, will rosasm automatically make those changes to my source,
or would I have to manually locate the function, remove it, and
re-paste the new clip library code?"
Automating the process can be used on the DIS system that will be also
used to update the fucntions for the clip feature. So, once you build
your code and wants to store your own functions to be used as an
internal "library" some automation could be necessary to also update it
onto the clip feature.
An integration betwen the DIS system and the clip features is not out
of the development plans. Also updating the clip feature itself for
this purposes (The integration with the DIS system, i mean) eventually
will be done too when we finish the other works we are currently on.
"How do you do concurrent work on a project with RosAsm if the project
is one file?"
You mean, several people working on the same project ? Simple....they
have the source for each part and work on the parts of it individually.
It is how is done with RosAsm itself...several people are working at
the same time on a different part of the project. When some of us
finishes something, it only requires an update on the targeted version.
For example, you are working on a game development. You built the
skeleton of parts of the game and the major code is assembled
(compiled). You are working, let´s say on a particle system, another
team is working on a editor for the scenarios, another is building on
the Gui. Once the teams wants to see if their code is being assembled,
all they need to do is compile the parts of the code they are currently
working on. So, when all of each team have finished their coding and
wants to put together on the whole game, all they need to do is merge
the files in the targeted project.
The targeted file, instead having the "include" command, will contain
only separated TITLES for each part. Example, the skeleton contains:
TITLE Main
(Main code a certain team is working on - work of Team 1)
TITLE Particles
(At 1st, it is empty on the main project - The particles code that the
other team is currectly working. Here is the place where their code
will be merged. work of Team 2)
TITLE Gui
(At 1st, it is empty on the main project - The gui code that the other
team is currectly working. Here is the place where their code will be
merged. work of Team 2)
Teams 2 and 3 are working independently..so, there is no need that
their sources have titles because the main target project already have
one.
All it is needed is you open one of the sources in RosAsm, and merge
the other clicking on Replace the source. So, You click on replace Gui
Title from Team 3 on the Main Target project. It will replace the empty
Gui Title with the code related for the GUI that the team 3 is
working....
The same for team 2.
At the end all is needed is merge the code when each team is finishing,
and start testing the produced app.
"Do you use a file revision system? "
Not sure if i understood this...But....a revision can be done whit the
security item settled to checked to on the configurations
menu...Whenever a source is changed, you is warned when you are trying
to assembled it.
About the revision itself...(I´ll try to answer in what i understood
the question...so..if this is not what you asked, pls explain to me
what exactly you mean.). If you meant for revision avoiding assemblying
bad instructions, this is already done in RosAsm..You can´t assemble
code that is not working...I mean, if you mistype something, or make
incorrect usage of mnemonics, your code won´t be assembled, because
RosAsm will warn about the error you are doing.
Whenever you suceed to assemble a project it means that your source
file have no errors.
"Do you merge modifications by hand by copying blocks in the main
RosAsm version?"
By Hand ? You mean..you have to write directly on the main target the
modificatinos ? If is that it..no...this is not ncessary. You can work
on a separated file and only merge it like above.
"Do you have to wait somebody has finished working to begin modifying
the project? "
No. You can work independetly. As i said, different teams can work on
different parts of the whole project.
"I really suspect that multiple files is mandatory when working with a
large team on the same project."
Yes....it is important. And this is allowed in RosAsm...each team can
work independently on a certain part of the whole project. It is not
necessary that each team have to wait for the other, or have to use the
whole source of them all.
Best Regards,
Guga
Betov
news:433017b5$0$5407$8fcf...@news.wanadoo.fr:
>>>So if I were to build an app with some clip library functions, are
>>>they copied directly into your source, or simply referenced? If I were
>>>then to later update the clip library with superior functions, will
>>>rosasm automatically make those changes to my source, or would I have
>>>to manually locate the function, remove it, and re-paste the new clip
>>>library code?
>>
>>
>> Feel free to use an inferior technology, that will
>> foolish you, if this is what you prefer to the Asm
>> ways of programming, Paul:
>
> Why don't you answer the questions? This is the occasion to prove the
> superiority of the clip technology!
Because there is nothing to be answered: If the guy had
taken a look, he would know that the Clip System is for
small snippets, and that for more important Materials,
which can be shared by several Projects, on the same
Computer, there is the "IncInclude" Pre-Parser, that
does way more, and way better, than any "Include".
> And other questions : How do you do concurrent work on a project with
> RosAsm if the project is one file?
We depress [Ctrl]/[S] for saving the concerned TITLE, and
exchange the .asm File. For Resources exchanges, we also
have special Binary Formats, and all of these make the
exchanges as simple as a Click.
> Do you use a file revision system?
Of course not.
> Do you merge modifications by hand by copying blocks in the main RosAsm
> version?
Of course not.
> Do you have to wait somebody has finished working to begin modifying the
> project?
Our rule is quite simple: Once a volunteer has been attributed
a TITLE, _he_, and only _he_ is allowed to touch _his_ TITLE.
In other words, we never have two volunteers writing the same
TITLE at the same time, and when two volunteers "work around"
a same TITLE (for example, actualy, Guga and me working both
at a time on the LibScanner), there is one doing one task
(example, searching for the Doc, preparing the developements,
controling the progresses,...), while the other one really
_writes_ the TITLE.
When two volunteers really want to work (_write_) on the
same component, we divide the TITLE into two TITLEs. Example,
recently Ludwig, who is in charge of the Debugger, wrote
something for the Assembler... in a _separated_ TITLE.
When finished, merging two TITLEs is just a matter of
deleting one Statement in the Source.
> I really suspect that multiple files is mandatory when working with a
> large team on the same project.
Up to now, whatever number of volunteers working directly on
some part of RosAsm, we never had any problem, with the actual
methods, and, in my opinion, even though RosAsm has the most
important Team of Developpers for an Assembly Project, we could
even be 10 times more volunteers, that it would not make any
difference.
Betov.
Bertrand Augereau
This is a...mmmh... original system :)
There has been a debate for a long time if the best representation for
source code is a bunch of ASCII files. I think it is, except if you can
provide all the tools that exist for processing text (regex,
preprocessor, and so on...)
(The file revision systems refer to CVS, SVN, VSS and such... )
Guga
The incIncluder is simple to use. On the separated teams i posted
before. you can have
a) Team 1 --> Working on Main project...called game.exe
b) Team2 --> working on a part of the source code for the
particles...they can name their sources as particle.asm
c) Team3 --> working on a part of the source code for the Gui...they
can name their sources as Gui.asm
At the end of each team job (or if they only wants to test as the
actual stage of the develo´pments. The game source will conatins
something like this:
TITLE MainCode
(Team 1 main work)
TITLE Particles
(Team 2 wants to insert his soruce here)
TITLE Gui
(TEam 3 wants to put his source here)
So, all it is needed is you put the incinclude preparse statement on
the main games source like:
PREPARSE incIncluder
INCINCLUDE c:\Particles.asm
INCINCLUDE c:\Gui.asm
When you assemble it, all different parts of the source will be merged
on the main app.
Best Regards,
Guga
Bertrand Augereau
By the way, since you are taking a game as an example, I work on a game
(and artists tools that come with) that compiles roughly 1,400,000 lines
of HLL (maybe 2,000 of ASM :) ), 500,000 lines of script and thousands
of file, so physical organisation of files and dependency management
becomes quite important... You can't rebuild the world everytime :)
Betov
news:433034a7$0$7868$8fcf...@news.wanadoo.fr:
> By the way, since you are taking a game as an example, I work on a game
> (and artists tools that come with) that compiles roughly 1,400,000
lines
> of HLL (maybe 2,000 of ASM :) ), 500,000 lines of script and thousands
> of file, so physical organisation of files and dependency management
> becomes quite important... You can't rebuild the world everytime :)
I hope that you are payed on a base of "Number of Lines".
:]]]]]]]]]]]]]]]]
Betov.
rand...@earthlink.net
Betov wrote:
> >
> > Well, if I lose some of my source, then I certainly don't expect to be
> > able to assemble the code. I also wouldn't expect to be able to
> > assemble RosAsm code if half of the file turned up missing.
>
> This is simply impossible Troll:
Have you so quickly forgotten the fact that bugs can crash your
assembler, losing user data? Are you claiming that RosAsm has no bugs
that will ever result in lost user data? Are you claiming that RosAsm
users cannot make mistakes and accidentally delete code from their
source file, do an assembly (which, disasterously, overwrites the
"source file" deleting all the original code)?
Oh, I forgot, you're assuming that the user makes backups to prevent
data loss in these situations. It's always the *user's* fault, never
the assembler's design that results in lost data.
>
> The ony way we know of, for having "half of the file turned
> up missing", in a RosAsm Produced PE, is to take a big hammer
> and to knock hard and repetitively upon the Hard Disk.
Or accidental erasure, followed by a "compile" command (rather than a
"save file" command).
This is a big problem with the "source file is part of the EXE"
approach.
>
> > [...]
> >
> > Well, that's a problem with the person not having given you the entire
> > source then. If I gave you half a RosAsm source, then you wouldn't
> > be able to assemble that either.
>
> This is simply impossible, Troll:
>
> You cannot remove half of a Source from a RosAsm
> produced PE.
Sure you can. You delete a bunch of statements to see what would happen
without them and then compile program program, forgetting the fact that
compile also means "save to disk." Arrrrgh!
>
>
> >> We all know that a library file is fixed.
> >
> > Not if it's my library.
>
> This would be impossible with RosAsm, Troll:
>
> RosAsm does not do Libraries.
I do believe that's the point. And it's the #1 reason why almost no
serious assembly language programmers use RosAsm. Of course, if these
problem were corrected, there are many other problems RosAsm possesses,
but most people don't get past the "no libraries" part before moving on
to something else.
>
>
> > Automatic disassembly? That'll never work.
>
> The reverse is proven true by RosAsm Disassembler, Troll.
So now you're claiming that automatic disassembly works? As in
"perfectly"? We've been there before and even you admit that it doesn't
work perfectly. And the example Richard points out is a *good* example
of the problem with automatic disassembly. Let me give you another --
the disassembler disassembles four bytes $81256845 as a DWORD value,
but really it's a *pointer* to some object in the source code.
Reassembling the code at a different address in memory breaks the
pointer because the "DWORD 0x81256845" statement (or whatever) isn't
properly relocated. Sure, you can catch *some* of these, but the
halting problem guarantees that you cannot catch all of them because
differentiating code and data is an undecidable problem. The sooner
you realize this, and the sooner you add interactive capabilities to
you disassembler so the end user can help correct errors on the part of
your disassembler, the sooner you disassembler might actually be useful
for something real.
>
>
> > Like Randy said, ...
>
> Ah! That explains a lot, Troll... :))
Sure. Like why you're calling Richard all kinds of nasty names.
>
>
> > I shouldn't be tied down to the RosAsm editor though. I've never met
> > an IDE that I liked (unless you count the QuickBASIC editor), and I
> > doubt RosAsm's IDE would be any better.
>
> If you never took any look, what tree are you barking at,
> Troll?
If he's happy with his editor, why should he even have to read the
documentation for your's?
Cheers,
Randy Hyde
rand...@earthlink.net
Betov wrote:
> >
> > Why don't you answer the questions? This is the occasion to prove the
> > superiority of the clip technology!
>
> Because there is nothing to be answered:
IOW, the clip system is in no way shape or form superior to statically
linked library modules.
>
>
> > And other questions : How do you do concurrent work on a project with
> > RosAsm if the project is one file?
>
> We depress [Ctrl]/[S] for saving the concerned TITLE, and
> exchange the .asm File. For Resources exchanges, we also
> have special Binary Formats, and all of these make the
> exchanges as simple as a Click.
IOW, it's all manual. The RosAsm team has no clue about modern software
engineering techniques and how to manage team projects.
>
>
> > Do you use a file revision system?
>
> Of course not.
:-)
>
>
> > Do you merge modifications by hand by copying blocks in the main RosAsm
> > version?
>
> Of course not.
He's lying. Of course they do. He just doesn't understand what you're
asking.
>
>
> > Do you have to wait somebody has finished working to begin modifying the
> > project?
>
> Our rule is quite simple: Once a volunteer has been attributed
> a TITLE, _he_, and only _he_ is allowed to touch _his_ TITLE.
See the statement above.
Yep. The RosAsm scheme truly supports team projects :-) :-) :-)
>
> In other words, we never have two volunteers writing the same
> TITLE at the same time,
The RosAsm team doesnt understand what a "team project" is all about.
> and when two volunteers "work around"
> a same TITLE (for example, actualy, Guga and me working both
> at a time on the LibScanner), there is one doing one task
> (example, searching for the Doc, preparing the developements,
> controling the progresses,...), while the other one really
> _writes_ the TITLE.
They *really* don't understand what team project management is all
about.
>
> When two volunteers really want to work (_write_) on the
> same component, we divide the TITLE into two TITLEs.
They *really, really* don't understand how team project management
should be done.
> Example,
> recently Ludwig, who is in charge of the Debugger, wrote
> something for the Assembler... in a _separated_ TITLE.
It's really a completely separate project. Subject, of course, to the
limitations that it cannot reuse label and variable names from the
*other* separate applications that are merged into RosAsm. Such are the
benefits of the "monolithic source file format" that RosAsm forces on
its users.
>
> When finished, merging two TITLEs is just a matter of
> deleting one Statement in the Source.
And resolving things like conflicting names, merging duplicate code,
and all those other things that plague this type of "monolithic"
software development. The really sad thing is that the RosAsm team
really doesn't know any better.
>
>
> > I really suspect that multiple files is mandatory when working with a
> > large team on the same project.
>
> Up to now, whatever number of volunteers working directly on
> some part of RosAsm, we never had any problem, with the actual
> methods, and, in my opinion, even though RosAsm has the most
> important Team of Developpers for an Assembly Project, we could
> even be 10 times more volunteers, that it would not make any
> difference.
HaHaHa!
The leader of the RosAsm team demonstrates his software engineering
competence with this last statement!
Cheers,
Randy Hyde
Guga
who don´t know what you are talking about, and, by consequence, you
are spreading lies again.
Example:
"And resolving things like conflicting names, merging duplicate code,
and all those other things that plague this type of "monolithic"
software development. The really sad thing is that the RosAsm team
really doesn't know any better. "
Just a lie .. Duplicated symbols or functions when merged the user is
warned because it won ´t assemble the file due to the duplications.
The error management is exactlyto prevent this sort of things.
"> > Do you have to wait somebody has finished working to begin
modifying the project?
> Our rule is quite simple: Once a volunteer has been attributed a TITLE, _he_, and only _he_ is allowed to touch _his_ TITLE.
See the statement above.
Yep. The RosAsm scheme truly supports team projects :-) :-) :-)
> In other words, we never have two volunteers writing the same TITLE at the same time,
The RosAsm team doesnt understand what a "team project" is all about. "
Maybe you didn´t read what i posted or you just disconsidered on your
attacks on rene...but..on all you posted you really seems clueless on
what it is all about, the clip features, the incinclude statements
preparsers and the lib scanners.
"They *really, really* don't understand how team project management
should be done."
So, pls enlight us with your "universal" knowledge.
If that means disseminating arrogancy or flames on our team of
co-workers...Sorry..this won´t happen :)
A team work using different files and people thinking together of the
whole project is what a team work is based on. The way it is developed
is not different from other techniques of working in team you want to
impose...
Best Regards,
Guga
rand...@earthlink.net
Guga wrote:
> The only sad thing on your statements Randall is that you are the one
> who don´t know what you are talking about, and, by consequence, you
> are spreading lies again.
>
> Example:
>
> "And resolving things like conflicting names, merging duplicate code,
> and all those other things that plague this type of "monolithic"
> software development. The really sad thing is that the RosAsm team
> really doesn't know any better. "
>
> Just a lie .. Duplicated symbols or functions when merged the user is
> warned because it won ´t assemble the file due to the duplications.
> The error management is exactlyto prevent this sort of things.
You really do not understand why namespace pollution is a bad thing, do
you?
Then again, this should come as no surprise from a user of the
assembler that encourages people to use label names like I0, I1, I2,
I3, etc.
>
> > The RosAsm team doesnt understand what a "team project" is all about. "
>
> Maybe you didn´t read what i posted or you just disconsidered on your
> attacks on rene...but..on all you posted you really seems clueless on
> what it is all about, the clip features, the incinclude statements
> preparsers and the lib scanners.
How many professional developers, whose day jobs include work on large
software systems (tens to hundreds of programmers) are involved with
the development of RosAsm? I thought so. Does the phrase "the blind
leading the blind" mean anything to you? I'm sure, in your state of
ignorance, you think that what you're doing is "team programming." The
truth is, you only think this because you don't know any better. Those
who've actually done some *real* software engineering in their
lifetimes are laughing at you behind your backs.
>
>> "They *really, really* don't understand how team project management
>> should be done."
>
> So, pls enlight us with your "universal" knowledge.
Pick up any decent book on software engineering and team project
management. Read it. Practice what it preaches. You will quickly
discover *much* better ways of doing team projects. And you'll quickly
discover that RosAsm is somewhat under-featured for such a task.
>
> If that means disseminating arrogancy or flames on our team of
> co-workers...Sorry..this won´t happen :)
You're already doing that. Rene's approach of "I'm not providing
libraries because I want to force people to code the way I do" is a
perfect example of such arrogance. If you weren't forcing people to
work the way *you* wanted them too, you'd provide the static linking
capability and let *them* choose how to write their code.
>
> A team work using different files and people thinking together of the
> whole project is what a team work is based on. The way it is developed
> is not different from other techniques of working in team you want to
> impose...
You've got it backwards. RosAsm's current development scheme is the one
*forcing* things onto people. Forcing naming conventions for separate
components (which wouldn't be necessary if you supported static linking
with file-scope naming). Think about it. How would allowing people to
work on modules as separate object files *force* your users to do
something they're doing now? Heck, if they *wanted* to do the
monolithic thing, they *still* could. It's your current scheme that
adds the restrictions that force people to work a certain way.
Cheers,
Randy Hyde
rand...@earthlink.net
Guga wrote:
> Yes...i have forgoten to mention the incIncluder.
>
>
> The incIncluder is simple to use. On the separated teams i posted
> before. you can have
>
> a) Team 1 --> Working on Main project...called game.exe
>
> b) Team2 --> working on a part of the source code for the
> particles...they can name their sources as particle.asm
>
> c) Team3 --> working on a part of the source code for the Gui...they
> can name their sources as Gui.asm
>
> At the end of each team job (or if they only wants to test as the
> actual stage of the develo´pments. The game source will conatins
> something like this:
>
You really don't understand the problem of namespace pollution, do you?
Include files are not the solution you seek. Though they are slightly
better than monolithic source files in terms of managing source code,
they still suffer from many of the problems of monolithic files, plus
the fact that they slow things down quite a bit.
>
>
> When you assemble it, all different parts of the source will be merged
> on the main app.
So as long as you're agreeing with the fact that breaking the project
up into multiple files that can be edited separately, what is your
fundamental problem with "doing it the right way" and using statically
compiled object modules? Clearly you see the benefit of multiple file
projects. Why do you insist on trumpeting Rene's "party line" that
there is no benefit to static linking? Why don't you guys just break
down and add this facility to RosAsm? Even if you don't use it
yourselves, it should be clear that the fundamental reason that RosAsm
is a failure in the marketplace is because of the lack of ability to do
static linking. If adding conditional assembly and branch displacement
optimization was a reasonable thing to do in order to attract users to
RosAsm, why not static linking? Why do you insist on forcing your
concept of programming onto an unwilling world? Why not give the world
what it wants and make them happy? Do you feel it's important to force
your programming style unto an unwilling world?
Though I suspect that RosAsm's design makes it darn near impossible to
add static linking (burying source files in EXEs and that sort of
stuff), I can't imagine how writing a *disassembler* could be
considered to be less work than adding this one important feature.
Given that you (wrongly) assume that the disassembler would be a
substitute for static linking, I'd suggest you reconsider your
development strategy. You're quickly producing a useless
(non-interactive) disassembler that's little more than a toy or demo,
at fantastic effort. With that same effort you could have given
assembly programmers what they *really* want - library and static
linking support.
Cheers,
Randy Hyde
Guga
"(The file revision systems refer to CVS, SVN, VSS and such... )"
Oh..i understood now...a version control system...No, we don´t use it.
It wasn´t necessary pointing out line-by-line, all the differences in
each released version. We constantly work on the program (Due to the
newer developments it is pratically from weekly a new dev version is
released), so nowadays, releasing on every new version the lines where
the previous one was changed would be killing to maintain.
Sometimes we announces the fixes or modifications of the part of the
code on the board.
If a user is interested in see the new version and learn how something
new was built comparing to the older version, all he need to do is use
a comparition Ascii tool to compare the source...i guess CVS uses
windiff (Or something like that), but there are other good tools like
winmerge that shows the differents better (At least better for me...i
like winmerge :) ).
A tool able to made some reports showing the differences between the
newer and the older version is not a bad idea. But for now it is not
maintainable...maybe in future some volunteer can work on something
similar to it. (Not similar to CVS, but basically a tool able to build
a brief report with the new changes comparing older versions. A sort of
summary builder that will only export News.txt for example.)
Best Regards,
Guga
rand...@earthlink.net
Betov wrote:
> > Linking to or include a library would make sense if the libraries
> > would contain really useful things only.
> > I haven't found any real good code in any yet.
>
> In the team, everybody is in this opinion too.
And that's why RosAsm has so few users. Outside the RosAsm development
team, most people don't share that opinion.
> The (demential)
> work, we are actually doing on the LibScanner
The amazing thing is how much work you keep investing in different ways
(disassembler, "lib scanner", etc.) to *avoid* the task of supporting
statically linked code. Even given RosAsm's fundamental design flaws
(like buring source code in EXE files) that make support of
object-module generation difficult, it would be *far* less work in the
long run to just bite the bullet and provide library/object module
support for RosAsm than run off on all these other bizarre tangents.
> - that will take
> all of this in charge, anyway...
No, it won't solve the fundamental problem that people want to produce
object modules that they can link with their RosAsm code and with other
code. You put in all this effort and waste all of this time creating
all these half-baked applications that nobody really wants (and nobody
really wants to learn *how* to use). People already know how to use
linkers. They don't want to have to learn how to use a disassembler
(and learn how to clean up incorrectly disassembled code) or use a "lib
scanner" or use "TITLEs" or anything else to do what they already know
how to do with libraries. Therefore, they use another assembler and
ignore RosAsm.
> - is, first, designed to create
> a complete D.I.S. system, for the Disassembler.
The disassembler failed to ignite the "assembly rebirth" so now it
needs a "D.I.S." system. Or the Lib Scanner. Or whatever. The sooner
you admit to yourself that you are simply wrong about static linking,
and add that facility to RosAsm, the sooner people will seriously
consider your product.
> Another story...
Another Failure....
Cheers,
Randy Hyde
Betov
news:1127245687....@f14g2000cwb.googlegroups.com:
> You really don't understand the problem of namespace pollution, do you?
Ass-hole, given the impressive number of things that
you do not understand, you'd better shut up, instead
of inventing problems that do not exist.
:)
Betov.
Betov
news:1127238114.9...@g43g2000cwa.googlegroups.com:
> The RosAsm team doesnt understand what a "team project" is all about
Sure, ass-hole: We just do it, while almost all of the
other Assembly Projects are home made, one-man thingie.
[Not talking of your "HLL Pre-Parser" shitty Project,
that is "one-incompetent-man" thingie]
:)
Betov.
Betov
news:1127237706.7...@g49g2000cwa.googlegroups.com:
> Are you claiming that RosAsm has no bugs
> that will ever result in lost user data? Are you claiming that RosAsm
> users cannot make mistakes and accidentally delete code from their
> source file, do an assembly (which, disasterously, overwrites the
> "source file" deleting all the original code)?
No, ass-hole. I am claiming that, since the oncoming
of RosAsm, many years ago, we never saw this.
:)
Betov.
< http://rosam.org >
Betov
news:1127237706.7...@g49g2000cwa.googlegroups.com:
> So now you're claiming that automatic disassembly works?
Yes, ass-hole, it does, as anybody can see.
> As in
> "perfectly"?
No as-hole. "perfectly" is reserved to your HLL Pre-Parser,
like in "perfect shit".
:)
Betov.
Betov
news:1127246078.4...@g49g2000cwa.googlegroups.com:
> And that's why RosAsm has so few users. Outside the RosAsm development
> team, most people don't share that opinion.
Glad to hear that you know about the number of RosAsm
users. Maybe you could tell me, because... i do not
know how many, at all...
I am even constantly surprised to see new comers, i
never heard about, who never sent me any mail, and
who never asked any question, at the Board, who, all
a sudden, are able to come in the Developements Team,
for doing a very good job, like Toto did, last week.
:)
Quite a difference with your victims, who never stop
asking questions about "how to install", "why doesn't
it work", "What did i do wrong", and so on... isn't
it, ass-hole?
:))))))
Betov.
rand...@earthlink.net
Betov wrote:
>
> I am even constantly surprised to see new comers, i
> never heard about, who never sent me any mail, and
> who never asked any question, at the Board, who, all
> a sudden, are able to come in the Developements Team,
> for doing a very good job, like Toto did, last week.
Really? And how many would that be?
> Quite a difference with your victims, who never stop
> asking questions about "how to install", "why doesn't
> it work", "What did i do wrong", and so on... isn't
> it, ass-hole?
You don't even know who's using RosAsm and you profess to know all
about the HLA user base?
Cheers,
Randy Hyde
rand...@earthlink.net
Hmmmm...
You never saw it, but you put in a patch to print an error message
(involving the name "Master PDF")? You have a strange way of "never
seeing things."
Cheers,
Randy Hyde
rand...@earthlink.net
Betov wrote:
> "rand...@earthlink.net" <rand...@earthlink.net> écrivait
> news:1127237706.7...@g49g2000cwa.googlegroups.com:
>
> > So now you're claiming that automatic disassembly works?
>
> Yes, ass-hole, it does, as anybody can see.
Okay, then.
Great world announcement, everyone. Rene is once again claiming that
he's proven the concept of undecidability to be incorrect. His
disassembler can perfectly differentiate between code and data (a
problem that has been reduced to the halting problem, which has been
proven to be undecidable).
The only problem is, Rene tends to waffle a lot on this subject. When
he first started writing his disassembler, he gave us the impression
that writing a perfect disassembler was possible. Then, as he gained a
little experience, he started admitting that it was not possible. Now,
he seems to be doing a bit of that "chest-thumping" he talks about, and
is once again making impossible claims for his disassembler. I wonder
what he'll be claiming next week?
Cheers,
Randy Hyde