Re: HLA v1.68 is now available
From: Betov (betov_at_free.fr)
Date: 07/28/04
- Next message: Beth: "Re: f0dder's fabulous folly."
- Previous message: Percival: "Re: HLA v1.68 is now available"
- In reply to: Percival: "Re: HLA v1.68 is now available"
- Next in thread: Percival: "Re: HLA v1.68 is now available"
- Reply: Percival: "Re: HLA v1.68 is now available"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 28 Jul 2004 21:23:31 GMT
Percival <dragontamer5788@yahoo.com> écrivait news:2mqdk9Fpo8ajU1@uni-
berlin.de:
> [...]
>>>>
>>>>> "Betov" <betov@free.fr> wrote in message
>>>>> news:XnF9533C014940ACbetovfreefr@212.27.42.65...
>>>>>
>>>> 1) The code Jumps sizes optimization, done automatically
>>>> by the Assembler, is of no interrest.
>>>
>>> It can save alot of bytes in the long run.
>>
>>
>> No Perversival. It cannot.
> Erm... Long jumps are 3 bytes longer than short jumps. So not using a
> space efficient jump doesn't save bytes. I gotcha.
>
>> Only for an idot like me, who _assumed:
>> @Label to be automatically short. But if I had bother to read about
>> lables I would have known that jmp L0> is a forward short jump, and jne
>> L0< is a backward short jump.
>
> ?? So you agree with me that it is a good idea to use short jumps when
> necessary, and long jumps in as few cases as possible?
> Thats what i mean as It can save alot of bytes in the long run. I was
> refuting Betov.
It's always a bit surprising to me when seing trolls
who do not understand something, discussing no end
about this something... Well...
* In normal use of RosAsm, most of the Jumps that
can be short _are_ short, because the programmer
knows how and when to use short and long forms.
* In some cases, this is _possible_ that some jumps
that _could_ be short, be encoded in the long form.
Particualry when using the standard HLL Constructs
Macros. In these cases either 3 or 4 Bytes _could_
be saved.
* The sizes of the Jumps has no effect on the speed
of Code.
* Given the structure of a PE File, there are few
chances that the Bytes, save by an automatic ajustement
of the Assembler could have some effect on the PE File
size.
* Even in case the 0200h Limit of a dead File section
would be concern by the saved bytes, nobody cares of
the size of an Asm written PE. This does not make
any sense on Giga Disks.
So, all in all, the interrest of having the Jumps
Sizes optimized automatically by Assembler is close
to zero, when not absolute zero.
Nevertheless, given the number of guys who do not
understand a word at this problem, and who think
that, an Assembler doing this is better than an
Assembler not doing this, i _will_ implement this
toy, in RosAsm. This will not be anything of any
interrest, at any technical point of view, but,
simply, a _selling_ argument, following my approach
of the "terrible illusions" (... Hi Beth!... :))
>> And so, I would have maybe have chosen the short labels, and only used
>> long lables when RosAsm told me it was time to. And NOTHING would be
>> better than that. WolfGang uses this technic, and his code is world
>> class. It doesnt get better than handmade short jumps. And depite the
>> things that Randall spew, this is not like he says : ~Its a tremendous
>> pain to do it~. The guys is so dishonest !!! Its no pain at all ! It is
>> something you do a few times, and after that, you do it allmost
>> automatically, and its never a problem! And RosAsm, tells you when your
>> jumps just went out of scope. In that case jmp L0> becomes jmp L0>> and
>> "problem" solved. How difficult is that ?
>
> Anyway, if your technique was that simple. then why can't the compiler
> do that for you? Save yourself 5 minutes.
Because, actually, the RosAsm uses this point
to make it a very usefull and highly wishable
error case pointing. And because, at the time
i wrote the Assembler, i saw no reason for
implementing this toy after the encoder.
> Not that it is a pain, it has and can be done automatically, using that
> technique.
> Now i could also say changing a c header file full of defines into
> assembler is an easy job. But it was easier for me to actually use a
> perl script to change it for me. Similarly, it is easier to let the
> compiler/assembler do jump optimizations for you.
>
> In the case of
> jmp L0>
> The assembler automatically changes it to jmp L0>>.
> You don't even have to push the keyboard. Heck, we are talking about one
> jump here, what about when you have 200 jumps in a source file, and 50
> of them are too short? Your instant fix is not so instant anymore.
You really do not understand a word. If it was
working that way, some errors would introduce
no end bug hunt, that are, actually, saved by
this feature.
Right
> click all you want, but you still have to spend the time doing it.
> Remove it from your life forever.
>
> Now also, Randall didn't say that it was a pain to do this. He said it
> was a pain implementing it into an assembler. Unless you are talking
> about another post i didn't read.
Randall knows exactely _nothing_ about programming
in Assembly. His competency level is equal to zero.
This is quite trivial to implement this in an Assembler.
For RosAsm, it will be, at most 3 pages of simple
Routines, and it will _not_ require Multi-Passes.
Re-read C Post above here: Though i have no idea
of what he calls "Brute Force", here, given the
fact that there are not 250 ways for solving this
problem the inteligent and elegant manner, i suppose
he is talking of something very similar to what
i am thinking about. And, in case you persist in
your stupid consideration of Master Pdf as some
"expert of Assembly", i have to say that i _have_
written an Assembler, and that C _is_ writting an
Assembler. Something that Master Pdf is utterly
unable to do. You will also possibly notice, if
you are not competely blind, that C also does, like
myself, not explain how to do this, exactely. You
know what? I am in the opinion that C is also
coming to idea that enough swindling is enough
swindling and that enough vileny is enough vileny.
Betov.
< http://betov.free.fr/RosAsm.html >
- Next message: Beth: "Re: f0dder's fabulous folly."
- Previous message: Percival: "Re: HLA v1.68 is now available"
- In reply to: Percival: "Re: HLA v1.68 is now available"
- Next in thread: Percival: "Re: HLA v1.68 is now available"
- Reply: Percival: "Re: HLA v1.68 is now available"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|