preprocessor: % as args to #defines

preprocessor: % as args to #defines

[Ralf Corsepius]

Hi,

I am facing a problem with a behavioral change in gcc:

Given this code fragment:
-- snip --
#define CONCAT1(a, b) CONCAT2(a, b)
#define CONCAT2(a, b) a ## b
#define REG(x) CONCAT1 (__REGISTER_PREFIX__, x)
-- snip --

Using this fragment from inside of a *.S-file with gcc-3.2.3 works
without any complaint:
# m68k-rtems4.6-gcc -P -E -Wall -o bla.i bla.S
# m68k-rtems4.6-gcc -P -E -Wall -ansi -o bla.i bla.S

With gcc-3.3.2, this happens:
# m68k-rtems4.7-gcc -P -E -Wall -o bla.i bla.S
=> No complaint, bla.i is being produced

# m68k-rtems4.7-gcc -P -E -Wall -ansi -o bla.i bla.S
bla.S:3:8: pasting "%" and "reg" does not give a valid preprocessing
token
=> Error, bla.i is not being produced

If using this fragment from inside of *.c-files, this happens:
# m68k-rtems4.6-gcc -P -E -Wall -o bla.i bla.c
bla.c:3:8: warning: pasting "%" and "reg" does not give a valid
preprocessing token
=> Warning, nevertheless bla.i is being produced.

# m68k-rtems4.6-gcc -P -E -Wall -ansi -o bla.i bla.c
bla.c:3:8: warning: pasting "%" and "reg" does not give a valid
preprocessing token
=> Warning, bla.i is being produced.

With gcc-3.3.2:
# m68k-rtems4.7-gcc -P -E -Wall -o bla.i bla.c
bla.c:3:8: pasting "%" and "reg" does not give a valid preprocessing
token
=> Error, no bla.i

# m68k-rtems4.7-gcc -P -E -Wall -ansi -o bla.i bla.c
bla.c:3:8: pasting "%" and "reg" does not give a valid preprocessing
token
=> Error, no bla.i


Apparent cause for gcc to complain is __REGISTER_PREFIX__ == % for
m68k-rtems*. 

The __REGISTER_PREFIX__ preprocessor trick above is known to have been
functional for more than 10 years. Even gcc itself uses it (cf.
gcc/config/m68klb1sf68.asm).

Now, gcc >= 3.3's behavior renders these macros non-functional.

Questions:
* How to re-write these macros into ansi-compliant form (I've tried to,
but no success until now)
* Why does gcc-3.3.x issue errors instead of warnings like gcc-3.2.x
did?
* Why does gcc-3.3.x behave differently on *.c and *.S file types?

Ralf

Re: preprocessor: % as args to #defines

[Michael Matz]

Hi,

On Thu, 29 Jan 2004, Ralf Corsepius wrote:

> -- snip --
> #define CONCAT1(a, b) CONCAT2(a, b)
> #define CONCAT2(a, b) a ## b
> #define REG(x) CONCAT1 (__REGISTER_PREFIX__, x)
> -- snip --

One can't use '##' for this anymore.  Normally one would simply delete it, 
but that produces a space (i.e. "% reg").  If that isn't wanted you might 
want to use this:

#define EVAL(x) x
#define CONCAT(x, y) EVAL(x)EVAL(y)
#define __REG__ %
#define REG(x) CONCAT (__REG__, x)
REG(reg)


Ciao,
Michael.

Re: preprocessor: % as args to #defines

[Zack Weinberg]

Ralf Corsepius <corsepiu@faw.uni-ulm.de> writes:

> * How to re-write these macros into ansi-compliant form (I've tried to,
> but no success until now)

Try this:

#define RP() __REGISTER_PREFIX__
#define REG(x) RP()x

> * Why does gcc-3.3.x issue errors instead of warnings like gcc-3.2.x
> did?

People have had long enough to fix their code.

> * Why does gcc-3.3.x behave differently on *.c and *.S file types?

.S files get special dispensation, because assembly syntax is not the
same as C syntax.

zw

Re: preprocessor: % as args to #defines

[Ralf Corsepius]

On Thu, 2004-01-29 at 18:41, Zack Weinberg wrote:
> Ralf Corsepius <corsepiu@faw.uni-ulm.de> writes:
> 
> > * How to re-write these macros into ansi-compliant form (I've tried to,
> > but no success until now)
> 
> Try this:
> 
> #define RP() __REGISTER_PREFIX__
> #define REG(x) RP()x
Thanks, this and Michael's proposals both seems to work.

