From owner-freebsd-questions Wed Jun 20 10:50:35 2001 Delivered-To: freebsd-questions@freebsd.org Received: from smtp.bmi.net (smtp.bmi.net [204.57.191.31]) by hub.freebsd.org (Postfix) with ESMTP id 9E97C37B406 for ; Wed, 20 Jun 2001 10:50:28 -0700 (PDT) (envelope-from jmcoopr@webmail.bmi.net) Received: from smtp.bmi.net (dsl-154.bmi.net [207.173.60.230]) by smtp.bmi.net (Pro-8.9.3/Pro-8.9.3) with SMTP id KAA04616; Wed, 20 Jun 2001 10:47:13 -0700 Date: Wed, 20 Jun 2001 10:47:18 -0700 From: John Merryweather Cooper To: j mckitrick Cc: John Merryweather Cooper , freebsd-questions@FreeBSD.ORG Subject: Re: what does this define do? Message-ID: <20010620104718.C14541@johncoop> References: <20010620173855.A2941@dogma.freebsd-uk.eu.org> <20010620094925.A14541@johncoop> <20010620182353.A3958@dogma.freebsd-uk.eu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="SLDf9lqlvOQaIe6s" Content-Transfer-Encoding: 8bit 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 X-Mailer: Balsa 1.1.4 Lines: 126 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --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 #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