Date: Wed, 14 Aug 1996 04:44:15 +1000 From: Bruce Evans <bde@zeta.org.au> To: ajones@ctron.com, hackers@freefall.freebsd.org Subject: Re: <machine/spl.h> and C++ Message-ID: <199608131844.EAA15809@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> I'm writing a device driver in C++, and have run into a problem with >the GENSPL macro in <machine/spl.h>. g++ is croaking on the statement: >__asm __volatile("":::"memory"); >with the following error: >parse error before "::" > Without getting into an argument about whether g++ is in error about >accepting the code as it is, I'm asking whether or not this code >fragment even needs to exist. Yes, it does. It tells gcc that memory may have changed so that gcc is forced to reload cached variables in code like this: extern int glob; int s; /* * Do an cheap although imperfect test of `glob' to minimize * overheads. */ if (glob) { /* * Probably something to do. An interrupt may have * cleared `glob' since we tested it before calling * splfoo(), so we have to test it again to be sure * that there is someting to do. */ s = splfoo(); if (glob) dostuff(glob); splx(s); } Without the dummy memory-accessing asm, `glob' isn't changed by splfoo(). It isn't declared volatile, so the second test of `glob' can be omitted if it really hasn't changed. The asm stops this invalid optimization. The problem could also be avoided by declaring `glob' as volatile. This method isn't used because 1) drivers are generally sloppy about declaring things volatile. 2) declaring things volatile would mainly slow things down. In the above, `glob' is non-volatile iff it is protected by an splfoo(), normal accesses to it are protected, so declaring it as volatile would be wasteful. > Now, I just tried an interesting experiment. I generated the assembly >code (using init_main.c) with the asm declaration in there. It produced >#APP >#NO_APP >where the asm declaration should be. Then I generated the assembly with >the asm declaration removed, and the code was the exact same except the >#APP/#NO_APP code was gone. gas also says: I checked all the spl's in last year's kernel for changes (pessimizations) caused by the asm. There was no significant change in most cases. There were a few small pesimizations (usually for _local_ variables being vulnerable to memory being changed, although it would take very poorly designed assembler to change a local variable), and no cases where the asm fixed a bug. > So it seems like the asm statement is a no-op. Is this a fair >assumption? Can I just safely get rid of it? What are people's >thoughts about this? This was fixed almost a 12 months ago in -current and 8 months ago in -stable. Change `:::' to ` : : : ' and complain to anyone who uses insufficient whitespace between tokens. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608131844.EAA15809>