> > * Why does gcc-3.3.x issue errors instead of warnings like gcc-3.2.x
> > did?
> 
> People have had long enough to fix their code.
;) Well, I only tripped this issue because of accidentially having used
-ansi on *.S's, otherwise this issue would not have popped up for my
code.

Apart from this, newlib, gcc-3.3.x and gcc-3.4 are using this kind of
constructs.

> > * Why does gcc-3.3.x behave differently on *.c and *.S file types?
> 
> .S files get special dispensation, because assembly syntax is not the
> same as C syntax.
OK.

Ralf

Re: preprocessor: % as args to #defines

[Zack Weinberg]

Ralf Corsepius <corsepiu@faw.uni-ulm.de> writes:

>> People have had long enough to fix their code.
> ;) Well, I only tripped this issue because of accidentially having used
> -ansi on *.S's, otherwise this issue would not have popped up for my
> code.

Right.  That's pretty much a 'don't do that then.'

> Apart from this, newlib, gcc-3.3.x and gcc-3.4 are using this kind of
> constructs.

Yeah, I know.  I wish people would use GAS macros instead.

zw

Re: preprocessor: % as args to #defines

[Joern Rennecke]

> Yeah, I know.  I wish people would use GAS macros instead.

Actually, use of gas macros can confuse the compiler, when it looses
track of how long an asm insert is.

Re: preprocessor: % as args to #defines

[Zack Weinberg]

Joern Rennecke <joern.rennecke@superh.com> writes:

>> Yeah, I know.  I wish people would use GAS macros instead.
>
> Actually, use of gas macros can confuse the compiler, when it looses
> track of how long an asm insert is.

I take the attitude that anything longer than a single instruction
probably ought to be in a separate file of assembly.

zw

Re: preprocessor: % as args to #defines

[Syd Polk]

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]


On Jan 29, 2004, at 10:51 AM, Zack Weinberg wrote:

> Joern Rennecke <joern.rennecke@superh.com> writes:
>
>>> Yeah, I know.  I wish people would use GAS macros instead.
>>
>> Actually, use of gas macros can confuse the compiler, when it looses
>> track of how long an asm insert is.
>
> I take the attitude that anything longer than a single instruction
> probably ought to be in a separate file of assembly.
>
> zw
>

It seems that most of Apple's customers do not agree at all; most major 
Macintosh software vendors have many many lines of inline assembly in 
their source files. It is one of the big preventers of GCC adoption in 
the Apple world.

Syd Polk
Apple Computer
Technology EPM, Mac OS X Development Tools
+1 408 974-0577


