In v2.02pre dated 12/28/09 short jumps with a displacement of 127 bytes are lengthened unnecessarily to the opposite condition and a near jump. Did not occur in the previous build.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is a bug concerning backpatching in v1.96-v2.01. I started to fix it before xmas, but then took a vacation,. so it's somewhat "half-fixed" currently.
However, "half-fixed" just means that JWasm may need more passes than necessary. It doesn't mean that "sub-optimal" code may be generated. So please, if possible, upload your test-case which reveals this behavior!
japheth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Retested with build dated 12/29/09 and it still happens. This happens with displacements 7Dh-7Fh. Generates opposite condition short jump and near jump for 8086/286, conditional rel16 jump (0F 8x) for 386+
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This may be true, but is more or less irrelevant because the backpatching issue has to be fixed, and that's why I have to know under what circumstances this "regression" occurs. Just a simple forward reference does NOT trigger it - a valid test case is needed!
japheth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
code segment para 'code'
assume cs:code,ds:code
org 100h
entry: jmp skip1
test ax,ax
jnz skip2
db 126 dup(90h)
skip1: ret
skip2: ret
code ends
end entry
The jmp skip1 causes the issue, removing this jmp makes the problem go away. Note JWasm v2.02 from 12/22 does 3 passes on this code while the 12/29 build only does 2 passes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The change which causes the lenghening has been reverted because a full fix would significantly delay JWasm v2.02. The fix is now "scheduled" for v2.03.
japheth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In v2.02pre dated 12/28/09 short jumps with a displacement of 127 bytes are lengthened unnecessarily to the opposite condition and a near jump. Did not occur in the previous build.
There is a bug concerning backpatching in v1.96-v2.01. I started to fix it before xmas, but then took a vacation,. so it's somewhat "half-fixed" currently.
However, "half-fixed" just means that JWasm may need more passes than necessary. It doesn't mean that "sub-optimal" code may be generated. So please, if possible, upload your test-case which reveals this behavior!
japheth
Retested with build dated 12/29/09 and it still happens. This happens with displacements 7Dh-7Fh. Generates opposite condition short jump and near jump for 8086/286, conditional rel16 jump (0F 8x) for 386+
This is a regression - the issue does not occur in v2.02pre build from 12/22/09
> This is a regression -
This may be true, but is more or less irrelevant because the backpatching issue has to be fixed, and that's why I have to know under what circumstances this "regression" occurs. Just a simple forward reference does NOT trigger it - a valid test case is needed!
japheth
code segment para 'code'
assume cs:code,ds:code
org 100h
entry: jmp skip1
test ax,ax
jnz skip2
db 126 dup(90h)
skip1: ret
skip2: ret
code ends
end entry
The jmp skip1 causes the issue, removing this jmp makes the problem go away. Note JWasm v2.02 from 12/22 does 3 passes on this code while the 12/29 build only does 2 passes.
Listing (.8086)
code segment para 'code'
assume cs:code,ds:code
org 100h
00000100 E98500 entry: jmp skip1
00000103 85C0 test ax,ax
00000105 7403E97F00 jnz skip2
0000010A 9090909090909090 db 126 dup(90h)
00000188 C3 skip1: ret
00000189 C3 skip2: ret
0000018A code ends
end entry
Listing (.386)
code segment para 'code'
assume cs:code,ds:code
.386
org 100h
00000100 E98400 entry: jmp skip1
00000103 85C0 test ax,ax
00000105 0F857F00 jnz skip2
00000109 9090909090909090 db 126 dup(90h)
00000187 C3 skip1: ret
00000188 C3 skip2: ret
00000189 code ends
end entry
The change which causes the lenghening has been reverted because a full fix would significantly delay JWasm v2.02. The fix is now "scheduled" for v2.03.
japheth