EmbeddedRelated.com
Forums
Memfault State of IoT Report

How to Auto-generate Unique Labels in C?

Started by aekalman November 23, 2004
Ha ha, I am sleeping on this one. Of course you are right on that.

At 03:09 PM 11/23/2004, Paul Curtis wrote:
>...
>As a man of considerable merit in the C preprocessor world, I would have
>though you should know the answer to this one.  I'm sure it's a
FAQ.  If
>you use A##__LINE__ you'll get A__LINE__ all the time as __LINE__
won't
>be expanded.  Wrapping __LINE__ up in a macro that expands to the
>expansion of __LINE__ is how you get round this particular problem.
>...
>

// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com) 


Beginning Microcontrollers with the MSP430

Hi,

yes, you can find it in the old C-FAQs:

// standard macros (K&R A.12, C-FAQs 11.17)
#   define mc_CAT(x, y) x ## y

#   define mc_XCAT(x, y) mc_CAT(x, y)

#   define mc_STR(x) #x

#   define mc_XSTR(x) mc_STR(x)

Regards,

Rolf


msp430@msp4... schrieb am 24.11.04 00:18:46:
> 
> 
> Ha ha, I am sleeping on this one. Of course you are right on that.
> 
> At 03:09 PM 11/23/2004, Paul Curtis wrote:
> >...
> >As a man of considerable merit in the C preprocessor world, I would
have
> >though you should know the answer to this one.  I'm sure it's
a FAQ.  If
> >you use A##__LINE__ you'll get A__LINE__ all the time as __LINE__
won't
> >be expanded.  Wrapping __LINE__ up in a macro that expands to the
> >expansion of __LINE__ is how you get round this particular problem.
> >...
> >
> 
> // richard (This email is for mailing lists. To reach me directly, please 
> use richard at imagecraft.com) 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 




Hi Rolf, 

> Paul,
> 
> ok, i found it in chapter 6.4.2.2 in C99, thanks for the hint.
> I used these macros only with gcc and they always worked in 
> user and kernel space on several platforms.
> On MSP430 i used simpler macros, without fprinft/kprintf.

Sure, you can't compile Linux without GCC...  ;-)

__FUNCTION__ is rather nasty.  It's a complex thing, mixing
pre-processing and parsing, something that's best kept apart.  __func__
is just something the compiler invents and is easily mistaken for a
preprocessing symbol.

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors  

Paul,

ok, i found it in chapter 6.4.2.2 in C99, thanks for the hint.
I used these macros only with gcc and they always worked in user and 
kernel space on several platforms.
On MSP430 i used simpler macros, without fprinft/kprintf.

Regards,

Rolf