[-- Attachment #2: Type: text/enriched, Size: 841 bytes --]



On Jan 29, 2004, at 10:51 AM, Zack Weinberg wrote:


<excerpt>Joern Rennecke <<joern.rennecke@superh.com> writes:


<excerpt><excerpt>Yeah, I know.  I wish people would use GAS macros
instead.

</excerpt>

Actually, use of gas macros can confuse the compiler, when it looses

track of how long an asm insert is.

</excerpt>

I take the attitude that anything longer than a single instruction

probably ought to be in a separate file of assembly.


zw


</excerpt>

It seems that most of Apple's customers do not agree at all; most
major Macintosh software vendors have many many lines of inline
assembly in their source files. It is one of the big preventers of GCC
adoption in the Apple world.


<fontfamily><param>Lucida Grande</param>Syd Polk

Apple Computer

Technology EPM, Mac OS X Development Tools

+1 408 974-0577

</fontfamily>

Re: preprocessor: % as args to #defines

[Andrew Pinski]

On Jan 29, 2004, at 10:55, Syd Polk wrote:
> It seems that most of Apple's customers do not agree at all; most  
> major Macintosh software vendors have many many lines of inline  
> assembly in their source files. It is one of the big preventers of GCC  
> adoption in the Apple world.

I wished GCC never supplied an inline-asm because it causes so much  
problems in that
it can cause seg faults when you are using %c0 or some other operand  
character which
does not work for your case, there are three different bugs for this on  
three different
targets.  The idea of using a compiler is to have the compiler optimize  
for you, if the
compiler does not, then either drop the compiler, improve it, or write  
full asm.

Inline-asm to gcc basically gives the information for the machine  
descriptions to the user
which is a bad thing.

I have to agree with Zack here that most of the problems come from  
people abusing inline-asm
too much problems for people to use with more than one asm instructions  
as most of gcc does
not understand really that the asm is really more than one instruction  
(yes parts of it does
but the problems that come with thins like this:

asm("lots of  
asm":"=r"(x0),"=r"(x1),"=r"(x2),"=r"(x3),"=r"(x4),"=r"(x5):"r"(y0),"r"(y 
1),"r"(y2),"r"(y3),"r"(y4),"r"(y5));
people do not why this fails on targets like x86 which does not have  
enough registers to fill
all those constraints.  There are others things like this happens a lot  
in people's code.
Also glibc has ugly (I mean ugly) inline-asm in their headers for some  
string and math
functions (at least on x86).


Thanks,
Andrew Pinski
a gcc bug master (and not speaking for Apple at all)

Re: preprocessor: % as args to #defines

[Zack Weinberg]

[Please use standard quoting conventions.]

Syd Polk <spolk@apple.com> writes:
> Zack Weinberg <zack@codesourcery.com> writes:
>> I take the attitude that anything longer than a single instruction
>> probably ought to be in a separate file of assembly.
>
> It seems that most of Apple's customers do not agree at all; most
> major Macintosh software vendors have many many lines of inline
> assembly in their source files.

Yeah, I'm aware that mine is a minority position.

> It is one of the big preventers of GCC adoption in the Apple world.

I don't see how this follows, however.  GCC does support big blocks of
inline assembly acceptably well.  Is it a syntax thing?

zw

Re: preprocessor: % as args to #defines

[Ian Lance Taylor]

Andrew Pinski <pinskia@physics.uc.edu> writes:

> I wished GCC never supplied an inline-asm because it causes so much
> problems 

....

While acknowledging that inline assembler is a fertile source of
problems, I would say that gcc's support for inline assembler is one
of the main reasons that gcc is useful in compiling for embedded
systems and kernels.  It permits scheduling of assembler code,
e.g. access to I/O ports, and thus permits high speed code which
really can not be written in C in any other way.

Ian

Re: preprocessor: % as args to #defines

[Syd Polk]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]


On Jan 29, 2004, at 11:19 AM, Zack Weinberg wrote:

>
> [Please use standard quoting conventions.]
>
> Syd Polk <spolk@apple.com> writes:
>> Zack Weinberg <zack@codesourcery.com> writes:
>>> I take the attitude that anything longer than a single instruction
>>> probably ought to be in a separate file of assembly.
>>
>> It seems that most of Apple's customers do not agree at all; most
>> major Macintosh software vendors have many many lines of inline
>> assembly in their source files.
>
> Yeah, I'm aware that mine is a minority position.
>
>> It is one of the big preventers of GCC adoption in the Apple world.
>
> I don't see how this follows, however.  GCC does support big blocks of
> inline assembly acceptably well.  Is it a syntax thing?

Yes. Our competition does not require machine description knowledge to 
use inline assembly. It's syntax is much easier to use.

Stan Shebs implemented this syntax in Apple's version of gcc 3.3 (well, 
to a certain extent). But it's not in 3.4 or 3.5. Somebody here is 
going to have to make it work again. Hopefully, whoever that is can 
spend the huge amount of time necessary to propose it to mainline GCC, 
and it won't have to be Apple Local forever.

I am not holding my breath.

>
> zw
>
>
Syd Polk
Apple Computer
Technology EPM, Mac OS X Development Tools
+1 408 974-0577


