The Case Against RosAsm (#7) (LONG)
Randall Hyde
One of the reasons people write assembly code in
the first place is to produce efficient code.
"Optimizers will never replace hand optimized
code" is a common cry of assembly programmers
everywhere.
While this is certainly true, there are certain
optimizations that an assembler (or compiler) *can*
do that, even if they could be done just as well by
human beings, they're much better done by machine
as the optimizations are rather tedious to perform
and very mechanical in nature (i.e., perfectly
suited for a machine to do).
"Branch Displacement Optimization" is one of these
types of optimizations. I've written a separate
essay, which I've attached to the end of this post
(from the assembler/compiler technology area on
the MASM Forum) that explains the issues with
Branch displacement optimization, so I won't go
into the details here.
The first assembler I recall that provided
branch displacement optimization was (IIRC) a
product called "OptAsm" produced by SLR systems.
This was a MASM 5.1 compatible assembler available
in the late 1980s. It was very fast (faster than
TASM) and supported some really neat features like
branch displacement optimization. TASM and MASM
followed suit in the early 1990s. Today, most
commonly-used assemblers (e.g., MASM, TASM,
FASM, Gas, and HLA) support branch displacement
optimization. Even NASM, whose original authors
resisted the notion of this optimization, has
been updated to include this important feature
(thanks to Frank Kotler).
Here's what Rene has recently said about this feature:
>>>>> Rene Tournois:
About the jmps Size Optimizations, this is
a design choice. Given your competency level
in Assemblers design, i cannot rewrite again
and again what i wrote up there to explain to
readers what this design choice is for.
<<<<<<<
In the past, Rene has lamented the fact that
FASM has introduced this feature and that it
really should be something the assembler forces
the user to do because it will make that user
a better programmer and help them write better,
bug-free code (though how forcing the user to
endure the tedium of manually fixing out of range
branches reduces bugs is beyond me).
Every time this subject has come up, Rene has
stubbornly refused to even consider the fact that
the machine is better suited for branch optimizations
than the human programmer.
But good news! Rene seems to be getting attacks
from his own users now. And despite his claims that
he doesn't care whether anyone uses his product or
not, the fact that people are *rejecting* his product
because it doesn't do branch optimization is finally
starting to sink in. Here's a post of Rene's from
the RosAsm Forum:
>>>>>> Rene Tournois:
It seems that some assembly programmers consider
the fact of having the assembler automatically
optimizing the jumps sizes (JMP / Jcc Short/Long),
is an important point when choosing what Assembler to use.
My choice when designing RosAsm, was that the main
important point, with this, was to run an error case,
when a wanted short jump was longer than required,
because, forgetting to write some local Label Declaration
is a very usual error, we all do, and because such an
error, if not pointed out by the Assembler, at
Compile-Time, may be a real hell to point out,
with Run-Time Debugging.
So, is the Short-Long dilemna implemented in
RosAsm, and i will certainaly not kill such an
important advantage.
Nevertheless, given the actual implementation,
it remains perfectely possible to have the Assembler
optimizing the jumps size, in the "Long > short"
direction, what is the only interresting point, in
the optimizing approach.
This can be done a very simple way, without
changing anything at the syntax, and at the
way the errors Manager preverses us from bugs,
by runing the Encoder twice, if some Long jumps
are found be under the Byte Size limit. This could
be done, at the user point of view, by inserting
one another Item, in the Menu, saying [Compile and
optimize JMPs Sizes], or something like this.
<<<<<<<<<
Yeah! Rene is actually responding to demands from
the user base. Yeah! Rene is finally coming around
to realizing that Branch Displacement optimization
is something people demand. Can library support be
too far off?
The only scary thing is that if you know anything
all about branch displacment optimization, you'll
realize that Rene's discussion of the solution
(above) won't work. First of all, it can't be
done by running the "encoder" (code generator)
twice. Optimization is a multi-phase operation
(described later in this post, for Rene's
benefit). Second of all, Rene's refusal to
even *study* anything related to compiler theory
pretty much means he'll ignore the little essay
on this subject I've prepared and go off about how
I am too "incompetent" to understand the issues
(despite the fact that I *have* taught compiler
construction courses before). Oh well, his loss.
Maybe someday RosAsm will actually support
Branch Displacement optimization. Probably about
the same time Rene delivers on his promise to
support conditional assembly :-) (i.e., in a
couple of years). I sure hope he grabs a copy
of Tomasz' FASM assembler and studies that code
first. Otherwise, it's doubtful (based on the
bits and pieces of RosAsm source I've read)
that he's going to do a very successful job
of this.
You've got to ask yourself, "Do I want to use
an assembler that supports Branch Displacement
Optimization today? Or do I want to wait for
Rene to get his act together and add it to
RosAsm, maybe two years from now?"
Cheers,
Randy Hyde
==================================================
This is a short essay that attempts to explain the
basics of "displacement optimization" in machine
code such as on the x86. In posts I've made here
and on various newsgroups (comp.lang.asm.x86 and
alt.lang.asm) it is quite clear that many people
don't understand what this is all about, and even
those who do understand the basic issues can't
believe the problem is as difficult to solve
(optimally) as I claim that it is. In this essay
I'm hoping to explain the process and the problems
in such a way so to make all this clear.
What is This All About?
The first place to start is with the question
"what is branch displacement optimization?" On
certain CPUs (e.g., the x86), certain instructions
have a limited branch range because of the way the
CPU encodes the target address of the branch. For
example, a typical "JE" instruction on the x86 is
two bytes long - one byte for the opcode and one
byte for a relative displacement. This relative
displacement allows the instruction to transfer
control to some instruction within +/- 128 bytes
(roughly) of the JE instruction.
What happens if the target address is *not* within
range? Well, if the target address is within +/-
32K bytes, the 386 and later devices have a
special four-byte version of JE (two-byte opcode
and two-byte displacement) that can transfer
control to the label. If you're operating on a
chip earlier than the 386, you have to emit a
five-byte sequence like the following:
jne skipJmp ;two bytes
jmp target ;three bytes
skipJmp:
On any of these processors, if you want to jump
beyond a +/- 32K range, you have to use the above
sequence with a five-byte version of the JMP
instruction (bringing the total to seven bytes).
In early x86 assemblers (and in a few assemblers
that have been created lately), it was the
programmer's responsibility to manually encode the
displacement sizes of these jumps. Besides being a
pain in the butt to do manually, it was often the
case that the programmer *missed* several
optimization opportunities (hey, who wants to
count bytes in a program) and so the program was
not as optimal as it should have been.
It doesn't take a huge intuitive leap to realize
that this kind of grunt work is *exactly* the kind
of thing computers were designed to handle. As
such, in the late 1980's, various assemblers
started appearing that automatically handled the
correct branch displacements (in most cases,
anyway). I don't personally recall the name of the
product, but the first time I saw this feature was
in a MASM 5.1-compatible assembler (not MASM
itself); TASM had the feature next. I believe
Microsoft added this feature in MASM v6.0. Today,
assemblers like Gas, FASM, and NASM all suport
this feature (and probably others too, I haven't
looked that closely).
Why is this optimization even necessary? Well,
it's pretty obvious that if the target location of
a jump instruction is within +/- 128 bytes, you're
wasting two or more bytes if you're not using the
smaller version of the jump instruction.
Considering that most branches turn out to be
within this range and there are generally quite a
few branches in a program, just using the long
version of each branch can make the program quite
a bit larger than it needs to be.
The Problem
"So what's the big deal?" You're probably asking.
"Why not just scan through the file during
assembly and determine the distance to the target
location and pick the appropriate size for the
branch instruction?"
The problem is, the size of a given branch
instruction may determine the size(s) of some
other branch instruction(s). Consider the
following simple code sequence:
jmp target
<exactly 125 bytes of code>
jmp someOtherTarget
target:
If "someOtherTarget" is within the +/- 128 byte
range of the second jmp instruction above, you can
encode it with only two bytes on the x86;
otherwise you will need at least four bytes. If we
do encode this second jump instruction in two
bytes, then we can encode the first jump
instruction above in two bytes (the actual range
on the x86 is 127 bytes starting with the *next*
instruction after the conditional jump, or -128
bytes before the next instruction following the
conditional jump). OTOH, if the second jump
requires more than two bytes, so will the first
jump. Consider the following degenerate case:
jmp l1
<<125 bytes of code>>
jmp l2
l1:
<<125 bytes of code>>
jmp l3
l2:
<<125 bytes of code>>
jmp l4
l3:
.
.
.
etc.
The *last* jump in this sequence controls the
sizes of all the other jumps in the code! This is
because if the last one is a two-byte opcode, then
the next-to-last one can be two bytes, then the
one before than can be two bytes, then the one
before that...
Unfortunately, there is no easy way (and soon,
you'll see, efficient way) to determine the size
of these jump instructions in a single pass over
the object code the assembler generates. A typical
assembler will do the following:
1. Scan over all the opcodes and determine if any
branches can be reduced in size.
2. If the answer is yes, the assembler reduces the
size of those branches and adjusts all other
instructions whose target addresses and other
values have changed as a result of reducing the
size of the branch instructions.
3. If the answer was yes, repeat steps 1-3 until
you make a pass with no optimizations occuring.
Note, that in the worst case, this algorithm runs
in O(n^2) time (that is, the amount of time it
takes, worst case, is proportional to the square
of the number of branches in the program; double
the number of branches, it takes four times as
long to process them). This isn't very good. But
it isn't terrible, either.
Though the algorithm above looks easy enough, it
turns out to be insufficient. Consider the
following trivial code sequence:
target2:
jmp target1
<< 124 bytes of object code>>
jmp target2
target1:
If we start off assuming that the branches are
long (four bytes each), then a quick pass through
this section of code will suggest that
optimization is not possible. However, were you to
arbitrarily select one of these jumps and make it
a short jump, the other jump would also be short
and both jumps would be within range. Therefore,
an assembler that starts off using large
displacements and shrinks them down can miss
optimization opportunities such as this one.
Another possibility is to start with all short
displacements and expand them as necessary. The
reason many assemblers start with long
displacements and shrink them is for reasons of
robustness -- the code will work, even if it's
less optimal, if a defect causes you to miss an
optimization that could have been introduced into
the object code. OTOH, if you start with short
displacements and extend the ones that are out of
range, a defect in the "correction" process
results in defective code generation. As it turns
out, optimization isn't guaranteed when you start
small and work big, either. So those assembler
authors who choose the robust aren't necessarily
missing out on something.
OTOH, *most* branches are short to begin with, so
starting off with short displacements and
increasing the size of those that are out of range
is going to be faster (O(n^2) >> O(m^2) if n>m).
The hard part for people to believe is that
starting small and working big doesn't necessarily
guarantee an optimal sized object file. In fact,
and this is the part that really blows people
away, sometimes the smallest object file is
achieved by making certain branches larger that
could have been encoded as short branches!
Here's a short example of some MASM source code
that demonstrates this problem:
.386
.model flat, syscall
.code
_HLAMain proc
jmpLbl: jmp near ptr target
jmpSize = $-jmpLbl
byte 32 - jmpSize*2 dup (0)
target:
_HLAMain endp
end
Here's the assembly listing:
Code:
.386
.model flat, syscall
00000000 .code
00000000 _HLAMain proc
00000000 EB 1C jmpLbl: jmp target
00000002 = 00000002 jmpSize = $-jmpLbl
00000002 0000001C [ byte 32 - jmpSize*2 dup
(0)
00
]
0000001E target:
0000001E _HLAMain endp
end
Note that the "object code" is 30 bytes long
(1Eh). Also note that the jump instruction is two
bytes long (that is, it's a short jump).
Now look at what happens when we force the jump to
be a five-byte jump:
.386
.model flat, syscall
.code
_HLAMain proc
jmpLbl: jmp near ptr target
jmpSize = $-jmpLbl
byte 32 - jmpSize*2 dup (0)
target:
_HLAMain endp
end
;;; Listing:
.386
.model flat, syscall
00000000 .code
00000000 _HLAMain proc
00000000 E9 00000016 jmpLbl: jmp near ptr target
00000005 = 00000005 jmpSize = $-jmpLbl
00000005 00000016 [ byte 32 - jmpSize*2 dup
(0)
00
]
0000001B target:
0000001B _HLAMain endp
end
Note that although the jump is now *five* bytes
long (rather than two), the object module is
actually *shorter* (27 bytes [1Bh] rather than
30).
Therefore, you cannot guarantee that you've got
the shortest possible program by simply making all
the jumps as short as they can be and letting it
go at that.
Unfortunately, as this last example demonstrates,
it's quite difficult to determine the optimal
selection of short and long branch instructions in
order to optimize your code. In fact, there have
been some mathematical proofs that show that this
problem is "NP-Complete", which means that the
only way to guarantee you've got an optimal
solution is to try all possible combinations of
short and long displacements in the object file
and select the (or one of the) combination(s) that
is the shortest. Unfortunately, this is an
intractible problem. The algorithm given earlier
runs in quadratic time (O(n^2)), which isn't
great, but still tractible. The best known
algorithms for NP-Complete problems run in
exponential time (i.e., O(2^n) where 'n' is the
number of branches in the program). This means
that adding a *single* branch doubles the amount
of time needed to determine the optimal output
module. To put it bluntly, no computer available
today and, indeed, no computer we can ever imagine
building will be fast enough to handle the
branches found in a reasonably-sized application
program.
Yet assemblers available today *do* perform branch
displacements. So how come they don't run real
slow? The answer is that these assemblers *don't*
guarantee that you'll get an optimal program.
AFAIK, for example, none of them handle the last
case I gave. Most of them simply use the "start
large, work small" or "start small, work large"
algorithms given earlier (for those who have had a
data structures class/algorithms analysis course,
you can think of this as a form the "greedy"
algorithm). As such, while they produce *good*
code (typically better than what someone will
produce by hand), they do not necessarily produce
optimal code.
In fact, some assemblers limit the amount of
optimization they do in order to keep assembly
times low. TASM is famous for this; TASM has the
/M# directive that lets you specify the maximum
number of passes (this is, generally, done to
actually *increase* the default number of passes
that TASM performs). I don't have any information
on MASM. However, the fact that FASM usually
produces better code that MASM suggests that MASM
stops at one point or another, before FASM does. I
have no information on how NASM or Gas handles
branch displacement optimization, so I cannot
comment on their performance.
That's not to say that there is anything wrong
with the way these assemblers do their
"optimization." Most of the time they probably do
produce the optimal program, and when they don't,
they produce something very close to it. That's a
reasonable trade-off given the intractible
alternative.
Although branch displacement optimization is a
tedious chore and it's difficult to add to an
assembler, it is a prime example of one of those
things that computers are much better suited for
than human beings. A decade and a half ago it
might have been reasonable to expect the
programmer to manually take care of branch
displacement optimizations. But given the fact
that most reasonable assemblers today offer this
facility, it's moved into the "must-have" category
for anyone developing a serious assembler.
Betov
@newsread1.news.pas.earthlink.net:
[...]
You fall utterly flat here, Master Pdf:
* I never got _any_ request for jmps size optimization.
* No, i never "lamented" that FASM implemented this. I
just consider that this is not a good thing to implement
in an Assembler, as long as 1) nobody can seriously care
of saving a couple of bytes, nowadays, when Writting a PE
and 2) when someone has real Code level optimization work
to do (quite exeptional cases) he will have much more work
to do with multiple aspects of his Routine than with the
jmps sizes detail (i hope you see what i mean...).
* Very recently, i made up my mind, that i could, as well,
implement this in RosAsm Assembler, without killing the
so precious and so usefull error case coming, with the
way i managed to solve this problem, in relationship with
the True-Local-Labels implementation.
* I am thinking seriously of implementing this option,
when i will have some free time, only because, this
seem to be some choice criteria, when some guys search
for whatever Assembler to use ("Oh! This one does
jmps size optimization! This second does not! >>> i
choose "one" "... Well... :( ).
* As long this feature is very simple to implement in
RosAsm, with one single added pass... Why not implementing
it as an added option...
Betov.
Gerhard W. Gruber
<rand...@earthlink.net> in alt.lang.asm with
<S4MMb.7394$zj7....@newsread1.news.pas.earthlink.net>
>a better programmer and help them write better,
>bug-free code (though how forcing the user to
>endure the tedium of manually fixing out of range
>branches reduces bugs is beyond me).
I can see only one reason where it makes sense to let the human do this. If
you have very strict memory requirements, you may need to squeeze your code
into a certain amount of storage space. If your assembler makes this
optimization for you, it could very well be that the code grows to large so
that it doesn't fit in your space anymore. In this case it would probably be
better to let the human decide if he wants to have a larger instruction, or
rather rearranges the code in a way that the size fits. I think this type of
projectrequirements are rather rare, so I don't think that this is a general
issue for assemblerdevelopers. Also this could be turned on and off with a
commandlineoption or something similar.
>one another Item, in the Menu, saying [Compile and
>optimize JMPs Sizes], or something like this.
Which would be a good way to do it, if I understood it correctly.
--
Gerhard Gruber
Maintainer of
SoftICE for Linux - http://sourceforge.net/projects/pice
Fast application launcher - http://sourceforge.net/projects/launchmenu
Beth
Well, I'm thinking that an even easier way which would keep everyone
happy is to take a "do it unless I say so" approach...in other words,
if the programmer is "ambiguous" about the size of the jump, using
just "jmp", "jz", "jc" and so forth, then the assembler carries on to
automatically optimise the jumps...if, on the other hand, the
programmer leaves very specific instructions about the size of the
jump - such as "jmp far", "jz short", "jc near", etc. - then, because
it has been _explicitly_ given, the assembler respects the
programmer's choice in the matter...
Note that, with Rene's "the programmer always make it explicit
everywhere" approach, you'd have to be typing in the jump sizes
yourself, anyway...hence, for the coder who likes to do it manually,
they'll already be typing "je short" and so forth...things would be no
different to such coders and they could carry on doing it all manually
by _telling_ the assembler what sizes they want...
On the other hand, when the programmer is "ambiguous" about the jump
size - coding just "jmp", "je", etc. - then they don't seem very
concern about the exact size of the jump at all...in a sense, they are
not typing in "short" or "near" because, truth is, they don't
particularly care...it's saying "look, I need a jump here...it doesn't
matter which one, just so long as it works"...and as it has not been
told otherwise to use an explicit size of jump, then it does this
automatically...
Surely this scheme above is somewhat intuitive and allows everyone to
work just as they worked before - doing it all "manual" or leaving to
the assembler, as they choose - without actually asking for anyone to
do any differently than they would have done without it (as, of
course, the assembler which needs the "explicit size" specified every
time will already be asking the "manual" coder to write it in every
time...that's no different here, other than there's also the option of
putting just "jmp" alone when they'd rather that the assembler do it
:)...
All of this sounds like a good idea and a nice way to implement it?
Well, that's probably why all the assemblers that optimise branch
sizes _already_ take exactly this approach...if you tell it what sizes
you want, it respects that...if you don't give it any particular size
explicitly, then it takes this to mean: "up to you,
Mr.Assembler...whatever you think is best!"...because if you haven't
told the assembler any specific size, then you obviously don't
particularly care about that...
"Make things as simple as possible, but no simpler"
[ Einstein (paraphrase) ]
If you insist on command line options (although, that won't appy to
RosAsm because it works through the GUI and not via command lines but
it can be put into some "options" dialogue*), then what you could have
are a bunch of options like: "optimise branches" (the default...and it
behaves as above because this is what most programmers will probably
want and expect from the assembler so that it works like most other
assemblers :), "don't optimise; all jumps are short" (an _error_
therefore results if a jump cannot be short), "don't optimise; all
jumps are near" (same but with near jumps) and "don't optimise; all
jumps are far" (unlikely option with 32-bit OSes these days, which
don't use far jumps...but added for completeness...also, of course, a
far jump is _always_ possible so no errors will result from this
option :) and, perhaps, a "don't optimise; jump without explicit size
generates error" (this option would be too useful ordinarily but could
come in handy when "translating" source code that _doesn't_ use
explicit sizes but you want to add those sizes in "manually"
yourself...hence, this option allows you to get the compiler to
"double check" that every jump has an explicit size attached or it'll
stop and give an error :)...
Then, combined, this will allow everyone to do as they please...you
can leave it all to the assembler, leave some of it to the assembler,
take control over the process yourself and even, by using one of the
"don't optimise" options, turn things around so that you _must_ be
explicit about every single jump or it'll generate an error...you
could also throw in a TASM "M#" options to allow you to specify how
many passes you'd like the assembler to use when it's optimising
things, so you can even control whether it should aim for a quick
compile or try to optimise it better with more passes (Randy, you are,
for once, being far more cynical than I...couldn't Borland have simply
been giving _more control_ to the programmer over what it should aim
for rather than _solely_ about trying to "dupe" people that it's a
faster assembler? Nah, you're probably right...but, due credit, at
least you can _change_ it if you'd rather it did a better job and you
don't care about the extra time...with the others, you have to except
whatever some programmer at Microsoft thought was a good idea or
whatever and that's it...the end of the matter...like it or lump
it...it's, therefore, probably better to throw some "glowing praise"
towards Borland for this, in case other assembler authors are watching
so that they get the "sure, have your 'fancy' default options but
_don't_ ever forget the command line switch which lets the programmer
tell you to go to hell and leave their code alone!!" ;)...
Beth :)
Betov
$Uu6....@newsfep3-gui.server.ntli.net:
> Note that, with Rene's "the programmer always make it explicit
> everywhere" approach, you'd have to be typing in the jump sizes
> yourself, anyway...hence, for the coder who likes to do it manually,
> they'll already be typing "je short" and so forth...things would be no
> different to such coders and they could carry on doing it all manually
> by _telling_ the assembler what sizes they want...
>
Beth,
all of this is to be considerd _inside_ the overall
syntax and Language implementation.
In RosAsm the Short/Long dilemna is implemented that way:
je L0 ; Short Up
je L0< ; Short Up
je L0> ; Short Down
je L0<< ; Long Up
je L0>> ; Long Down
Also, RosAsm imlements true Local Labels. That is,
fully reusable Local Labels (no relationship with
Local _Symbols_... just in case someone would be
confusing...).
The way i implemented this is, mainly, as a usefull
error case when the user "forgets" to declare some
reusable Local Label (Many chance to have some "L0"
somewhere else in the Source, if not the required one).
This is the main reason why, in RosAsm, Jmps Sizes
are fully "under user control".
Now, all of this stupid debate reality is with Master
Pdf searching for whatever argument he ever could found
to list against RosAsm. The basis is:
RosAsm does not optimize Branchings >>> So RosAsm is
bad. And, as i suppose most readers do not well see
the reality of the problem, it seems i have to give
some infos:
1) jmps optimization is zero or very poor interrest.
2) jmps optimization are SIZEs optimizations.
3) Nobody cares, nowadays of saving a couple of Bytes
in a PE Application written in Assembly (what is the
only purpose of RosAsm).
3) The cases when the sizes optimizations might be
considered are for the "loop" and "jecxz" Instructions.
As long as the RosAsm syntax, already offers the true
Local Labels thingie, there is no chance that, in a well
RosAsm written Application, that any Plain Label could
be used inside such a branch.
Nevertheless, considering that the success of an Assembler
depends, mainly, on irrational choices criteriums and on
spreaded out propaganda ideas, i will much probably have
to implement this stupidity in RosAsm. It will come under
the form of a second Encoder Pass, selected by the user.
In fact, i don't think that this optimization would even
do any real work, as long as well written RosAsm Sources
cannot require this second pass, but, as long as we are,
here and with this, strictly, in the illusion world of
propaganda bound to uncompetency... why not?... Selling
Arguments... :( ...
Betov.
< http://betov.free.fr/RosAsm.html >
hutch--
The google server just dropped its bundle and took my post with it as
it failed so I will try again.
It is rare that I agree with Betov on anything but I agree with his
view on the compiler style of optimisation of jump lengths. If it does
anything it may act as a size optimisation but I seriously doubt it is
a peformance factor in 32 bit code.
I am of the view that assembler mnemonics should remain fully under
the control of the programmer and if they want to write Jxx SHORT
label, they can get that result if they wish.
When I get some more time, I will write a test piece for both jump
sizes to see if there is any speed difference but I would not hold out
much hope for it.
Regards,
hutch at movsd dot com
C
> I am of the view that assembler mnemonics should remain fully under
> the control of the programmer and if they want to write Jxx SHORT
> label, they can get that result if they wish.
I am of the opinion that the assembler should optimise by default,
but always give the programmer the option to override those
optimisations. Therefore I think the design of such assemblers as
TASM which give you this choice are the best way to go.
> When I get some more time, I will write a test piece for both jump
> sizes to see if there is any speed difference but I would not hold out
> much hope for it.
I think you would be wasting your time there, the efficiency gain
is most likely to be found in greater cache utilisation (L1/L2/L3
though I doubt it would effect the P4's trace cache) not in fewer
clocks. This is very difficult to test with kernel benchmarks,
though it may be posssible with very large pieces of code. Either
way I believe (though I have not tested this hypothesis) that the
difference between the two formats will be minor -- this, however,
I do not see as a valid excuse to not bother performing such a
trivial size optimisation.
C
2003-01-14
Frank Kotler
> Even NASM, whose original authors
> resisted the notion of this optimization, has
> been updated to include this important feature
> (thanks to Frank Kotler).
Thanks to John Coffman, actually. I had almost nothing to do with it -
suggested a couple bug-fixes that didn't work...
And thanks for the rundown on why it's not as easy as it sounds. I
hadn't realized the "down side" of some of the "other" methods. Saved
for future reference!
Best,
Frank
Randall Hyde
"hutch--" <hu...@movsd.com> wrote in message
news:af910ce4.04011...@posting.google.com...
>
> It is rare that I agree with Betov on anything but I agree with his
> view on the compiler style of optimisation of jump lengths. If it does
> anything it may act as a size optimisation but I seriously doubt it is
> a peformance factor in 32 bit code.
But if you take it one step farther and use the branch displacement
sizes to inject "invisible" NOPs into the code, aligning (if possible)
later branch targets to 16-bit (or cache-line) boundaries, then
this *could* noticably improve performance. This, however, is
a much more difficult problem (conceptually) than displacement
optimization *and* it is likely to prove an intractible problem for
many source files (i.e., you need some sort of cut off when you
can't achieve an optimal solution in so many passes).
> I am of the view that assembler mnemonics should remain fully under
> the control of the programmer and if they want to write Jxx SHORT
> label, they can get that result if they wish.
There is no question that if a programmer wants to specify a displacement
size, the assembler should request that length. But if the user *doesn't*
specify it, why not just produce the shortest possible displacement? The
only argument for leaving them long is to make the assembler easier to
write. And that's not a very quality-concious argument given that this is
a very popular feature with assembly programmers today. Even if it
doesn't improve the speed, it's not likely it will *lower* the speed.
In the absense of a negative performance penalty, you may as well
optimize for size, if possible.
>
> When I get some more time, I will write a test piece for both jump
> sizes to see if there is any speed difference but I would not hold out
> much hope for it.
I wouldn't either. As I mentioned earlier, the bigger effect is probably
the alignment of branch targets later in the code. And shrinking the
opcode size is just as likely to disturb that as improve it.
Cheers,
Randy Hyde
hutch--
JMP, I arbitrarily align the label by 4 bytes as it does not effect
the operation and sometimes inproves the times where it matters.
I am much of the view that writing code where possible to set the
backwards jump prediction and keeping labels aligned wherever possible
are more productive where performance actually matters.
Auto optimisations are fine in a compiler and you would expect them
there doing many different things but opening the door in assembler is
probably risky and on the road to a compiler when you get any
alteration of the users code.
While I am a fan of high level capacity in modern assemblers, where
the programmer writes a sequence of mnemonics, I am inclined to leave
them in his control so when he specifies a SHORT jump, he gets one and
if the target is out of range, he gets an error advising what has
happened.
It means the programmer can still perform manual optimisations where
they need it yet use high level style code where they don't.
Beth
> hmmmm,
>
> The google server just dropped its bundle and took my post with it
as
> it failed so I will try again.
>
> It is rare that I agree with Betov on anything but I agree with his
> view on the compiler style of optimisation of jump lengths. If it
does
> anything it may act as a size optimisation but I seriously doubt it
is
> a peformance factor in 32 bit code.
Oh, indeed; Kicking up too much of a fuss about this is really
splitting hairs, to be honest...although, mind you, someone may have
important "size" issues where they really are compelled to split those
hairs...but, true enough, for ordinary and everyday stuff, it's not
particularly the most important topic in the universe or anything...
But, on the other hand, if the assembler can happily do it fairly
quickly without causing a great fuss and it doesn't get in the way of
the programmer and their "control" whatsoever, then why not do it?
Now, if to save those bytes, we were required to drag a heavy anvil to
the peak of Mount Everest or something, then, sure, "no bloody
way!"...leave those extra bytes there, if it's that much trouble to
wipe them out...BUT, of course, what we're talking about is the
assembler doing this work all for you (but NOT when you do explicitly
specify "JMP SHORT"...I don't think any of the assemblers that have
this optimisation don't have the ability to hard-code the size nor do
they ignore your directives, right? Well, I've never seen that happen
anywhere, anyway)...so why on Earth not?
Say you actually _DO_ want this size optimisation because you've got
some "size issue" you have to keep with (fitting code into a disk
sector or two for OS development, going right up to the last byte,
trying to not waste anything...or for an entry into some "size"
competition...although, granted, "taking control" is more usual just
to make absolutely sure things are as tight as possible...but, hey,
you could always let the assembler give its "opinion" first - looking
in the "listing" file - and then apply what it says, making "tweaks"
where you think you can do better ;)...then not having it is a right
royal pain in the backside...note that "a few bytes" can also
sometimes have cache implications (okay, rare enough for another "oh,
come on, isn't this splitting hairs again?" comment, true enough ;)
that "as close together as possible" is a good thing...
Now, _IF_..._IF_ what we were asking prohibited a programmer from
"taking control" by _explicitly_ marking a "JMP" as "SHORT" or "NEAR"
or "FAR" or whatever, then there'd be a good point here...but that's
not a requirement any implementation of this I've seen ever makes...it
_ONLY_ does it when you've left off the "SHORT", "NEAR" or "FAR"
qualifier...when it's written explicitly then the assembler does what
it's told, regardless of whether it may think it can do better or
not...
And, for the person who insists on _every_ "JMP" being under
programmer control, these people will, of course, always be writing
"JMP SHORT" and "JZ NEAR" and such, right? I mean, if they are so
concern about these jump sizes, they're not going to using the
"ambiguous" forms of just "JMP" (which, in a sense, _IS_ a directive
to the assembler that it's a "JMP (don't care what size)"...if you
want "JMP SHORT", you put it there...if you don't care, you just put
"JMP"...and someone highly concern that they "take control" will,
therefore, _never_ be using any "ambiguous" forms in their code at
all...they'll write "NEAR" and "SHORT" every single time, yeah?
Hence, we do have a "best of both worlds" in this case (that was what
my other post was trying to capture :)...for those that care, they can
write things explicitly (and, note, were the assembler _NOT_ able to
do this "optimisation" then it would require _explicit_ size
references, anyway)...for those that don't care or want to see the
assembler's attempts first (remembering that the "listing" file can be
used to determine what the assembler actually did...so, even "going
manual", you can run it through the assembler merely to get the
"machine's perspective" on the matter in a matter of seconds ;) or
really do want this functionality, then it's there for them, just by
using "ambiguous" jump forms that don't explicitly specify any size...
If, as I suggested, we also added command line options to explicitly
say "optimise / don't optimise" (and, as I suggested, you could even
have "assume all jumps are near, give an error if one can't be" or
"give an error if there's any jump without an explicit size" options,
providing even more potentially useful functionality for different
needs and occasions :) then the essential point here is that this
optmisation doesn't "get in the way" so why not do it? For those that
don't want it, it's perfectly possible to make it go away...in fact,
if - as Rene suggests you're already doing in being _explicit_ about
the size with every single "JMP" or "Jxx" instruction - the size is
always explicit on every reference, anyway, than the assembler
respects that and no optimisations would actually occur as we have
_told_ the assembler what to do in every instance...
> I am of the view that assembler mnemonics should remain fully under
> the control of the programmer and if they want to write Jxx SHORT
> label, they can get that result if they wish.
Well, that's where Rene's missing a trick, hutch...with all the
assemblers that _do_ have this optimisation, there's always the
ability to "qualify" any jump with "SHORT", "NEAR" and "FAR" (well,
that's exactly the syntax you're using there, so you obviously know
that the option is there :) and, if you do, the assembler _RESPECTS_
that fully and wouldn't try to "optimise" such an instance...write it
on _ALL_ of your jumps and the assembler will do absolutely no
optimising at all (and, note, if following Rene's method, you will
_ALREADY_ be specifying _explicitly_ what sizes you want each and
every time...that people of this need and disposition need to do
_ABSOLUTELY NOTHING_ different to what they are doing already...and
they won't get any results different to what they'd get were the
optimisation not an ability of the assembler...because, of course,
it's all explicit and the assembler excludes explicitly qualified
jumps...hence, that's _telling_ the assembler, in a round-about way,
that you don't want any optimisation)...mind you, if you feel you _DO_
want this or are happy to leave off "SHORT" and let the assembler work
out whether it's possible and try its best to "shorten" as many jumps
as it can to "tighten" up the code...then just write "JMP" alone and
the assembler takes this "ambiguous" instruction to mean: "I want a
JMP instruction...I don't mind which one, so long as it works...I'll
let you, Mr.Assembler, decide what you think is best"...
These assemblers _ARE_ 100% "doing what they are told"...if, as you
say above, you find this very minor "size" issue to normally be quite
irrelevent then, in fact, you _WANT_ the assembler that does this
optimisation stuff...because then you can "free" yourself from the
trivial concerns of "size" which you don't particularly care
about...just code "JMP" and then the assembler will concern itself
with trying to make the choices as to what's most reasonable (as far
as it can tell)...if you _actually_ used Rene's method, then you would
be _FORCED_ to have to write this _explicitly_ every single time and,
thus, the thing you are not particularly interested in, is _thrust_ -
in the typical Rene "philosophy" way - into your face...you're not
allowed to be "unconcerned", you must be _explicit_ every single
time...
So, in fact, if you side with Rene then you're actually getting the
reverse of what you said above...you said "who cares?" as it doesn't,
indeed, make much of a difference...well, with an assembler that can
_decide for itself_ what is an appropriate "JMP" size, you can code
merely "JMP" and you need not concern yourself about this issue
whatsoever...with Rene, you are _FORCED_ to be concern and count bytes
and so forth (coding them all as "NEAR" (or "FAR" if we're in DOS, not
Windows ;) so that it'll _always_ be able to make the jump is one
possibility, of course...but then, why not simply let the assembler do
it because it doesn't particularly matter and it will handle those
issues for you...in a sense, this is called an "optimisation" but it's
more like a simple "extension" on the assembler to mean that you
_don't_ have to be concerned about these things...the fact that the
assembler tries its best to make it as small as possible is just a
case of doing its job as best as it can..."optimisation" is
misleading, really...it's more a case of "freeing" you, the
programmer, from the "size" considerations...that is, unless you
really, really want to...in which case, go back to how it was before
this stuff existed and manually code "SHORT" and "NEAR" on those jumps
by hand)...
Okay, here's another perspective...for the sake of argument, I'm going
to rename the mnemonics for particular opcodes...the short
unconditional jump opcode is now called "JMPS" and the near one "JMPN"
(similarly, "JZS" / "JZN" and so forth)...because, in the end, they
are different opcodes and the different size really is a significant
semantical difference...it takes different operands and is a different
size when encoded...also, following wolfgang's lead, we're going to
have "LOAD" and "STORE" explicitly rather than "MOV" (the "MOV"
instruction can actually have two different encodings in many
cases...a "LOAD" and a "STORE" version...the assembler normally takes
care of this and simply "defaults" to one encoding or the other
:)...are we beginning to see the point?
An assembler that "takes care of this for us" is simply allowing a
"JMP" form, which may be either "JMPS" or "JMPN" according to how
close the destination is from the source of that jump (and, as for the
"jiggery-pokery" Randy was talking about, that simply comes about
because, of course, the _JMP itself_ effects that distance in some
cases...the "snake biting its own tail", so to speak...Randy covered
the ramifications well in his "essay" :)...in exactly the same way
that you write "MOV" and then let the assembler pick a "LOAD" or
"STORE" encoding...because, in both cases, we're telling the
assembler: "Look, I don't particularly care which one you use...so I
leave it up to you to pick a reasonable / decent choice"...
> When I get some more time, I will write a test piece for both jump
> sizes to see if there is any speed difference but I would not hold
out
> much hope for it.
Actually, while you're at it, try another test too...give these
assemblers that include the "optimisation" source code where _every
single instance_ is _explicitly_ marked "SHORT", "NEAR" or "FAR"...and
see if you can find _one_ assembler that doesn't respect your
wishes...
Note, I actually already know the answer (at least, for all the
assemblers I've ever tried ;), the answer is that you won't find _any_
that don't respect your wishes when you make it explicit...
And, guess why I know the answer? Because, yes, when I code, I use
"JMP SHORT" and "RET NEAR" and "CALL FAR" and...and...I'm actually an
"explicit" programmer just like Rene...I practice the "if I put the
size explicitly in there then I _know_ I'm going to get what I asked
for" attitude throughout my coding...I also type "MOVSD", "PUSHD"
(where supported), "PUSHAD" and so forth, never leaving off the size
on even these instructions where many people do (also, my "OllyDbg"
knows my preferences for this when displaying disassembly ;)...
Hence, I'm actually writing in support of this stuff because I know it
doesn't actually effect an "explicit" coder whatsoever...on the other
hand, when I also have that "oh, who bloody cares?" feeling myself,
then I also know I can type "JMP" and leave it _completely_ up to the
assembler to pick something reasonable on my behalf...and I recognise
that many may, indeed, _prefer_ that way...being a "reverse explicit"
coder, if you will...leaving everything "ambiguous" _unless_ they
really _must_ specify the size (for example, the usual "JMP" after
going into protected mode has to be _forced_ to be "FAR" because it's
purpose is to ensure CS:EIP is fully reloaded in a "protected mode
friendly" way without their being any "real mode remnants" sitting in
CS or whatever...in this case, you've _got to_ make the correct sized
jump or, in fact, they'd be no point making the jump at all ;)...
In fact, this is much the same arguing point as I make for HLA...I'm
NOT actually talking about the merits of "optimisation" or the merits
of Randy's "IF" statement or whatever...as, actually, I'm an
"explicit" coder and never make use of "IF" (I know the arguments for
"IF" and don't disagree, by the way...it's just that I'm used to the
other way that it actually makes little difference which I
choose...so, being, as I say, an "explicit" coder, I settle for just
using the machine instructions so that I can see what instructions are
there...I'm not "against" the use of "IF" from time to time...I just
don't actually find it that much "easier" or "quicker" because I'm
plenty used to "assembly thinking", so to speak...if anything, it
could slow me down as I wade through the "reference manual" to find
out whether it's "OR" or "|" or whether I need to bracket it or not
and that kind of thing because I'm not used to the syntax...in that
time, I could just do it with ASM directly...granted, different
situation for newbies, where being like BASIC or whatever is probably
a really great thing...and, hence, for _them_, not me: "more power to
the IF stuff!" ;)...
Beth :)
Betov
$UY1...@newsfep3-gui.server.ntli.net:
> But, on the other hand, if the assembler can happily do it fairly
> quickly without causing a great fuss and it doesn't get in the way of
> the programmer and their "control" whatsoever, then why not do it?
>
It's a bit sad to see you not understanding a thing
at the way RosAsm Manages this problem, but, well,
just to answer to that paragraph ("Why not"):
Simply because, usually, the Assemblers Authors have
some other works to do than utterly no use things.
Nevertheless, as long as we are, here, strictly in
the propaganda area, yes, i will much probably
implement something like this. Certainaly not for
such a stupidity like saving 20 Bytes in a PE, but
for using one of those so stupid selling arguments
that are considered by beginers not knowing for
what reason choose one of the available Assemblers,
and, evidently, not yet anderstanding what all of
this is about.
Betov.
Beth
> Beth wrote:
> > But, on the other hand, if the assembler can happily do it fairly
> > quickly without causing a great fuss and it doesn't get in the way
of
> > the programmer and their "control" whatsoever, then why not do it?
>
> It's a bit sad to see you not understanding a thing
> at the way RosAsm Manages this problem, but, well,
> just to answer to that paragraph ("Why not"):
>
> Simply because, usually, the Assemblers Authors have
> some other works to do than utterly no use things.
>
> Nevertheless, as long as we are, here, strictly in
> the propaganda area, yes, i will much probably
> implement something like this. Certainaly not for
> such a stupidity like saving 20 Bytes in a PE, but
> for using one of those so stupid selling arguments
> that are considered by beginers not knowing for
> what reason choose one of the available Assemblers,
> and, evidently, not yet anderstanding what all of
> this is about.
And, of course, coming from Rene saying this, that kind of also makes
my point...
This is Rene who will happily ruin his reputation if he can manage to
"save" _one_ newbie from Randy's "evil propoganda"...he's a man who
will take the damage, if it means the principle is
maintained...NOTHING can make him go back on his principles...
Hence, if Rene is going to implement this - even though he doesn't
really want to do so - merely as a "selling point", he's implicitly
confirming what I was saying above that the inclusion does not effect
an "explicit" coder one bit when they put the sizes onto every
instance of the jumps...because if that weren't the case then Rene's
"principles" would not permit him to add it, were it a great "selling
point" or not...
Because Rene's shown that he will NOT go back on a "principle", merely
to "sell" a product...and he is determined in this...that is, of
course, why we don't have library support on RosAsm and _never_ will
do...he said it himself...it doesn't matter how many people tell him
they want library support, there is the "principle" in his mind that
this is "anti-assembly" so it will never be added under any
circumstances...
So, for Rene to be saying in such a "laissez faire" way: "oh,
alright...go on, then...if you really want it, I'll add it just to
please people and help sell it"...then you know, as I was saying, that
because there's always the option to be _explicit_ on every reference
and effectively "turn it off", it makes no great difference to include
it...if there was, Rene has shown that he wouldn't compromise on any
principle that would represent something "anti-assembly" in his
eyes...
I quote, he merely sees this as a "no use thing", not any
"anti-assembly" thing...
Thank you for helping me prove my point in an indirect way,
Rene...most kind and gracious of you...
Beth ;)
Randall Hyde
"Beth" <BethS...@hotmail.NOSPICEDHAM.com> wrote in message news:fn2Ob.429
>
> This is Rene who will happily ruin his reputation if he can manage to
> "save" _one_ newbie from Randy's "evil propoganda"...he's a man who
> will take the damage, if it means the principle is
> maintained...NOTHING can make him go back on his principles...
I don't know about this :-)
Here's a recent post on the RosAsm board:
>>>> Rene "Betov" Tournois:
After this, it seemed to me a good idea to, also, insert such a collection
of available Routines in as a RosASm Pre-Parser.
OK, might be a bit shocking for purists, but here is how the problem comes:
Given the existence of "some" propanga (...) about "High Level
Assembler(s)", this is a good thing to offer such an opportunity to
beginners, for writing HLL _inside_ RosAsm.
The problem we will have when times will have come to "push" and to "sell"
RosAsm into public places (the day ReactOS will enable RosAsm with, at
least, an Auto-Compilation), we will have to face the real facts of
"propaganda", and of "illusions selling". We like it or not, we _must_ do
this, in order to attract beginners.
When a beginner chooses an Assembler, he has no idea of the real important
things inside an Assembler. He chooses this one, or that one, for multiple
weird reasons:
* Because that one is most in use.
* Because my friend told me...
* Because this one does JMPs size optimizations.
* Because this one makes OOP.
* Because that one has Static Libraries.
* and so on, and so on...
So, at end, whatever stupidity that may push a beginner to choose RosAsm, we
will have to try to do our best to implement it. As long as it does not and
will not hurt anything, and, as long as the "serious" work is done,
previously.
Such a Pre-Parser as a Basic one, inside the beast, will not eat that much
room, and it will be a good argument to make beginners think they can, the
sweet and easy way, slowly upgrade from HLL to Asm (terrific illusion,
but,... well...). Then, it will be quite easy to convince them, once they
will be "in", that they can jump into the great bath, when they like to.
We cannot convince them, at all, and in no case, with sentences saying the
simple truth, like: "Give Assembly a try and you will see it is easy". They
will NEVER believe it, as long as everybody, but me, claims the exact
opposite. As long as Basic is certainly one of the very most in use HLL...
One another point is that these Basic Routines will answer to all the usual
critisms about RosAsm not having Libraries (!!!...). And, also, when we
(even me... ) will want to write some "quick and durty" tool, for whatever
side task, theses routines will be perfectely re-usable, and a precious
help, the overall performances of the Apps not being dramatically reduced by
these, nevertheless,... "asm Routines").
What should this Pre-Parser do, exactely?
Simple: Nothing but inserting the Routines (the ones Gugas and YeoH are
actually writing) into the User Source, when the Pre-Parser encounts some
Evocation(s) of these Routines Names. Plus of course, i suppose an automatic
run of your own Equal Pre-Parser (i suppose there will be no conflict, at
all, with runing these two at once... and... its done. The way i see this
should be very simple.
I suppose that the more difficult problems, that will be encounted, will be
with the [Unfold Option] and, much more difficult (but, well, we already
have something like this already done), with the error manager.
Betov.
<<<<<<<<<<<<<<<<<<<
Sounds to me like he's experiencing the futility of constantly swimming
against the tide and refusing to accept that fact that users really want
something different than he's offering. THIS IS A GOOD THING!
Maybe in another five years he'll actually put in support for statically
linked libraries! Never can tell. But obiously even he is beginning to
realize that his "vision" for an assembler isn't quite getting the
acceptance
he expected.
>
> Because Rene's shown that he will NOT go back on a "principle", merely
> to "sell" a product...and he is determined in this...that is, of
> course, why we don't have library support on RosAsm and _never_ will
> do...he said it himself...it doesn't matter how many people tell him
> they want library support, there is the "principle" in his mind that
> this is "anti-assembly" so it will never be added under any
> circumstances...
Amazing. Now all of a sudden he is discussing the nasty "s" word (sell).
This is totally cool. I'm sure they're having a snowball fight in Hell on
this very day!
>
> So, for Rene to be saying in such a "laissez faire" way: "oh,
> alright...go on, then...if you really want it, I'll add it just to
> please people and help sell it"...then you know, as I was saying, that
> because there's always the option to be _explicit_ on every reference
> and effectively "turn it off", it makes no great difference to include
> it...if there was, Rene has shown that he wouldn't compromise on any
> principle that would represent something "anti-assembly" in his
> eyes...
yeah, make it so painful to use that no one will.
You can still say you have it and put it in the feature matrix, but
indirectly you will prevent its use in applications.
Cheers,
Randy Hyde
Betov
6....@newsfep3-gui.server.ntli.net:
> Hence, if Rene is going to implement this - even though he doesn't
> really want to do so - merely as a "selling point", he's implicitly
> confirming what I was saying above that the inclusion does not effect
> an "explicit" coder one bit when they put the sizes onto every
> instance of the jumps...because if that weren't the case then Rene's
> "principles" would not permit him to add it, were it a great "selling
> point" or not...
>
> Because Rene's shown that he will NOT go back on a "principle", merely
> to "sell" a product...and he is determined in this...that is, of
> course, why we don't have library support on RosAsm and _never_ will
> do...he said it himself...it doesn't matter how many people tell him
> they want library support, there is the "principle" in his mind that
> this is "anti-assembly" so it will never be added under any
> circumstances...
>
How stupid!...
I am used to implement everything users want, as long
as it does not hurt anything, and as long as it remains
compatible with my own view of the whole RosAsm Project
and with my idea of what Assembly is. Period.
Another side of the problem is that i have only two
hands and that the RosAsm Developers group is around
4 or 5 volunteers facing a mountain of work. So i also
tend to delay no or few use implementations.
Betov.
< http://betov.free.fr/RosAsm.html >
Beth
Rene!!! You _traitor_!!
I may not have agreed with you but I totally respected your
"principled stand" on this...and then we see you not only give up but
actually _completely go back_ against your earlier principles...
Including "anti-assembly" in RosAsm and then - _KNOWINGLY_ and
_DELIBRATELY_ - sell "terrible illusions" to them? Use "propoganda"
knowing full well that you are _deceiving_ people?
You're not the only one who's _furious_, Rene...after all you've said
about "principles", you're going to go completely against all of them
and do so _knowingly_ selling people "Lies! Swindles! Propoganda!"?
Also, you say it there but no mention of this "I'm selling out
completely" policy on this group...pretending that you haven't sold
your soul in our company...are you also cowardly to boot in knowing
that I would be _appalled_ to hear you _sell your soul_ like this?
What Faustian pact have you signed, Rene? "Glory"? "Fame"? A promise
to be "King" of the "rebirth"?
You are a traitor and a liar to your supposed "cause"...I was
_entirely right_; YOU _HAVE_ BECOME THE VERY ENEMY YOU CLAIM TO BE
FIGHTING AGAINST! Promoting "anti-assembly", selling out to "populism"
alone, _knowingly_ spreading "lies, swindles and propoganda",
implementing a "fascist police state", selling out your principles
merely to advance your "personal glory"...
I'm really and genuinely sad and sorry to see this...you had something
to begin with and you've _sold out_ completely on that...it's going to
be incredibly difficult to respect you after writing such a thing...
Now, if you'd said "I know believe that Randy's method is correct and
wish to do it" then that could be respected...but: "make beginners
think they can, the sweet and easy way, slowly upgrade from HLL to Asm
(terrific illusion, but,... well...)."? Knowing dishonest deception? A
"swindle" of "propoganda" and I can't hear any guilt or regret in the
tone you took writing that either...how are we to respect your
"principled stand" after this, Rene?
> Sounds to me like he's experiencing the futility of constantly
swimming
> against the tide and refusing to accept that fact that users really
want
> something different than he's offering. THIS IS A GOOD THING!
No, not really...because, look closely, he's not said "I realise that
Randy may have some good points in his methods", he's said: "I still
don't believe in these things at all but will _deceive_ people that I
do, simply to be popular and get personal glory for doing
it"...realisation would, indeed, be a "Good Thing" but that doesn't
appear to be what we've got at all...he still firmly _disbelieves_ but
will spread "propoganda" and "swindles" that he really does and wants
to support this properly when he doesn't at all...and he will _sell
out_ on his principles completely to do so...merely to be "popular"...
That's a very BAD THING...he's, note, not really going to support
static libraries but trying to create a, I quote, "terrible illusion"
that he does...so, not only is he selling out but when the beginner
comes to RosAsm on "propoganda" that RosAsm has these things, that
beginner will be _deceived_, as it _won't_...they will NOT be getting
libraries at all, they will be getting _illusions_, phantoms and
smoke...
He's realised that he's swimming against the tide but is changing
direction merely to be "popular" and "follow the crowd", not because
he's realised that he should do so or that he believes in any way that
he should do so...even if we take the highly condemning "terrible
illusion" comment with a pinch of salt, he _still_ doesn't believe or
realise, so we'll hardly get a _good implementation_ from that...a
"disbeliever" trying to code something he does not believe in or even
really understand _why_ others would want these things? It's
pre-written: It'll _suck_...it'll be no good because good library
support is _hard_ to do well when you're 100% committed to the idea
(as I'm sure you'll confirm, Randy...designing, testing and putting
your library was NOT just rolled off in a "lazy" fashion, dismissing
it because "oh, it's just beginner propoganda crap!"...imagine how it
would be, though, if you'd taken Rene's contemptuous attitude towards
what you were doing as you designed and coded the libary)...
I'm severely disappointed by this...this is actually far worse than
him simply sticking by his misguided principles...what's worse than
not getting any assistance in a store? Getting a store assistant who
treats you like crap and _delibrately_ lies to you with complete lies,
sending you to all the wrong places and filling you with total
_misinformation_ that you're in a _worse_ position than you were
coming in...that, in fact, you would have been better with no
"assistance", trying to fathom it out for yourself...
"With friends like these, who needs enemies?"
> Maybe in another five years he'll actually put in support for
statically
> linked libraries! Never can tell. But obiously even he is beginning
to
> realize that his "vision" for an assembler isn't quite getting the
> acceptance he expected.
But wasn't the whole point that he was taking a "principled"
_innovative_ step towards his "vision" of a better tomorrow? Didn't
"acceptance" not matter because he believed it was _right_ and that,
in time, as he forged forward, the _facts_ (as he believed them) would
prove themselves?
This reminds me of Tony Blair the other day...he'd earlier called Ken
Livingstone - also called "red Ken" because he's a true red socialist
of the old Labour tradition - a "disaster" when Ken opposed Labour's
"official" candidate for Mayor of London...a move which got Ken
_thrown out_ of the party...
But Ken won the election and become Mayor of London...and he brought
in his "disasters" of Congestion Charging and stuff, which, of course,
did rather well and people actually _LIKED_ (well, they voted for Ken
knowing full well that this was among his central policies, which he
said straight out to everyone)...and now there's another London Mayor
election on its way, what is Tony saying and doing? Letting Ken back
into the Labour party and "admitting" that his earlier prediction of
him being a "disaster" was a mistake...
Now, being able to admit a "mistake" would normally be a fantastic
thing to see in a politician and especially Tony Blair - who's been
chargrilled by the Hutton Inquiry but still tries to wriggle out with
"look at this in the totality" excuses (what? Is he suggesting that if
he _lied_ 27 times but told the truth 28 times then it "cancels out"
that he got people _KILLED_ on his _lies_? Sorry, that's something I
will NOT buy, Tony...like Rene, if you're going to be "principled",
then you _GO DOWN WITH THE SHIP_...you stand by what you said and
did...and, if necessary, admit that you did make a mistake and would
like to try to make amends for that, if you can) - but he's only
saying this for _one_ reason...with Ken in the party as their
"official" Labour candidate, they'll win hands down (as Ken cleaned up
those votes last time too)...if they don't? Well, the other "official"
Labour candidate was rated as being _4th_...and considering Labour are
the ruling party, to not even be 2nd or 3rd but _4th_ is unbelievably
condemning...a major kick in the face there to say "fudge off" and
Tony knows it...
So, he's only "admitting the mistake" to get Ken back into the party
so that Labour have the London Mayor position under their
control...it's NOT honest, it's NOT genuine...it's power-mongering,
plain and simple...like Rene saying "I have libraries, beginners!
Please come and use my libraries! I Love libraries! You Love
libraries! We will do good work with libraries!" and _NOT meaning a
single word_ of it...straight "lies, swindles and propoganda" just to
get people to "vote RosAsm" and nothing more..._knowingly deceiving_
newbies just so that his "rating" doesn't look so bad in comparison to
yours, Randy...
"You lied! You faked!
You cheated! You changed the stakes!
Magnet toss that pie in the sky
Unrehearsed, let the bubbles burst
All in all, a three-ring circus...
Of unity with parody
Tragedy or comedy
Probably publicity
Open up, make room for me
Now open up, make room for me
Lose myself inside your schemes
Go for the money, honey...
NOT the screen!
Be a movie star, blah-blah-blah...
Go the _whole hog_
Be bigger than God!"
[ "Open Up", Leftfield featuring John Lydon (A.K.A. Johnny Rotten of
the Sex Pistols) ]
> > Because Rene's shown that he will NOT go back on a "principle",
merely
> > to "sell" a product...and he is determined in this...that is, of
> > course, why we don't have library support on RosAsm and _never_
will
> > do...he said it himself...it doesn't matter how many people tell
him
> > they want library support, there is the "principle" in his mind
that
> > this is "anti-assembly" so it will never be added under any
> > circumstances...
>
> Amazing. Now all of a sudden he is discussing the nasty "s" word
(sell).
> This is totally cool. I'm sure they're having a snowball fight in
Hell on
> this very day!
Indeed...and I'm deeply saddened by this...I mean, I disagreed with
Rene but I was sincerely fighting his corner there with _RESPECT_ that
he took a "principled stand" on this issue (even if misguided...but
"misguided" is curable with education..."I will sell my soul for
popularity" and _knowing deception_? I fear that someone who could so
thoroughly _sell out_ like that, is probably incurable, no matter what
anyone said)...
He's disappointed me and also made a fool of me trying to defend his
principles, when it turns out that he's _traitored_, he's _sold out_
and he was _deceiving_ me completely in pretending he was still _true
to those principles_ when he's given them up...
Put it this way, Rene...if any beginner feels as cheated and deceived
and let down as I do by this, then they will leave RosAsm - no matter
how clever your "terrible illusion" - like rats abandoning a sinking
ship...all along, you were promoting an "illusion", a terrible lie
simply to make you popular...that's really hard to excuse, Rene, when
you've made such a point of this for so long and made me _truly_
believe you when you said these things...and it turns out you never
really did believe them...just "propoganda"..."swindles"...no wonder
you used those words so often, it was probably a "distraction tactic"
to try to make sure we didn't realise that it was _you_ who was
spreading propoganda and swindles...
> > So, for Rene to be saying in such a "laissez faire" way: "oh,
> > alright...go on, then...if you really want it, I'll add it just to
> > please people and help sell it"...then you know, as I was saying,
that
> > because there's always the option to be _explicit_ on every
reference
> > and effectively "turn it off", it makes no great difference to
include
> > it...if there was, Rene has shown that he wouldn't compromise on
any
> > principle that would represent something "anti-assembly" in his
> > eyes...
No, on second thoughts, of course...it doesn't mean that at all...what
it means is that Rene sold out and made me look a fool in defending
him...and because of respect for that "principle", I never did launch
a real assault on what he was saying that I really could have done to
blow it out of the water in a really, really bitchy way...care to tell
me why, after being deceived and let down by you, Rene, that I
shouldn't do exactly that?
Nah, of course..."vengence is unto the Lord"...you're let off because,
you see, some people _DO_ stick by principles and really _mean_ things
when they say them...and one principle that's good enough for the Lord
Himself is that if you _genuinely_ and _honestly_ want and ask for
forgiveness and want to make amends for your mistakes then it's _total
given_, _no questions asked_...so long as, indeed, you _mean_ it and
it's not just more "terrible illusions"...a form of "poetic
justice"...you will be done or undone by _your own actions_ (and for
anyone that doubts this, I just point to what Rene - and Annie to an
extent - have done to their own "causes" in the way they carry on
about them...indeed, "karma" is hard to initially believe until you
notice that it really _does_ happen ;)...
> yeah, make it so painful to use that no one will.
Yeah, like I said...an implementation by a "true believer" is hard
enough to do well because of all the concerns you have to juggle
simultaneously...but an implementation by someone who doesn't want to
be doing it at all? Don't bother, Rene...beginners _won't_ be
interested in an implementation that _sucks_...that, after all, is the
reason _why_ you're currently having problems already that you're
contemplating this "terrible illusion" to deceive them...have you not
ever carried through on fine-tuning the assembler and such because you
never really did believe in them that much?
> You can still say you have it and put it in the feature matrix, but
> indirectly you will prevent its use in applications.
Yes...but what's the point in that? Merely to "sell units"? I thought
this was about getting rid of Microsoft, not copying and idolising
their methods with as equal contempt as they carry that was always
reason numero uno why I _never_ liked that company...now I have to ask
quite, quite seriously, Rene, what is the big difference between you
and your sworn "enemies"? I can _no longer_ see any difference at all
in the methods whatsoever...hacking out crap...never fine-tuning
anything...trying to _deceive_ "clueless beginners" into thinking your
stuff is "some big thing" when even you _know_ it isn't...forcing
everyone to do things as the _fascist_ "ThoughtPolice" demand that you
do...
You have become your own enemy...any reason why I shouldn't work
against you as I happily would do with Microsoft? Make it good as I'm
already "defaulting" to just thinking "not" about this...
Beth :)
Betov
$EI4...@newsfep3-gui.server.ntli.net:
:)) :)) :))
I am afraid you prefectely understood the thing, Beth.
Yes RosAsm will (very easily) beat HLA in its own land.
:)) :)) :))
Now, you can faint to ignore that the "Pre-Parser"
concept has been introduced in RosAsm since its
first life years.
Yes, RosAsm already includes some HLL Pre-Parser,
with the interresting:
PREPARSE Equal
Yes, RosAsm will sooner or later include also a:
PREPARSE Basic
or anything alse like this anyone would like to
implement. This is planed since years. There will
also be a:
PREPARSE AAO
... and so on.
The great advantage, with these Pre-Parsers is that
they are clearly designed as.... _HLL_ or _HLL-Like_.
This makes all the difference with a swindling bad
trick of introducing an HLL as being Assembly. When
a RosAsm user actually says:
PREPARSE Equal
, he perfectely _knows_ that this is _not_ Assembly,
but HLL-Like Assembly. When a RosAsm user will say:
PREPARSE Basic
, he will perfectely know that he is going to write
Basic, and not at all Assembly.
... and the better thing with all of this is that
these implementations do not change a thing at
RosAsm being and remaining a true assembler per se.
Turning crazy when understanding that RosAsm can
beat HLA hands down on all points? Nice. Thanks.
Betov.
< http://betov.free.fr/RosAsm.html >
hutch--
========================================================
> When a beginner chooses an Assembler, he has no idea of the real important
> things inside an Assembler. He chooses this one, or that one, for multiple
> weird reasons:
>
> * Because that one is most in use.
>
> * Because my friend told me...
>
> * Because this one does JMPs size optimizations.
>
> * Because this one makes OOP.
>
> * Because that one has Static Libraries.
========================================================
This is unadulterated clap trap. Most beginners to assembler
programming would not have a clue about these aspects of the language
and what they actually go for is a language they have some chance in
succeeding with.
The language forms that HAVE succeeded are those that a learner has a
reasonable chance of learning and getting results out of in a
reasonable time frame. Along the line they learn that a powerful macro
system and libraries are part and parcel of a language that can be
written successfully within that time frame.
The real distinction here is between Betov's imagination driven
"rebirth" of assembler and the MASM driven "resurrection" of
assembler. The first is a fantasy while the second is a fact. The
large numbner of people who are coming into assembler programming are
doing it with MASM initially and the marginal flow on to a toy like
Betov's assembler is a byproduct of the massive support and popularity
that MASM has.
Now it seems reasonable to advise Betov to download Randy Hyde's HLA
so he can actually learn some decent software engineering concepts and
architecture and then when he is proficient enough, he can make it to
the big time and try and use an assembler as powerful as MASM.
Think how much better BetovAsm would be if it was written in HLA where
he could learn to use fast hash tables, dynamic trees and a whole pile
of other normal programming style structures that are a part of modern
programming. Then the style of micro-optimisation for real speed would
start to make sense when you use a real assembler.
Regards,
hutch at movsds dot com
Betov
news:af910ce4.04011...@posting.google.com:
> Think how much better BetovAsm would be if it was written in HLA where
> he could learn to use fast hash tables, dynamic trees and a whole pile
> of other normal programming style structures that are a part of modern
> programming. Then the style of micro-optimisation for real speed would
> start to make sense when you use a real assembler.
>
My dear friend, having two nobodies supporting each others,
in order to try to enhance each other reputation might work
fine in some case. Courage. Though in the case of a Power
Basic Programmer and of a HLL/VHLL programmer, finally,
expecting nothing but to get the first Position on the other
one, as soon as possible, i am afraid this will be a bit
complicated...
;)
Betov.
< http://betov.free.fr/RosAsm.html >
Beth
> :)) :)) :))
>
> I am afraid you prefectely understood the thing, Beth.
Oh, geez Louise, he's trying to be an amateur psychologist now...
> Yes RosAsm will (very easily) beat HLA in its own land.
All due respect and all that...but, well, don't make me laugh...you
really have no idea at all if you think you come anywhere near...
> :)) :)) :))
>
> Now, you can faint to ignore that the "Pre-Parser"
> concept has been introduced in RosAsm since its
> first life years.
No, no...I perfectly saw that you'd realised a "lacking" and "absence"
in your tool so now you're hard-coding BASIC and standard arithmetical
stuff into it...
Really, Rene...if you're going to declare "Holy War" then remember the
first rule of military strategy: _KNOW YOUR ENEMY_...if you think this
kind of thing comes anywhere near being "competition" then you
seriously need to study up on HLA to find out just how "backward" your
tool really is in comparison...it's only been politeness that's kept
everyone from simply telling you just how much it sucks...but, in the
end, it's kinder to let you know so that you can realise and work to
_really_ fixing these things, rather than let you stew in your
ignorance, thinking that there's any comparison at all...
> Yes, RosAsm already includes some HLL Pre-Parser,
> with the interresting:
>
> PREPARSE Equal
>
> Yes, RosAsm will sooner or later include also a:
>
> PREPARSE Basic
>
> or anything alse like this anyone would like to
> implement. This is planed since years. There will
> also be a:
>
> PREPARSE AAO
>
> ... and so on.
>
> The great advantage, with these Pre-Parsers is that
> they are clearly designed as.... _HLL_ or _HLL-Like_.
>
> This makes all the difference with a swindling bad
> trick of introducing an HLL as being Assembly. When
> a RosAsm user actually says:
>
> PREPARSE Equal
>
> , he perfectely _knows_ that this is _not_ Assembly,
> but HLL-Like Assembly. When a RosAsm user will say:
>
> PREPARSE Basic
>
> , he will perfectely know that he is going to write
> Basic, and not at all Assembly.
And when a HLA user puts '#include("stdlib.hhf")', she perfectly knows
that she's including the standard library functions...but, on the
other hand, if she puts '#include("Win32.hhf")' then she knows that
she's including the Win32 API...if she puts '#include("OpenGL.hhf")'
then she perfectly knows she's including the OpenGL interface....if
she puts '#include("DirectX.hhf")' then she perfectly knows she's
including DirectX...if she puts '#include("MyMacros.hhf")' then she
perfectly knows that she's getting her macros...if she puts
'#include("AdventureDSEL.hhf")' then she perfectly knows that she's
going to get a complete adventure game DSEL extension onto HLA...
And this can be extended _without_ needing to in any way alter the
source code whatsoever...a user can write these files themselves
directly with HLA code...and they can create their own libraries or
interface with third-party libraries at the drop of a hat...
> ... and the better thing with all of this is that
> these implementations do not change a thing at
> RosAsm being and remaining a true assembler per se.
You know, HLA doesn't even have to be _altered at all_ to get exactly
the same functionality...so you know for a fact that it won't change
what HLA is at all...
You're NOT "forging ahead" here, Rene...you're _still_ just "playing
catch-up"...and, worse, you're doing it with a severe "poor man's
version" which simply isn't as good or as versatile and flexible...
> Turning crazy when understanding that RosAsm can
> beat HLA hands down on all points? Nice. Thanks.
Really, Rene...if you want to know just how much of a ignorant
wannabee this makes you sound, then you really should remember that
first rule of military strategy: KNOW YOUR ENEMY...go - just once -
look at HLA and what it can do and get to _really_ know how it
works...and then piss your pants with raw fear...
You "win" on but one single point: You have a GUI interface...that is
your _sole_ advantage, Rene...and that _is_ easily rectified at any
point at all...Randy's just got the sense to _make it work and work
well_ before he messes around with buttons and widgets...
He's a monster of programming and productivity in comparison to you,
Rene...and - being immodest for a second - he attracts programmers
that actually know what they are doing and talking about (so when such
people assist Randy, you have no chance of catching up
anymore)...whereas, you can only attract people who don't quite know
exactly what's going on or, otherwise, they'd be nowhere near your
bug-ridden "it's a GUI...isn't that pretty?" thing that just really
doesn't work too well at all, does it?
I mean, you don't have to speak it out loud, Rene, just think to
yourself...you _know_ just how much you couldn't work out how to
implement and just how much you've avoided getting "exactly right" and
how distinctly unprofessional you are in comparison to Randy...ponder
that over before you, eventually, wake up from your little
DreamWorld(tm)...
Beth :)
Betov
@newsfep3-gui.server.ntli.net:
> Betov wrote:
>> :)) :)) :))
>>
>> I am afraid you prefectely understood the thing, Beth.
>
> Oh, geez Louise, he's trying to be an amateur psychologist now...
>
>> Yes RosAsm will (very easily) beat HLA in its own land.
>
> All due respect and all that...but, well, don't make me laugh...you
> really have no idea at all if you think you come anywhere near...
Beth, when you will wish to consider facts, i will
consider discussing them.
For now, I am not that much interrested with no base
claims saying that Master Pdf is "professional", that
RosAsm "doesn't come anywhere near", and other such
stupidities, coming from a so called Assembly Programmer
like you, unable to define what an Assembler is, and
unable to answer anything but : "You are insulting me!"
to a question question like: "Where are your Assembly
real life Applications available?".
Betov.
< http://betov.free.fr/RosAsm.html >