msp430@msp4... schrieb am 24.11.04 00:15:32:
> 
> 
> Rolf,
> 
> __FUNCTION__ is not ISO C.
> __func__ does not expand to a constant, it is not a preprocessor symbol,
> it is generated by the compiler.
> 
> So, each of these fails Andrew's requirement os something that can
> generate a label name.
> 
> --
> Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors   
> 
> > -----Original Message-----
> > From: rolf.freitag@rolf... [mailto:rolf.freitag@rolf...] 
> > Sent: 23 November 2004 22:55
> > To: msp430@msp4...
> > Subject: RE: [msp430] How to Auto-generate Unique Labels in C?
> > 
> > 
> > Hi
> > 
> > i am using a similar macro for debugging:
> > 
> > // Debug messages for user and kernel space.
> > // Preparation because ANSI-/ISO-C99 does not know 
> > __FUNCTION__ (gcc feature).
> > #   ifndef __FUNCTION__
> > #      define __FUNCTION__ __func__
> > #   endif
> > #   if defined(DeBuG) || defined(DEBUG)
> > #      ifdef __KERNEL__
> > #         define mc_DEBUG(fmt, args...) { 
> > (void)printk(KERN_EMERG "mc_DEBUG: \"%s\",
\"%s\", line %d: ", \
> >         __FILE__, __FUNCTION__, __LINE__); 
> > (void)printk(KERN_EMERG fmt, ## args); }
> > #      else
> > #         define mc_DEBUG(fmt, args...) { 
> > (void)fprintf(stderr, "mc_DEBUG: \"%s\",
\"%s\", line %d: ", \
> >         __FILE__, __FUNCTION__, __LINE__); 
> > (void)fprintf(stderr, fmt, ## args); }
> > #      endif
> > #   else
> > #      define mc_DEBUG(fmt, args...)
> > #   endif
> > 
> > and several macros for static and dynamic debug level:
> > 
> > // same with dynamic debug level
> > #   if defined(DeBuG) || defined(DEBUG)
> > #      define mc_debug(debug_level, fmt, args...)\
> >    if (debug_level >= DEBUG_LEVEL) mc_DEBUG(fmt, ##args);
> > #   else
> > #      define mc_debug(debug_level, fmt, args...)
> > #   endif
> > 
> > // same with static debug level; expands to no code if not used
> > #   if ((defined(DeBuG) || defined(DEBUG)) && (DEBUG_LEVEL
<= 0))
> > #      define mc_debug0(fmt, args...) mc_DEBUG(fmt, ##args);
> > #   else
> > #      define mc_debug0(fmt, args...)
> > #   endif
> > 
> > ...
> > 
> > In the linux sources you can find hundreds of other and more 
> > simple debug macros.
> > 
> > Rolf
> > 
> > 
> > msp430@msp4... schrieb am 23.11.04 23:38:35:
> > > 
> > > 
> > > Hi Andrew:
> > > 
> > > #define DoLabel(X) X
> > > #define MyUniqueLabelMacro() A##DoLabel(__LINE__)
> > > 
> > > This generates identifiers of the type A<linenumber.  This is
a 
> > > use-once macro, you can use it exactly once to define a label but

> > > can't use it to reference a label.  If the labels are only
inside 
> > > compounds, then they are scoped by the compiler so there 
> > are no name clashes possible anyway.
> > > 
> > > --
> > > Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk 
> > CrossWorks 
> > > for MSP430, ARM, and (soon) Atmel AVR processors
> > > 
> > > > -----Original Message-----
> > > > From: aekalman [mailto:aek@aek@...]
> > > > Sent: 23 November 2004 22:28
> > > > To: msp430@msp4...
> > > > Subject: [msp430] How to Auto-generate Unique Labels in C?
> > > > 
> > > > 
> > > > 
> > > > Hi All.
> > > > 
> > > > This is more of a C-centric, rather than MSP430-specific 
> > question, 
> > > > but with all the compiler vendors here on-line :) I 
> > though I'd ask 
> > > > ... I think I once saw this done, but I've searched 
> > everywhere and 
> > > > can't find it.
> > > > 
> > > > Is there a way / what is the best way to have the compiler 
> > > > auto-generate lables in C code?
> > > > 
> > > > In the broadest sense, what I want is to be able to 
> > invoke a macro 
> > > > and have it create a unique label each time it is invoked,
e.g.
> > > > 
> > > > #define MyUniqueLabelMacro()      // your wizard code here
> > > > 
> > > > and use it like this:
> > > > 
> > > > {
> > > >   ...
> > > >   MyUniqueLabelMacro()
> > > >   ...
> > > >   MyUniqueLabelMacro()
> > > > }
> > > > 
> > > > so that it results in
> > > > 
> > > > {
> > > >   ...
> > > >   auniquelabel:
> > > >   ...
> > > >   anotheruniquelabel:
> > > > }
> > > > 
> > > > I can do this manually by explicitly passing a label name to
the 
> > > > macro, but I would prefer (because the labels are only 
> > used locally, 
> > > > not outside the scope of any function) to not have to pass
an 
> > > > argument to the macro. Each such label must be unique,
however, 
> > > > otherwise (in my experience) many assemblers will choke.
> > > > 
> > > > I'd like to see a solution in ANSI C only (no in-line
assembly, 
> > > > etc.), but I'll settle for the latter of the former
isn't 
> > possible.
> > > > 
> > > > I was thinking about something along the lines of using 
> > __FILE__ and 
> > > > __LINE__, but the filename is likely to cause problems 
> > with its '.'
> > > > character, etc. ...
> > > > 
> > > > Thanks for any help.
> > > > 
> > > > --Andrew E Kalman, Ph.D.
> > > > aek at pumpkin inc dot com
> > > > 
> > > >   
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > ------------------------ Yahoo! Groups Sponsor 
> > > > --------------------~--> Make a clean sweep of pop-up
ads.
> > > > Yahoo! Companion Toolbar.
> > > > Now with Pop-Up Blocker. Get it for free!
> > > > http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/CFFolB/TM
> > > > --------------------------
> > > > ------~->
> > > > 
> > > > .
> > > > 
> > > >  
> > > > Yahoo! Groups Links
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > .
> > > 
> > >  
> > > Yahoo! Groups Links
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> > 
> > ------------------------ Yahoo! Groups Sponsor 
> > --------------------~-->
> > $9.95 domain names from Yahoo!. Register anything.
> > http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/CFFolB/TM
> > --------------------------
> > ------~-> 
> > 
> > .
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 