[-- Attachment #2: Type: text/enriched, Size: 1461 bytes --]



On Jan 29, 2004, at 11:19 AM, Zack Weinberg wrote:


<excerpt>

[Please use standard quoting conventions.]


Syd Polk <<spolk@apple.com> writes:

<excerpt>Zack Weinberg <<zack@codesourcery.com> writes:

<excerpt>I take the attitude that anything longer than a single
instruction

probably ought to be in a separate file of assembly.

</excerpt>

It seems that most of Apple's customers do not agree at all; most

major Macintosh software vendors have many many lines of inline

assembly in their source files.

</excerpt>

Yeah, I'm aware that mine is a minority position.


<excerpt>It is one of the big preventers of GCC adoption in the Apple
world.

</excerpt>

I don't see how this follows, however.  GCC does support big blocks of

inline assembly acceptably well.  Is it a syntax thing?

</excerpt>

Yes. Our competition does not require machine description knowledge to
use inline assembly. It's syntax is much easier to use.


Stan Shebs implemented this syntax in Apple's version of gcc 3.3
(well, to a certain extent). But it's not in 3.4 or 3.5. Somebody here
is going to have to make it work again. Hopefully, whoever that is can
spend the huge amount of time necessary to propose it to mainline GCC,
and it won't have to be Apple Local forever.


I am not holding my breath.


<excerpt>

zw



</excerpt><fontfamily><param>Lucida Grande</param>Syd Polk

Apple Computer

Technology EPM, Mac OS X Development Tools

+1 408 974-0577

</fontfamily>

Re: preprocessor: % as args to #defines

[Joel Sherrill]

Andrew Pinski wrote:

> On Jan 29, 2004, at 10:55, Syd Polk wrote:
> 
>> It seems that most of Apple's customers do not agree at all; most  
>> major Macintosh software vendors have many many lines of inline  
>> assembly in their source files. It is one of the big preventers of 
>> GCC  adoption in the Apple world.
> 
> 
> I wished GCC never supplied an inline-asm because it causes so much  
> problems in that
> it can cause seg faults when you are using %c0 or some other operand  
> character which
> does not work for your case, there are three different bugs for this on  
> three different
> targets.  The idea of using a compiler is to have the compiler optimize  
> for you, if the
> compiler does not, then either drop the compiler, improve it, or write  
> full asm.

I have to wade in here.  Inline assembler is an easy thing to abuse but
it is an incredibly useful and powerful thing when use judiciously.
RTEMS has VERY few pure assembly files because we have macros to
let you do tings like enable/disable interrupts and access processor
special registers.  We do not attempt to write context switches
in inline-asm.

And I would never attempt to beat the compiler at its own game
with it trying to hand optimize.  And I have reject code which
has too much or the wrong type of assembly language.

> Inline-asm to gcc basically gives the information for the machine  
> descriptions to the user
> which is a bad thing.

I agree that it exposes gcc machine descriptions which is weird
in that those are internal and hard to grok as a user writing
inline assembly.

> I have to agree with Zack here that most of the problems come from  
> people abusing inline-asm
> too much problems for people to use with more than one asm instructions  
> as most of gcc does
> not understand really that the asm is really more than one instruction  
> (yes parts of it does
> but the problems that come with thins like this:
> 
> asm("lots of  
> asm":"=r"(x0),"=r"(x1),"=r"(x2),"=r"(x3),"=r"(x4),"=r"(x5):"r"(y0),"r"(y 
> 1),"r"(y2),"r"(y3),"r"(y4),"r"(y5));
> people do not why this fails on targets like x86 which does not have  
> enough registers to fill
> all those constraints.  There are others things like this happens a lot  
> in people's code.
> Also glibc has ugly (I mean ugly) inline-asm in their headers for some  
> string and math
> functions (at least on x86).

I agree the above is quite abusive.  But getting to special math
instructions and being able to inline them is a powerful speedup.
Inlining a 50 instruction memcpy wouldn't make that type of cut to
me.

Some of the code in the gdb stubs looks like even worse to me.

> Thanks,
> Andrew Pinski
> a gcc bug master (and not speaking for Apple at all)

(go ahead .. speak for Apple) :)

> 

--joel

Re: preprocessor: % as args to #defines

[Paul Koning]

>>>>> "Andrew" == Andrew Pinski <pinskia@physics.uc.edu> writes:

 Andrew> On Jan 29, 2004, at 10:55, Syd Polk wrote:
 >> It seems that most of Apple's customers do not agree at all; most
 >> major Macintosh software vendors have many many lines of inline
 >> assembly in their source files. It is one of the big preventers of
 >> GCC adoption in the Apple world.

 Andrew> I wished GCC never supplied an inline-asm because it causes
 Andrew> so much problems in that it can cause seg faults when you are
 Andrew> using %c0 or some other operand character which does not work
 Andrew> for your case, there are three different bugs for this on
 Andrew> three different targets.  The idea of using a compiler is to
 Andrew> have the compiler optimize for you, if the compiler does not,
 Andrew> then either drop the compiler, improve it, or write full asm.

In embedded systems development, that doesn't fly at all.  Embedded
assembly is critical, and the extended asm features of gcc are a very
important and very helpful facility.

	  paul

Re: preprocessor: % as args to #defines

[Jim Wilson]

inline asms can be replaced with intrinsics (built-in functions) with no 
significant loss of functionality.  We may even gain functionality in 
some cases, because we may be able to optimize intrinsics better than 
inline asms.  inline asms are a black box, but we know exactly what an 
intrinsic does.

