Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Jun 2001 10:47:18 -0700
From:      John Merryweather Cooper <jmcoopr@webmail.bmi.net>
To:        j mckitrick <jcm@FreeBSD-uk.eu.org>
Cc:        John Merryweather Cooper <jmcoopr@webmail.bmi.net>, freebsd-questions@FreeBSD.ORG
Subject:   Re: what does this define do?
Message-ID:  <20010620104718.C14541@johncoop>
In-Reply-To: <20010620182353.A3958@dogma.freebsd-uk.eu.org>; from jcm@FreeBSD-uk.eu.org on Wed, Jun 20, 2001 at 10:23:53 -0700
References:  <20010620173855.A2941@dogma.freebsd-uk.eu.org> <20010620094925.A14541@johncoop> <20010620182353.A3958@dogma.freebsd-uk.eu.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--SLDf9lqlvOQaIe6s
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

On 2001.06.20 10:23 j mckitrick wrote:
> | This is, of course, highly compiler dependent.  Looks like somebody is
> | concerned with the efficiency of a MOV AX, 0 as opposed to an XOR AX,
> AX. 
> 
> I wondered about that.  But i agree, with no way of knowing what the
> compiler is doing anyway, it doesn't make much sense.  
> 
> The way it is being used seems to invalid the potential benefit:
> 
> static char var = FLAG1 | FLAG2 | n(FLAG3)
> 
> because the compiler might drop the n() values anyway, since ORing with 0
> does nothing anyway.  I can understand the n() values being in the code
> as
> placeholders, so you can see what lines are hi or low on the hardware
> register, but if the compiler drops them anyway, optimizing the macro
> rather
> than just using 0 doesn't seem to buy any benefits.
> 
> 
> Jonathon
> --
> "It is through will alone I set my mind in motion...."
> 

Because I qualify as among the curious, I ran a little test program to look
at the assembly.  A couple of observations:

	1) the "not/and" macro breaks on doubles;
	2) the "xor" macro also breaks on doubles;
	3) the compiler doesn't know about fldz . . . :)

See attached . . .

jmc
--SLDf9lqlvOQaIe6s
Content-Type: text/x-c; charset=us-ascii
Content-Disposition: attachment; filename="testzero.c"

#include <stdlib.h>

#define n1(flags) (~(flags) & (flags))
#define n2(flags) (0)
#define n3(flags) ((flags) ^ (flags))
#define n4(flags) ((flags) - (flags))

#define INIT_IVAR (-1)
#define INIT_DVAR (3.1425)

int main (int argc, char **argv)
{
  int ivar;
  double dvar;

  ivar = INIT_IVAR;
  ivar = n1(ivar);

  ivar = INIT_IVAR;
  ivar = n2(ivar);

  ivar = INIT_IVAR;
  ivar = n3(ivar);

  ivar = INIT_IVAR;
  ivar = n4(ivar);

  /* dvar = INIT_DVAR;  causes compiler error */
  /*  dvar = n1(dvar);                        */

  dvar = INIT_DVAR;
  dvar = n2(dvar);

  /* dvar = INIT_DVAR;  causes compiler error */
  /* dvar = n3(dvar);                         */

  dvar = INIT_DVAR;
  dvar = n4(dvar);

  exit(0);
}

--SLDf9lqlvOQaIe6s
Content-Type: application/octet-stream; charset=us-ascii
Content-Disposition: attachment; filename="testzero.s"
Content-Transfer-Encoding: base64