How I just love the simplicity and clarity of C. The meaning of the 
following simply leaps from the page without any effort at interpretation.

:?}

Sorry rolf, that was just irresistible.

Al

rolf.freitag@rolf... wrote:

> Hi
> 
> i am using a similar macro for debugging:
> 
> // Debug messages for user and kernel space.
> // Preparation because ANSI-/ISO-C99 does not know __FUNCTION__ (gcc
feature).
> #   ifndef __FUNCTION__
> #      define __FUNCTION__ __func__
> #   endif
> #   if defined(DeBuG) || defined(DEBUG)
> #      ifdef __KERNEL__
> #         define mc_DEBUG(fmt, args...) { (void)printk(KERN_EMERG
"mc_DEBUG: \"%s\", \"%s\", line %d: ", \
>         __FILE__, __FUNCTION__, __LINE__); (void)printk(KERN_EMERG fmt, ##
args); }
> #      else
> #         define mc_DEBUG(fmt, args...) { (void)fprintf(stderr,
"mc_DEBUG: \"%s\", \"%s\", line %d: ", \
>         __FILE__, __FUNCTION__, __LINE__); (void)fprintf(stderr, fmt, ##
args); }
> #      endif
> #   else
> #      define mc_DEBUG(fmt, args...)
> #   endif
> 
> and several macros for static and dynamic debug level:
> 
> // same with dynamic debug level
> #   if defined(DeBuG) || defined(DEBUG)
> #      define mc_debug(debug_level, fmt, args...)\
>    if (debug_level >= DEBUG_LEVEL) mc_DEBUG(fmt, ##args);
> #   else
> #      define mc_debug(debug_level, fmt, args...)
> #   endif
> 
> // same with static debug level; expands to no code if not used
> #   if ((defined(DeBuG) || defined(DEBUG)) && (DEBUG_LEVEL <=
0))
> #      define mc_debug0(fmt, args...) mc_DEBUG(fmt, ##args);
> #   else
> #      define mc_debug0(fmt, args...)
> #   endif
> 
> ...
> 
> In the linux sources you can find hundreds of other and more simple debug
macros.
> 
> Rolf
> 
> 
> msp430@msp4... schrieb am 23.11.04 23:38:35:
> 
>>
>>Hi Andrew:
>>
>>#define DoLabel(X) X
>>#define MyUniqueLabelMacro() A##DoLabel(__LINE__) 
>>
>>This generates identifiers of the type A<linenumber.  This is a
use-once
>>macro, you can use it exactly once to define a label but can't use
it to
>>reference a label.  If the labels are only inside compounds, then they
>>are scoped by the compiler so there are no name clashes possible anyway.
>>
>>--
>>Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
>>CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors  
>>
>>
>>>-----Original Message-----
>>>From: aekalman [mailto:aek@aek@...] 
>>>Sent: 23 November 2004 22:28
>>>To: msp430@msp4...
>>>Subject: [msp430] How to Auto-generate Unique Labels in C?
>>>
>>>
>>>
>>>Hi All.
>>>
>>>This is more of a C-centric, rather than MSP430-specific 
>>>question, but with all the compiler vendors here on-line :) I 
>>>though I'd ask ... I think I once saw this done, but I've 
>>>searched everywhere and can't find it.
>>>
>>>Is there a way / what is the best way to have the compiler 
>>>auto-generate lables in C code?
>>>
>>>In the broadest sense, what I want is to be able to invoke a 
>>>macro and have it create a unique label each time it is invoked,
e.g.
>>>
>>>#define MyUniqueLabelMacro()      // your wizard code here
>>>
>>>and use it like this:
>>>
>>>{
>>>  ...
>>>  MyUniqueLabelMacro()
>>>  ...
>>>  MyUniqueLabelMacro()
>>>}
>>>
>>>so that it results in
>>>
>>>{
>>>  ...
>>>  auniquelabel:
>>>  ...
>>>  anotheruniquelabel:
>>>}
>>>
>>>I can do this manually by explicitly passing a label name to 
>>>the macro, but I would prefer (because the labels are only 
>>>used locally, not outside the scope of any function) to not 
>>>have to pass an argument to the macro. Each such label must 
>>>be unique, however, otherwise (in my experience) many 
>>>assemblers will choke.
>>>
>>>I'd like to see a solution in ANSI C only (no in-line 
>>>assembly, etc.), but I'll settle for the latter of the former 
>>>isn't possible.
>>>
>>>I was thinking about something along the lines of using 
>>>__FILE__ and __LINE__, but the filename is likely to cause 
>>>problems with its '.'
>>>character, etc. ...
>>>
>>>Thanks for any help.
>>>
>>>--Andrew E Kalman, Ph.D.
>>>aek at pumpkin inc dot com
>>>
>>>  
>>>
>>>
>>>
>>>
>>>
>>>------------------------ Yahoo! Groups Sponsor 
>>>--------------------~--> Make a clean sweep of pop-up ads. 
>>>Yahoo! Companion Toolbar.
>>>Now with Pop-Up Blocker. Get it for free!
>>>http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/CFFolB/TM
>>>--------------------------
>>>------~-> 
>>>
>>>.
>>>
>>> 
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>.
>>
>> 
>>Yahoo! Groups Links
>>
>>
>>
>> 
>>
>>
>>
> 
> 
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 


