I have found strange behaviour of HLA in some situations.
1) HLA code:
if (edx > 0) then
xor(edx,edx);
elseif ((eax < $100) || !test_proc(eax)) then
xor(ecx,ecx);
endif;

ASM generated code:
cmp edx, 00h ;/* 0 */
jng L1768_false__hla_
cmp eax, 0100h ;/* $100 */
jb L1770__hla_
xor edx, edx
jmp L1768_endif__hla_
L1768_false__hla_:
push eax
call L1765_test_proc__hla_ ; test_proc
test eax,eax
jne L1769_false__hla_
L1770__hla_:
xor ecx, ecx
L1769_false__hla_:
L1768_endif__hla_:

I think here is some mistake with positioning "cmp" instructions.

2) This is not a bug i think, but inefficience in generated code
HLA code:
if (eax == edx) then
xor(ecx,ecx);
if (ecx == ebx) then
xor(eax,eax);
endif;
else
xor(edx,edx);
endif;

ASM generated code:
cmp eax, edx
jne L1766_false__hla_
xor ecx, ecx
cmp ecx, ebx
jne L1767_false__hla_
xor eax, eax
L1767_false__hla_:
jmp L1766_endif__hla_
L1766_false__hla_:
xor edx, edx
L1766_endif__hla_:

When ecx != ebx in second "if" then there must be jump to L1766_endif__hla_ not to L1767_false__hla_. With such thing we do not execute "jmp L1766_endif__hla_" because this instruction does the same.

Sorry for my bad english.
Posted on 2005-01-11 02:52:16 by Elohim Meth
Hi,

You are right, in the first situation, there is really a bug in the generated code. If (edx>0) is false, (edx < $100) will never be tested because the generated code for this test is misplaced.



cmp edx, 00h ;/* 0 */
jng L1768_false__hla_
cmp eax, 0100h ;/* $100 */ <--- here
jb L1770__hla_ <--- and here
xor edx, edx
jmp L1768_endif__hla_
L1768_false__hla_:
push eax
call L1765_test_proc__hla_ ; test_proc
test eax,eax
jne L1769_false__hla_
L1770__hla_:
xor ecx, ecx


should be



cmp edx, 00h ;/* 0 */
jng L1768_false__hla_
xor edx, edx
jmp L1768_endif__hla_
L1768_false__hla_:
cmp eax, 0100h ;/* $100 */ <--- have to go here
jb L1770__hla_
push eax
call L1765_test_proc__hla_ ; test_proc
test eax,eax
jne L1769_false__hla_
L1770__hla_:
xor ecx, ecx


maybe corrected in version 1.74 :wink:
Posted on 2005-01-11 04:35:08 by arlequin
Error confirmed for FASM output:



cmp edx, 00h ;/* 0 */
jna L2_false__hla_
cmp eax, 0100h ;/* $100 */
jb L4__hla_
xor edx, edx
jmp L2_endif__hla_
L2_false__hla_:
push eax
call L1_test_proc__hla_ ; test_proc
test eax,eax
jne L3_false__hla_
L4__hla_:
xor ecx, ecx
L3_false__hla_:
L2_endif__hla_:
QuitMain__hla_:
pushd 00h
call dword ptr [__imp__ExitProcess@4]
;_HLAMain endp

Posted on 2005-01-11 17:17:09 by Kain
I have found strange behaviour of HLA in some situations.
1) HLA code:
if (edx > 0) then
xor(edx,edx);
elseif ((eax < $100) || !test_proc(eax)) then
xor(ecx,ecx);
endif;



The problem seems to be a bug in Bison. I'm not sure, the grammar is a bit convoluted and I'm playing tricks to handle procedure calls in this code, but the grammar does look right (the problem seems to be with the way Bison does lookahead). Until I can figure this out, the best I can offer is the following work-around:



if (edx > 0) then

xor(edx,edx);

else
if
(
(ebx < $100)
|| !test_proc(ebx)
) then

xor(ecx,ecx);

endif;

endif;

Cheers,
Randy Hyde
Posted on 2005-01-11 22:54:05 by rhyde
Thanks everybody for replies!
And what about situation 2?
Posted on 2005-01-12 02:30:42 by Elohim Meth
Thanks everybody for replies!
And what about situation 2?



Situation 2 is a classic example of "if you care about this kind of stuff, you shouldn't be using HLL-like constructs." :-)

Seriously, though, there's not much chance of this kind of optimization in HLA v1.x. The internal structure of the compiler just won't allow it. I definitely plan to add an optimizer to HLA v2.0 (actually, if I follow the original road map, the difference between HLA v2.0 and v3.0 is the existence of the optimizer). In any case, don't expect great code here (note: MASM actually *does* optimize this type of code). There are lots of known "bad code optimizations" that occur in HLA. I have no plans of correcting most of these because that effort is better spent on HLA v2.0.

As for topic #1, I have found the problem and I've corrected it. Look forward to an HLA v1.75 release this weekend or so.
Cheers,
Randy Hyde
Posted on 2005-01-12 21:36:20 by rhyde