Re: Rid of Multi-Pass
- From: Frank Kotler <fbkotler@xxxxxxxxxxx>
- Date: Sat, 18 Nov 2006 20:56:11 -0500
T.M. Sommers wrote:
Herbert Kleebauer wrote:
Frank Kotler wrote:>
so Nasm picks a "default" if you don't
specify. Defaults for branches seem reasonable to me ("near" for an
unconditional "jmp", and "short" for conditional jumps).
It should not default in any way, it should convert the user
given instruction to machine code. And if there is no machine
code for a user given instruction (like jmp), then it should
give an error message and not select a machine code himself.
If the user uses an unadorned 'jmp', he is telling the assembler to pick the right size. The huge advantage to this is that when the source is modified, the user doesn't have to revisit every single jmp in the program to make sure it still works. Maybe in toy programs that never get modified such a procedure would be acceptable, but it is not acceptable for a real-world program.
Right. The "old Nasm" did not select the "optimal" size of instruction, but defaulted as above, and the default is still the same. Use of the "-O" switch enables the "automatic" behavior.
If you go into shop to buy two bottles of beer an you instead
get only one big bottle with the same content as the two ordered
bottles, would you accept this?
Not analogous. If you specified a near jump and got a short jump, you would have reason to complain (assuming you did not tell the assembler it was okay to make such changes), but if you don't specify, why should you complain?
Agreed. Nasm comes up less-than-ideal in this department. Nasm feels free to disregard your specifiers - if you've used the "-O" switch - unless you also use the "strict" qualifier. I don't know why it should have to be that way, but that's the way it's currently implemented. Generally, you'd want "either, or", so it isn't often a nuisance.
This all assumes that the user wants the shortest valid form. This is *almost* always the case, but programmers want to do some weird things, and the tool shouldn't stop 'em.
Best,
Frank
.
- References:
- Rid of Multi-Pass
- From: Betov
- ///Re: Rid of Multi-Pass
- From: rhyde
- Re: ///Re: Rid of Multi-Pass
- From: vid512@xxxxxxxxx
- Re: Re: Rid of Multi-Pass
- From: Betov
- Re: Rid of Multi-Pass
- From: ¬a\\/b
- Re: Rid of Multi-Pass
- From: Betov
- Re: Rid of Multi-Pass
- From: ¬a\\/b
- Re: Rid of Multi-Pass
- From: Frank Kotler
- Re: Rid of Multi-Pass
- From: Herbert Kleebauer
- Re: Rid of Multi-Pass
- From: Frank Kotler
- Re: Rid of Multi-Pass
- From: Herbert Kleebauer
- Re: Rid of Multi-Pass
- From: T.M. Sommers
- Rid of Multi-Pass
- Prev by Date: Re: Rid of Multi-Pass
- Next by Date: Re: shift left in masm
- Previous by thread: Re: Rid of Multi-Pass
- Next by thread: Re: Rid of Multi-Pass
- Index(es):
Relevant Pages
|