Al,

Have you tried APL?  Or even Perl?  Now, without proper training, those
are seriously scary.

Personally, I love Modula-2 but I can't make a business out of it.  The
C strain has impetus behind it.  Modula-2 died when it was standardised
(a failing of the standardisation process, unfortunately, VDM-SL with
pie-in-the-sky aspirations) whereas C has prospered by codifying
existing practice and not pushing too far and leaving (gasp!) holes
where the compiler implementers can play games and taunt each other in
the playground.

The C preprocessor should never have been but, boy, is it useful!

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors  

> -----Original Message-----
> From: onestone [mailto:onestone@ones...] 
> Sent: 23 November 2004 23:43
> To: msp430@msp4...
> Subject: Re: [msp430] How to Auto-generate Unique Labels in C?
> 
> 
> How I just love the simplicity and clarity of C. The meaning 
> of the following simply leaps from the page without any 
> effort at interpretation.
> 
> :?}
> 
> Sorry rolf, that was just irresistible.
> 
> Al
> 
> rolf.freitag@rolf... wrote:
> 
> > Hi
> > 
> > i am using a similar macro for debugging:
> > 
> > // Debug messages for user and kernel space.
> > // Preparation because ANSI-/ISO-C99 does not know 
> __FUNCTION__ (gcc feature).
> > #   ifndef __FUNCTION__
> > #      define __FUNCTION__ __func__
> > #   endif
> > #   if defined(DeBuG) || defined(DEBUG)
> > #      ifdef __KERNEL__
> > #         define mc_DEBUG(fmt, args...) { 
> (void)printk(KERN_EMERG "mc_DEBUG: \"%s\", \"%s\",
line %d: ", \
> >         __FILE__, __FUNCTION__, __LINE__); 
> (void)printk(KERN_EMERG fmt, ## args); }
> > #      else
> > #         define mc_DEBUG(fmt, args...) { 
> (void)fprintf(stderr, "mc_DEBUG: \"%s\", \"%s\",
line %d: ", \
> >         __FILE__, __FUNCTION__, __LINE__); 
> (void)fprintf(stderr, fmt, ## args); }
> > #      endif
> > #   else
> > #      define mc_DEBUG(fmt, args...)
> > #   endif
> > 
> > and several macros for static and dynamic debug level:
> > 
> > // same with dynamic debug level
> > #   if defined(DeBuG) || defined(DEBUG)
> > #      define mc_debug(debug_level, fmt, args...)\
> >    if (debug_level >= DEBUG_LEVEL) mc_DEBUG(fmt, ##args);
> > #   else
> > #      define mc_debug(debug_level, fmt, args...)
> > #   endif
> > 
> > // same with static debug level; expands to no code if not used
> > #   if ((defined(DeBuG) || defined(DEBUG)) && (DEBUG_LEVEL
<= 0))
> > #      define mc_debug0(fmt, args...) mc_DEBUG(fmt, ##args);
> > #   else
> > #      define mc_debug0(fmt, args...)
> > #   endif
> > 
> > ...
> > 
> > In the linux sources you can find hundreds of other and 
> more simple debug macros.
> > 
> > Rolf
> > 
> > 
> > msp430@msp4... schrieb am 23.11.04 23:38:35:
> > 
> >>
> >>Hi Andrew:
> >>
> >>#define DoLabel(X) X
> >>#define MyUniqueLabelMacro() A##DoLabel(__LINE__)
> >>
> >>This generates identifiers of the type A<linenumber.  This is a 
> >>use-once macro, you can use it exactly once to define a label but 
> >>can't use it to reference a label.  If the labels are only
inside 
> >>compounds, then they are scoped by the compiler so there 
> are no name clashes possible anyway.
> >>
> >>--
> >>Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk 
> CrossWorks 
> >>for MSP430, ARM, and (soon) Atmel AVR processors
> >>
> >>
> >>>-----Original Message-----
> >>>From: aekalman [mailto:aek@aek@...]
> >>>Sent: 23 November 2004 22:28
> >>>To: msp430@msp4...
> >>>Subject: [msp430] How to Auto-generate Unique Labels in C?
> >>>
> >>>
> >>>
> >>>Hi All.
> >>>
> >>>This is more of a C-centric, rather than MSP430-specific
question, 
> >>>but with all the compiler vendors here on-line :) I though
I'd ask 
> >>>... I think I once saw this done, but I've searched
everywhere and 
> >>>can't find it.
> >>>
> >>>Is there a way / what is the best way to have the compiler 
> >>>auto-generate lables in C code?
> >>>
> >>>In the broadest sense, what I want is to be able to invoke a
macro 
> >>>and have it create a unique label each time it is invoked, e.g.
> >>>
> >>>#define MyUniqueLabelMacro()      // your wizard code here
> >>>
> >>>and use it like this:
> >>>
> >>>{
> >>>  ...
> >>>  MyUniqueLabelMacro()
> >>>  ...
> >>>  MyUniqueLabelMacro()
> >>>}
> >>>
> >>>so that it results in
> >>>
> >>>{
> >>>  ...
> >>>  auniquelabel:
> >>>  ...
> >>>  anotheruniquelabel:
> >>>}
> >>>
> >>>I can do this manually by explicitly passing a label name to
the 
> >>>macro, but I would prefer (because the labels are only 
> used locally, 
> >>>not outside the scope of any function) to not have to pass an 
> >>>argument to the macro. Each such label must be unique, however,

> >>>otherwise (in my experience) many assemblers will choke.
> >>>
> >>>I'd like to see a solution in ANSI C only (no in-line
assembly, 
> >>>etc.), but I'll settle for the latter of the former
isn't possible.
> >>>
> >>>I was thinking about something along the lines of using 
> __FILE__ and 
> >>>__LINE__, but the filename is likely to cause problems with its
'.'
> >>>character, etc. ...
> >>>
> >>>Thanks for any help.
> >>>
> >>>--Andrew E Kalman, Ph.D.
> >>>aek at pumpkin inc dot com
> >>>
> >>>  
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>------------------------ Yahoo! Groups Sponsor 
> >>>--------------------~--> Make a clean sweep of pop-up ads.
> >>>Yahoo! Companion Toolbar.
> >>>Now with Pop-Up Blocker. Get it for free!
> >>>http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/CFFolB/TM
> >>>--------------------------
> >>>------~->
> >>>
> >>>.
> >>>
> >>> 
> >>>Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>.
> >>
> >> 
> >>Yahoo! Groups Links
> >>
> >>
> >>
> >> 
> >>
> >>
> >>
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > .
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> > 
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> --------------------~-->
> $9.95 domain names from Yahoo!. Register anything.
> http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/CFFolB/TM
> --------------------------
> ------~-> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
> 

Come on Al, lets be fair. I don't (usually :-) ) argue w/ C vs.
assembly, 
but Andrew is asking for some really esoteric thing. Why don't you give us 
an equivalent asm example, in ANY of your favorite macro assembler's
syntax.

At 03:43 PM 11/23/2004, onestone wrote:


>How I just love the simplicity and clarity of C.
The meaning of the
>following simply leaps from the page without any effort at interpretation.
>
>:?}
>
>Sorry rolf, that was just irresistible.
>

// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com) 


--- In msp430@msp4..., Richard <richard-lists@i...> wrote:
> Come on Al, lets be fair. I don't (usually
:-) ) argue w/ C vs.
assembly, 
> but Andrew is asking for some really esoteric
thing. Why don't you
give us 
> an equivalent asm example, in ANY of your favorite
macro assembler's
syntax.

Ok, guys, thanks for all the input.

I now recognize that what I want / need is tied more to the
assembler's (in this case, a non-MSP430 toolset's) global scope than
to C in general (because C labels are only local).

As to my lack of C preprocessor knowledge :), I was asking more for
the "why" and not the "how" re ##__LINE__. Makes sense now
-- thanks
Paul.

The reason for all this is due to cross-platform compatibility of the
Salvo RTOS. Right now, if you write e.g.

OS_Delay(12, uniquelabel);

It will work with all of Salvo's ports: PICs (no software stacks),
AVRs, MSP430s, etc. Trouble is, the label is only used in the PIC
ports, and is unnecessary (and is ignored) in the others. I'd love to
get rid of the unique label requirement altogether, and I swear I saw
a Salvo user who had achieved that (on the PIC), but for the life of
me I can no longer find it. 

More than likely, the key is to pass stuff to the PICC assembler via
in-line assembly and ## and something else.