This places a burden on the compiler writer, since we need an intrinsic 
for every instruction that the end user might want to use, which means 
we may need hundreds of intrisics.  However, this makes things easier 
for users, since intrinsics are much easier to use than inline asms.

The Intel IA-64 compiler does not support inline asm, but it is able to 
compile the linux kernel, because it defines an intrinsic for almost 
every instruction.  The IA-64 linux kernel calls the intrinsics 
directly, and then if compiled by gcc, it uses inline asm to implement 
the intrinsics.

The main disadvantage I see of intrinsics is that it makes it easier for 
other compilers to replace gcc.  Currently, anyone using gcc inline asm 
is captive to gcc, because no other compiler can reasonably implement 
it.  This isn't a very good argument for it though.  And we have already 
lost one major captive, the linux kernel.

Also, another disadvantage is that people who insist on embedding 
assembly code in C, despite compiler experts telling them not to, will 
not be happy with intrinsics.  You can't get your hands dirty writing 
intrinsics, like you can when you write inline asm.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: preprocessor: % as args to #defines

[Syd Polk]

On Jan 29, 2004, at 12:50 PM, Jim Wilson wrote:

> inline asms can be replaced with intrinsics (built-in functions) with 
> no significant loss of functionality.  We may even gain functionality 
> in some cases, because we may be able to optimize intrinsics better 
> than inline asms.  inline asms are a black box, but we know exactly 
> what an intrinsic does.
>
> This places a burden on the compiler writer, since we need an 
> intrinsic for every instruction that the end user might want to use, 
> which means we may need hundreds of intrisics.  However, this makes 
> things easier for users, since intrinsics are much easier to use than 
> inline asms.

I am working on adding PowerPC intrinsics to GCC as we speak...

>
> The Intel IA-64 compiler does not support inline asm, but it is able 
> to compile the linux kernel, because it defines an intrinsic for 
> almost every instruction.  The IA-64 linux kernel calls the intrinsics 
> directly, and then if compiled by gcc, it uses inline asm to implement 
> the intrinsics.
>
> The main disadvantage I see of intrinsics is that it makes it easier 
> for other compilers to replace gcc.  Currently, anyone using gcc 
> inline asm is captive to gcc, because no other compiler can reasonably 
> implement it.  This isn't a very good argument for it though.  And we 
> have already lost one major captive, the linux kernel.
>
> Also, another disadvantage is that people who insist on embedding 
> assembly code in C, despite compiler experts telling them not to, will 
> not be happy with intrinsics.  You can't get your hands dirty writing 
> intrinsics, like you can when you write inline asm.

We have customers who want each, with some overlap.

Syd Polk
Apple Computer
Technology EPM, Mac OS X Development Tools
+1 408 974-0577

Re: preprocessor: % as args to #defines

[Geoff Keating]

Ian Lance Taylor <ian@wasabisystems.com> writes:

> While acknowledging that inline assembler is a fertile source of
> problems, I would say that gcc's support for inline assembler is one
> of the main reasons that gcc is useful in compiling for embedded
> systems and kernels.  It permits scheduling of assembler code,

I'm sure you meant another word here, not 'scheduling'.  One of the
best reasons not to use inline asm is that it can't be scheduled.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: preprocessor: % as args to #defines

[Ian Lance Taylor]

Geoff Keating <geoffk@geoffk.org> writes:

> Ian Lance Taylor <ian@wasabisystems.com> writes:
> 
> > While acknowledging that inline assembler is a fertile source of
> > problems, I would say that gcc's support for inline assembler is one
> > of the main reasons that gcc is useful in compiling for embedded
> > systems and kernels.  It permits scheduling of assembler code,
> 
> I'm sure you meant another word here, not 'scheduling'.  One of the
> best reasons not to use inline asm is that it can't be scheduled.

Mea culpa.  It can be rearranged, hoisted, duplicated, eliminated,
etc., but it can't actually be scheduled.

And Jim was quite correct to point out that intrinsics are actually a
better solution, assuming somebody is patient enough to enter and
document all the appropriate instructions, and add the features
required to support stuff like the carry flag which can not be
expressed in C.

Ian

Re: preprocessor: % as args to #defines

[Joern Rennecke]

> Mea culpa.  It can be rearranged, hoisted, duplicated, eliminated,
> etc., but it can't actually be scheduled.