CnRlc3R6ZXJvLm86ICAgICBmaWxlIGZvcm1hdCBlbGYzMi1pMzg2CgpEaXNhc3NlbWJseSBv
ZiBzZWN0aW9uIC50ZXh0OgoKMDAwMDAwMDAgPG1haW4+OgoJOzsgcHJvbG9ndWUKICAgMDoJ
NTUgICAgICAgICAgICAgICAgICAgCXB1c2ggICAlZWJwCiAgIDE6CTg5IGU1ICAgICAgICAg
ICAgICAgIAltb3YgICAgJWVzcCwlZWJwCiAgIDM6CTgzIGVjIDE4ICAgICAgICAgICAgIAlz
dWIgICAgJDB4MTgsJWVzcAoJOzsgbjEoZmxhZ3MpCiAgIDY6CWM3IDQ1IGZjIGZmIGZmIGZm
IGZmIAltb3ZsICAgJDB4ZmZmZmZmZmYsMHhmZmZmZmZmYyglZWJwKQogICBkOgk4YiA0NSBm
YyAgICAgICAgICAgICAJbW92ICAgIDB4ZmZmZmZmZmMoJWVicCksJWVheAogIDEwOglmNyBk
MCAgICAgICAgICAgICAgICAJbm90ICAgICVlYXgKICAxMjoJMjEgNDUgZmMgICAgICAgICAg
ICAgCWFuZCAgICAlZWF4LDB4ZmZmZmZmZmMoJWVicCkKCTs7IG4yKGZsYWdzKQogIDE1Oglj
NyA0NSBmYyBmZiBmZiBmZiBmZiAJbW92bCAgICQweGZmZmZmZmZmLDB4ZmZmZmZmZmMoJWVi
cCkKICAxYzoJYzcgNDUgZmMgMDAgMDAgMDAgMDAgCW1vdmwgICAkMHgwLDB4ZmZmZmZmZmMo
JWVicCkKCTs7IG4zKGZsYWdzKQogIDIzOgljNyA0NSBmYyBmZiBmZiBmZiBmZiAJbW92bCAg
ICQweGZmZmZmZmZmLDB4ZmZmZmZmZmMoJWVicCkKICAyYToJOGIgNDUgZmMgICAgICAgICAg
ICAgCW1vdiAgICAweGZmZmZmZmZjKCVlYnApLCVlYXgKICAyZDoJMzEgNDUgZmMgICAgICAg
ICAgICAgCXhvciAgICAlZWF4LDB4ZmZmZmZmZmMoJWVicCkKCTs7IG40KGZsYWdzKQogIDMw
OgljNyA0NSBmYyBmZiBmZiBmZiBmZiAJbW92bCAgICQweGZmZmZmZmZmLDB4ZmZmZmZmZmMo
JWVicCkKICAzNzoJYzcgNDUgZmMgMDAgMDAgMDAgMDAgCW1vdmwgICAkMHgwLDB4ZmZmZmZm
ZmMoJWVicCkKCTs7IG4yKGZsYWdzKQogIDNlOglkZCAwNSAwMCAwMCAwMCAwMCAgICAJZmxk
bCAgIDB4MAogIDQ0OglkZCA1ZCBmMCAgICAgICAgICAgICAJZnN0cGwgIDB4ZmZmZmZmZjAo
JWVicCkKICA0NzoJYzcgNDUgZjAgMDAgMDAgMDAgMDAgCW1vdmwgICAkMHgwLDB4ZmZmZmZm
ZjAoJWVicCkKICA0ZToJYzcgNDUgZjQgMDAgMDAgMDAgMDAgCW1vdmwgICAkMHgwLDB4ZmZm
ZmZmZjQoJWVicCkKCTs7IG40KGZsYWdzKQogIDU1OglkZCAwNSAwMCAwMCAwMCAwMCAgICAJ
ZmxkbCAgIDB4MAogIDViOglkZCA1ZCBmMCAgICAgICAgICAgICAJZnN0cGwgIDB4ZmZmZmZm
ZjAoJWVicCkKICA1ZToJZGQgNDUgZjAgICAgICAgICAgICAgCWZsZGwgICAweGZmZmZmZmYw
KCVlYnApCiAgNjE6CWRjIDY1IGYwICAgICAgICAgICAgIAlmc3VibCAgMHhmZmZmZmZmMCgl
ZWJwKQogIDY0OglkZCA1ZCBmMCAgICAgICAgICAgICAJZnN0cGwgIDB4ZmZmZmZmZjAoJWVi
cCkKCTs7IGVwaWxvZ3VlLCBleGl0KDApLCBldGMuCiAgNjc6CTgzIGM0IGY0ICAgICAgICAg
ICAgIAlhZGQgICAgJDB4ZmZmZmZmZjQsJWVzcAogIDZhOgk2YSAwMCAgICAgICAgICAgICAg
ICAJcHVzaCAgICQweDAKICA2YzoJZTggZmMgZmYgZmYgZmYgICAgICAgCWNhbGwgICA2ZCA8
bWFpbisweDZkPgogIDcxOgk4MyBjNCAxMCAgICAgICAgICAgICAJYWRkICAgICQweDEwLCVl
c3AKICA3NDoJYzkgICAgICAgICAgICAgICAgICAgCWxlYXZlICAKICA3NToJYzMgICAgICAg
ICAgICAgICAgICAgCXJldCAgICAK

--SLDf9lqlvOQaIe6s--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010620104718.C14541>