higgins@uni-paderborn.de (Frank Westheider) (04/22/91)
Hi guys !
I`ve perhaps found one more bug in TC2.0
If you set all optimization switches and write the following line
Input[func(bla)+bla] = !Input[func(bla)+bla]
the compiler generates code for the inner section, but
it doesn't load the Value of Input[] !!!!
In Assembly-Mode there will be
xor dx,dx
generated, but dx has never been loaded !
Is this a known bug, or is the Code to comprehensive !
So long
Frank
higgins@uni-paderborn.de
Greetings from United Germany
wirzenius@cc.helsinki.fi (04/29/91)
In article <1991Apr22.130418.8079@uni-paderborn.de>, higgins@uni-paderborn.de (Frank Westheider) writes: > Input[func(bla)+bla] = !Input[func(bla)+bla] A side note: do you really want to call func(bla) twice? > In Assembly-Mode there will be > xor dx,dx > generated, but dx has never been loaded ! I'm not familiar with assembler, but if this does what I think it does, i.e. xors dx with itself and puts the result back into dx, then it doesn't matter whether dx has been loaded or not. The truth table for xor is: a b a xor b 0 0 0 0 1 1 1 0 1 1 1 0 Since the result is 1 if and only if the operands are different, xoring a value with itself is identical to 0, regardless of the value of the operand. So the assembler statement sets dx to 0. Why didn't they just do it explicitly? Maybe this method is faster, smaller, or has some other virtue. Lars Wirzenius wirzenius@cc.helsinki.fi
darcy@druid.uucp (D'Arcy J.M. Cain) (04/29/91)
In article <1991Apr28.220249.1@cc.helsinki.fi> wirzenius@cc.helsinki.fi writes: >In article <1991Apr22.130418.8079@uni-paderborn.de>, higgins@uni-paderborn.de (Frank Westheider) writes: >> In Assembly-Mode there will be >> xor dx,dx >> generated, but dx has never been loaded ! > [...] >Since the result is 1 if and only if the operands are different, xoring >a value with itself is identical to 0, regardless of the value of the >operand. So the assembler statement sets dx to 0. Why didn't they just >do it explicitly? Maybe this method is faster, smaller, or has some >other virtue. One of the skills of being an assembler programmer is to know the tricks to speed up your program. In the above case it is extremely obvious where the savings happen. If you do: mov dx, 0 you will get the same result but you need an extra 2 bytes to store the zero in the code stream and you also need an extra memory fetch to get it, 2 fetches on the 8088. Another other way to zero a register is: sub dx, dx which if I remember correctly uses the same number of cycles (2) as the xor command but has some difference in flag handling on the 386. -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | There's no government Toronto, Ontario, Canada | like no government! +1 416 424 2871 |
nevries@cs.ruu.nl (Nico de Vries) (05/03/91)
In <1991Apr28.220249.1@cc.helsinki.fi> wirzenius@cc.helsinki.fi writes: >In article <1991Apr22.130418.8079@uni-paderborn.de>, higgins@uni-paderborn.de (Frank Westheider) writes: >> Input[func(bla)+bla] = !Input[func(bla)+bla] > >A side note: do you really want to call func(bla) twice? > >> In Assembly-Mode there will be >> xor dx,dx >> generated, but dx has never been loaded ! > >I'm not familiar with assembler, but if this does what I think it does, >i.e. xors dx with itself and puts the result back into dx, then it >doesn't matter whether dx has been loaded or not. The truth table for >xor is: > > a b a xor b > > 0 0 0 > 0 1 1 > 1 0 1 > 1 1 0 > >Since the result is 1 if and only if the operands are different, xoring >a value with itself is identical to 0, regardless of the value of the >operand. So the assembler statement sets dx to 0. Why didn't they just >do it explicitly? Maybe this method is faster, smaller, or has some >other virtue. > >Lars Wirzenius wirzenius@cc.helsinki.fi On 8086 and 80286 processors xor dx,dx is in most cases faster than mov dx, 0h. On 80386 and i486 there is no reel reason to do this any more by the way.
joe@proto.com (Joe Huffman) (05/06/91)
nevries@cs.ruu.nl (Nico de Vries) writes: >On 8086 and 80286 processors xor dx,dx is in most cases faster than >mov dx, 0h. On 80386 and i486 there is no reel reason to do this any more >by the way. Code size is smaller with either xor dx,dx or sub dx,dx than with mov dx,0. Especially when in 386 native mode -- mov edx,0 uses 4 bytes for the constant 0. -- joe@proto.com