Re: HLA v1.68 is now available
From: Percival (dragontamer5788_at_yahoo.com)
Date: 07/29/04
- Previous message: NoDot: "Re: Sol OS"
- In reply to: Betov: "Re: HLA v1.68 is now available"
- Next in thread: Kain: "Re: HLA v1.68 is now available"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 28 Jul 2004 20:06:19 -0400
Betov wrote:
> 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!... :))
I will agree, size isn't of interest. HOWEVER, what is of interest is
when we encode everything as short, then every compile we change each
failed one to long. That extra time spent because the compiler didn't
know what to do when the jump was too short, that could be saved by just
having the assembler do what you would have done anyway.
Anyway, maybe a bootsector writer will like it :)
>>>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.
I really don't see what kind of error you can get from changing
something from a short jump to a long jump. What is gained from knowing
that a jump is too short?
>>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.
You don't understand what i said. I said if you work to make each jump
bigger when it doesn't work, why not let the assembler do it? And if you
say error one more time, i ask that you actually post a specific error
instead of beating around the bush.
> 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.
Do it then :)
> 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.
Maybe you can point out where HLA isn't an assembler, then i can believe
you.
But then again, you will go on the endless rant to say "There wasn't any
need to define an assembler" and so forth. So if you aren't going to say
about HLA itself, nothing about Randall or hutch or the GPL. don't even
bother posting.
And just for you knowledge, brute force is when you traverse all the
possible solutions and check which one is the smallest and works. It
seems pritty slow to me...
Percival
- Previous message: NoDot: "Re: Sol OS"
- In reply to: Betov: "Re: HLA v1.68 is now available"
- Next in thread: Kain: "Re: HLA v1.68 is now available"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
