Charles Crayne wrote:
> On Sun, 28 Sep 2008 09:31:29 -0400
> Frank Kotler <fbkotler@...> wrote:
>
>> > 1. The default state does not optimize as previous versions.
>> > This breaks many programs with errors saying jumps are out
>> > of range.
>>
>> Yes. This appears to be broken. I haven't looked into why...
>
> In prior releases, jumps with backward references were optimized even
> when optimization was turned off. Currently, such jumps are only
> optimized when optimization is turned on. Therefore, in the default
> case, the code is larger than it was before, and some short jumps can
> be pushed out of range.
>
> The desired behavior depends upon the reason for not using optimization.
>
> In the majority of cases, optimization is disabled simply because that
> is the default, and the user either doesn't know how to turn it on, or
> doesn't see any reason to do so. For this user class, I recommend that
> we change the default.
>
> If the user wants optimization off in order to have more control over
> the jump sizes, then the new behavior is the desired one.
>
> If the user wants optimization off in order to speed up the assembly
> process, then the old behavior is the desired one.
>
> Because optimization is now decoupled from forward reference resolution
> we have the ability to offer our users as many different optimization
> choices as we care to support. I just need to know what the consensus
> is.
Okay... here's an offending bit of code (Jeff's "copy.asm"")...
...
; jmp short pup_ok
jmp pup_ok
*** "short" commented out for the 2.04 assembly***
pup_ck1:
cmp word [eax],'-c' ;-compare?
jne pup_ck2
mov [content_flag],byte 1 ;enable x server window list
jmp short pup_loop
pup_ck2:
cmp word [eax],'-t' ;-t time/date?
jne pup_ck3
mov [time_flag],byte 1
jmp short pup_loop
pup_ck3:
cmp word [eax],'-s' ;-s size?
jne pup_ck4
mov [size_flag],byte 1
jmp short pup_loop
pup_ck4:
cmp word [eax],'-h' ;-h help?
jne pup_ck5
jmp short parse_error
pup_ck5:
cmp word [eax],'-d' ;-d delete?
jne pup_ck6
mov [delete_flag],byte 1
jmp short pup_loop
pup_ck6:
;save from path
push esi
mov esi,eax
mov edi,from_path
call str_move
pop esi
;save to path
lodsd
or eax,eax
jz parse_error ;jmp if no destination file
mov esi,eax
mov edi,to_path
call str_move
pup_ok:
clc
jmp short parse_exit
From "objdump -d copy.o"...
2.04rc1:
5f0: eb 68 jmp 65a <pup_ok>
000005f2 <pup_ck1>:
5f2: 66 81 38 2d 63 cmpw $0x632d,(%eax)
5f7: 75 09 jne 602 <pup_ck2>
5f9: c6 05 d9 01 00 00 01 movb $0x1,0x1d9
600: eb e1 jmp 5e3 <pup_loop>
00000602 <pup_ck2>:
602: 66 81 38 2d 74 cmpw $0x742d,(%eax)
607: 75 09 jne 612 <pup_ck3>
609: c6 05 da 01 00 00 01 movb $0x1,0x1da
610: eb d1 jmp 5e3 <pup_loop>
...
and 2.04:
718: e9 80 00 00 00 jmp 79d <pup_ok>
0000071d <pup_ck1>:
71d: 66 81 38 2d 63 cmpw $0x632d,(%eax)
722: 0f 85 09 00 00 00 jne 731 <pup_ck2>
728: c6 05 d9 01 00 00 01 movb $0x1,0x1d9
72f: eb d2 jmp 703 <pup_loop>
00000731 <pup_ck2>:
731: 66 81 38 2d 74 cmpw $0x742d,(%eax)
736: 0f 85 09 00 00 00 jne 745 <pup_ck3>
73c: c6 05 da 01 00 00 01 movb $0x1,0x1da
743: eb be jmp 703 <pup_loop>
Looks to me as though the problem is not with "not optimizing backwards
jumps", but with defaulting to "near" on jcc's.
It was "intended" that with no optimization, Nasm should behave "just
like 0.98". Actually, John originally intended the default to be "-O2",
IIRC. This optimizing of backward jumps deviated from that, but no one
complained because it didn't break anything (whereas optimizing "add
edx, 7" did!). It never occurred to me that fixing it so it *didn't*
optimize would break code if we fixed it.
I was a little surprised that this cropped up as *often* as it (or
another problem) did in Jeff's code... which is why I checked further.
Defaulting to "near" on an unadorned jcc has the advantage of not seeing
a "short jump out of range" error (unless we specify "short" where we
shouldn't have), but doesn't match previous default (no "-O" switch)
behavior of either 0.98 or any of the "interim" versions. I don't
*think* it's what we want to do...
I'm less sure what to do with backward jumps. "Just like 0.98" seems a
poor criterion at this point. "Just like interim versions" might get us
into less trouble there!
Can you - do you think we "should" - default to short on jcc's?
Best,
Frank
|