Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!uunet!mcsun!hp4nl!alchemy!nevries
From: nevries@cs.ruu.nl (Nico de Vries)
Newsgroups: comp.lang.c
Subject: Re: Bug in TC2.0 Optimization
Message-ID: <1991May03.104059.13090@cs.ruu.nl>
Date: 3 May 91 10:40:59 GMT
Article-I.D.: cs.1991May03.104059.13090
References: <1991Apr22.130418.8079@uni-paderborn.de> <1991Apr28.220249.1@cc.helsinki.fi>
Organization: Utrecht University, Dept. of Computer Science
Lines: 33

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.