about #pragma

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, guys,

I am confused with the instruction #pragma.

What does the #pragma mean?
and what does this mean?

#pragma vector = TIMER2_OVF_vect

any additional info will be appreciated!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

#pragma is just a pre-processor token that can be ignored by a C compiler.

So it is used as a mechanism to pass instructions to a compiler.

avr-gcc can read and ignore an IAR or CodeVision pragma.
Likewise IAR can ignore a avr-gcc pragma.

Your particular example is the IAR method of setting the avr interrupt vector number.

One day all AVR compilers may choose to use a similar syntax. If they do, then it will probably be by using #pragma. Put I should not lose any sleep over it.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It means absolutely bunk (nothing) under AVR-GCC. Pragmas are ways for compilers to implement compiler-specific options, in addition to the one or two pragmas mandated by the C standard.

AVR-GCC doesn't use pragmas, and instead uses __attribute__((attribute_name)) for things like ISRs.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
#pragma is just a pre-processor token that can be ignored by a C compiler.

Than why is it used. In my programming experience I never used it but when I try to undestand some default libraries It's use is huge.

Upto my knowledge it is used to activate some code depending upon the condition.

edit:

Quote:

Pragmas are ways for compilers to implement compiler-specific options

Thats what I mean to say. Thanks Dean.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> If they do, then it will probably be by using #pragma.

That certainly won't happen for GCC. Pragmas are a poor design
straight from the beginning, and while C99's optional _Pragma()
replacement at least removes one of the reasons that made it a poor
design, many compilers still don't implement enough of C99 anyway,
so for them, you cannot generate a #pragma within a preprocessing
#if statement, thus in turn you cannot abstract compiler dependencies
e.g. within a central header file. Even IAR which implements C99 and
also _Pragma() still fails to implement it for *all* of its pragmas,
so you have to poison your entire code with stuff like

#if defined __ICCAVR__
#  pragma diag_suppress=Pa050
#endif

Another reason for why they are evil is that the C standard mandates
that pragmas that are not understood by a particular implementation
are to be ignored. Thus, if you try compiling AVR-GCC code with its
__attribute__((signal)) interrupt handlers on a different compiler,
you'll for sure get a compiler error that will clearly tell you you've
got some porting work ahead. If you use the source code for a
compiler that implements interrupt vectors as #pragma, and compile it
on AVR-GCC, it might compile without any error (and even without a
warning unless you enable them!), yet the result is junk and just
won't work.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Than why is it used. In my programming experience I never used it but when I try to undestand some default libraries It's use is huge.

You may choose not to use #pragma. avr-gcc chooses not to use #pragma. But more importantly avr-gcc can legally ignore a #pragma.

As far as I understand, implementation or compiler specific instructions should use #pragma and not use special __attribute tokens.

However I can see that __attribute or some other form of modifier makes neater code.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
It means absolutely bunk (nothing) under AVR-GCC. Pragmas are ways for compilers to implement compiler-specific options, in addition to the one or two pragmas mandated by the C standard.

AVR-GCC doesn't use pragmas, and instead uses __attribute__((attribute_name)) for things like ISRs.

- Dean :twisted:

i'm using avr-gcc. does that mean i can't say, for example, using timer2 overflow interrupt for RTC.

#pragma vector = TIMER2_OVF_vect
ISR (TIMER2_OVF_vect)
{
SECOND++;
}

so what can i say in avr-gcc instead of #pragma.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ommit the PRAGMA - what you have (the correctly named ISR vector) is quite enough for it to work. If you're using a recent version of avr-libc I'd suggest adding the ", ISR_BLOCK" to it for completeness:

ISR(TIMER2_OVF_vect, ISR_BLOCK)
{
SECOND++;
}

With GCC and the avr-libc library, using the ISR macro is all you need to link into the interrupt vector table. You'll notice that if you use a bad vector name with the ISR macro GCC produces a warning, telling you that it couldn't find the corresponding entry in the vector jump table.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jorg,

I would agree that #pragma and the _Pragma() construction are probably not the perfect solution. It just happens that C99 chose to recommend them.

Personally I feel that a pragma should be a special compiler instruction, and that extension modifiers are best handled with a macro like syntax.

PROGMEM or ISR() can be easily handled by the pre-processor.
Something like supporting binary constants or generating position independent code would be a pragma.

I do not think that I would classify any particular mechanism as evil. Perhaps misguided.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> As far as I understand, implementation or compiler specific instructions
> should use #pragma and not use special __attribute tokens.

No, there's no kind of real recommendation about that in the standard.
Anything that starts with two underscores is reserved for the implementation
(i.e. compiler and standard library), so they are free to use these names.

The key point here is that __attribute__ can always be the result of a macro
expansion, #pragma cannot. (_Pragma() can, but see above about the real world
implementation status. Only GCC has fully implemented it, ironically even though
it does not really use it.)

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean, what is that ISR_BLOCK stuff? You said that we should use it for completeness, what completeness?

KISS - Keep It Simple Stupid!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

m23402027: Google is your friend -- http://www.nongnu.org/avr-libc/u...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Dean, what is that ISR_BLOCK stuff? You said that we should use it for completeness, what completeness?

It's an extension to the API which I submitted as a patch a while ago, and which is included in recent versions of avrlib-c. I designed it to be backwards compatible with the old API, which is why not many people have noticed it -- existing code works just fine.

The API can be referenced on this page. Essentially, the ISR macro is extended to include an optional space separated attribute list:

ISR(vector, [attribute 1] [attribute n])
{
// ISR code here
}

With a few nice attributes defined:

ISR_BLOCK - Normal blocking ISR, standard behavior.
ISR_NOBLOCK - Non-blocking ISR, allows for nested interrupts.
ISR_NAKED - No ISR prologue or epilogue.
ISR_ALIASOF(vector) - Aliases the given ISR vector to the second vector.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
It's an extension to the API which I submitted as a patch a while ago, and which is included in recent versions of avrlib-c.

Hei, new version of avrlibc! How could i don't know that.. Geez, Ok. I'll update my lib.
Thanks. :mrgreen:

KISS - Keep It Simple Stupid!