All in the name of Salvo v4 ...

--Andrew E. Kalman, Ph.D.
aek at pumpkin inc dot com




Hi,

> Neat, but if I read it correctly, the uniqueness
of the labels is
> hidden in string arguments to printk().

yes, i use the macros as a debug-version of printf with varible argument list.
I started with the version from the book "The pragmatic programmer".
The argurments in the first and last macros are evaluated from from
kprintf/fprintf
but you must use other functions on MSP430.

On MSP430 i used e. g.

// CHECK derived from the book "The pragmatic programmer".
// Example usage: CHECK(foo, 0);
#define CHECK(LINE, EXPECTED)                                \
  {                                                          \
    int i_rc = LINE;                                           \
    if (i_rc != EXPECTED)                                      \
        ut_abort(__FILE__, __LINE__, #LINE, i_rc, EXPECTED);  \
  }

And because of

 #      define __FUNCTION__ __func__

my macros should work with every (C99-) preprocessor and compiler; not only gcc.

Regards,

Rolf


------------- 
> I need the compiler to treat them as individual,
unique labels, and
> not string literals.
> 
> I should look into the Linux source, though ...
> 
> Thanks,
> 
> --Andrew E. Kalman, Ph.D.
> aek at pumpkin inc dot com
> 
> 
> --- In msp430@msp4..., <rolf.freitag@e...> wrote:
> > Hi
> > 
> > i am using a similar macro for debugging:
> > 
> > // Debug messages for user and kernel space.
> > // Preparation because ANSI-/ISO-C99 does not know __FUNCTION__ (gcc
> feature).
> > #   ifndef __FUNCTION__
> > #      define __FUNCTION__ __func__
> > #   endif
> > #   if defined(DeBuG) || defined(DEBUG)
> > #      ifdef __KERNEL__
> > #         define mc_DEBUG(fmt, args...) { (void)printk(KERN_EMERG
> "mc_DEBUG: \"%s\", \"%s\", line %d: ", \
> >         __FILE__, __FUNCTION__, __LINE__); (void)printk(KERN_EMERG
> fmt, ## args); }
> > #      else
> > #         define mc_DEBUG(fmt, args...) { (void)fprintf(stderr,
> "mc_DEBUG: \"%s\", \"%s\", line %d: ", \
> >         __FILE__, __FUNCTION__, __LINE__); (void)fprintf(stderr,
> fmt, ## args); }
> > #      endif
> > #   else
> > #      define mc_DEBUG(fmt, args...)
> > #   endif
> > 
> > and several macros for static and dynamic debug level:
> > 
> > // same with dynamic debug level
> > #   if defined(DeBuG) || defined(DEBUG)
> > #      define mc_debug(debug_level, fmt, args...)\
> >    if (debug_level >= DEBUG_LEVEL) mc_DEBUG(fmt, ##args);
> > #   else
> > #      define mc_debug(debug_level, fmt, args...)
> > #   endif
> > 
> > // same with static debug level; expands to no code if not used
> > #   if ((defined(DeBuG) || defined(DEBUG)) && (DEBUG_LEVEL
<= 0))
> > #      define mc_debug0(fmt, args...) mc_DEBUG(fmt, ##args);
> > #   else
> > #      define mc_debug0(fmt, args...)
> > #   endif
> > 
> > ...
> > 
> > In the linux sources you can find hundreds of other and more simple
> debug macros.
> 
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 




Andrew, 

> The reason for all this is due to cross-platform 
> compatibility of the Salvo RTOS. Right now, if you write e.g.
> 
> OS_Delay(12, uniquelabel);
> 
> It will work with all of Salvo's ports: PICs (no software 
> stacks), AVRs, MSP430s, etc. Trouble is, the label is only 
> used in the PIC ports, and is unnecessary (and is ignored) in 
> the others. I'd love to get rid of the unique label 
> requirement altogether, and I swear I saw a Salvo user who 
> had achieved that (on the PIC), but for the life of me I can 
> no longer find it. 
> 
> More than likely, the key is to pass stuff to the PICC 
> assembler via in-line assembly and ## and something else.

Uniqueness need not be based on file co-ordinates, it can be based on
compilation time.  Unfortunately, __TIME__ doesn't cut it here and
can't
be bent to work as there is no de-stringizing operator nor something
that can remove the colons if there were.

The resolution is blindingly obvious: propose an extension to the ISO
standard, get it approved, get the standard implemented by all compiler
vendors that support Salvo, and then you can eliminate that label!  :-)

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors  


Memfault State of IoT Report