Well, it can't be scheduled with the C code, but it can be scheduled inside.
When you combine prefetching, loop unswitching, loop unrolling,
modulo scheduling, instruction selection, data layout, register allocation
and stack slot allocation into one holistic optimization, you can do much
better than the compiler.  Then you just leave the boring bits of
calculations needed for preconditioning the outermost asm-ized loop to
the C code.

Re: preprocessor: % as args to #defines

[Dale Johannesen]

On Jan 29, 2004, at 7:11 PM, Ian Lance Taylor wrote:
> Geoff Keating <geoffk@geoffk.org> writes:
>> Ian Lance Taylor <ian@wasabisystems.com> writes:
>>
>>> While acknowledging that inline assembler is a fertile source of
>>> problems, I would say that gcc's support for inline assembler is one
>>> of the main reasons that gcc is useful in compiling for embedded
>>> systems and kernels.  It permits scheduling of assembler code,
>>
>> I'm sure you meant another word here, not 'scheduling'.  One of the
>> best reasons not to use inline asm is that it can't be scheduled.
>
> Mea culpa.  It can be rearranged, hoisted, duplicated, eliminated,
> etc., but it can't actually be scheduled.

Yes, but we do have requests from users who want a mechanism to add
scheduling info to their asm's.   So far we've resisted successfully.

Re: preprocessor: % as args to #defines

[Ian Lance Taylor]

Dale Johannesen <dalej@apple.com> writes:

> Yes, but we do have requests from users who want a mechanism to add
> scheduling info to their asm's.   So far we've resisted successfully.

It seems to me that those users should use intrinsics functions
instead.  It shouldn't be any harder than writing inline assembler.

Ian

Re: preprocessor: % as args to #defines

[Andrew Pinski]

On Jan 29, 2004, at 10:55, Syd Polk wrote:
> It seems that most of Apple's customers do not agree at all; most  
> major Macintosh software vendors have many many lines of inline  
> assembly in their source files. It is one of the big preventers of GCC  
> adoption in the Apple world.

I wished GCC never supplied an inline-asm because it causes so much  
problems in that
it can cause seg faults when you are using %c0 or some other operand  
character which
does not work for your case, there are three different bugs for this on  
three different
targets.  The idea of using a compiler is to have the compiler optimize  
for you, if the
compiler does not, then either drop the compiler, improve it, or write  
full asm.

Inline-asm to gcc basically gives the information for the machine  
descriptions to the user
which is a bad thing.

I have to agree with Zack here that most of the problems come from  
people abusing inline-asm
too much problems for people to use with more than one asm instructions  
as most of gcc does
not understand really that the asm is really more than one instruction  
(yes parts of it does
but the problems that come with thins like this:

asm("lots of  
asm":"=r"(x0),"=r"(x1),"=r"(x2),"=r"(x3),"=r"(x4),"=r"(x5):"r"(y0),"r"(y 
1),"r"(y2),"r"(y3),"r"(y4),"r"(y5));
people do not why this fails on targets like x86 which does not have  
enough registers to fill
all those constraints.  There are others things like this happens a lot  
in people's code.
Also glibc has ugly (I mean ugly) inline-asm in their headers for some  
string and math
functions (at least on x86).


Thanks,
Andrew Pinski
a gcc bug master (and not speaking for Apple at all)

Re: preprocessor: % as args to #defines

[Marc Espie]

Let's talk real-life, then.
Is theere any kind of standard for intrinsices on, say, i386 ?

Speaking from personal experience, the OpenBSD kernel uses inline
assembler to:

- do IO
- establish bufspace barriers (not sure if that's applicable to i386)
- change interrupt blocking level.


The interrupt level hadnling roughly looks like this:
volatile int cpl;       /* Current interrupt priority level.  */
volatile int ipending;  /* Interrupts pending.  */
volatile int astpending;/* Asynchronous software traps (softints) pending. */
static __inline int
splraise(ncpl)
        int ncpl;
{
        int ocpl = cpl;

        if (ncpl > ocpl)
                cpl = ncpl;
        __asm __volatile("":::"memory");
        return (ocpl);
}


note the asm volatile.


software interrupt registration uses asm too.
static __inline void
softintr(mask)
        int mask;
{
        __asm __volatile("orl %1, %0" : "=m"(ipending) : "ir" (mask));

}


can I now do this kind of thing in C entirely ? this is not code I know
well, btw...

Re: preprocessor: % as args to #defines

[Richard Henderson]

On Sat, Feb 14, 2004 at 03:59:50PM +0100, Marc Espie wrote:
> can I now do this kind of thing in C entirely ?

No.


r~