• State Answer Suggested
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 4202 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Inaccurate GNU as warning for eint, dint

David Schultz
Guru 18815 points
Other Parts Discussed in Thread: MSP430FR5969

The TI GNU assembler issues a warning if a nop instruction does not follow an enable of interrupts, eint; According to slau367.pdf the proper place is before the eint.

"Include at least one instruction between the clear of an interrupt enable or
interrupt flag and the EINT instruction. For example: Insert a NOP instruction in
front of the EINT instruction." page 42.

The warning when a nop doesn't follow a dint doesn't correctly describe the reason. It says that it is about changes to the interrupt state when the actual reason is that the following instruction is always executed.

  • 0
    TI__Guru**** 232680 points

    Please show the exact text of the diagnostic you get.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Guru 18815 points
    /usr/ti/gcc/bin/msp430-elf-gcc -g -mmcu=msp430fr5969 -I /home/dsc560/ti/gcc/include -c system.S
    system.S: Assembler messages:
    system.S:166: Warning: a NOP might be needed here because of successive changes in interrupt state
    system.S:458: Warning: a NOP might be needed here because of successive changes in interrupt state

    The first is for the eint and the second for a dint.
  • 0
    TI__Guru**** 232680 points

    Unfortunately, I am unable to reproduce the diagnostic.

    David Schultz36 said:
    The TI GNU assembler issues a warning if a nop instruction does not follow an enable of interrupts, eint

    There must be more to it than that.  Please submit that assembly file, or a cut-down of it which still causes the diagnostic.  Hopefully, it doesn't include any other files.  But if it does, then we need those files as well.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Guru 18815 points 
    GAS LISTING test.S 			page 1


   1               		.text
   2               	
   3 0000 0343      		nop
   4 0002 32D2      		eint
   5 0004 0E4F      		mov	r15,r14
****  Warning: a NOP might be needed here because of successive changes in interrupt state
   6               		.end

  • 0 in reply to David Schultz
    TI__Guru**** 232680 points

    Unfortunately, I still cannot reproduce the issue.  What version do you use?  Please show the output of this command: msp430-elf-gcc --version .

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Guru 18815 points
    /usr/ti/gcc/bin/msp430-elf-as --version
    GNU assembler (GNU Binutils) 2.25.2
  • 0 in reply to David Schultz
    TI__Guru**** 232680 points

    I was using the wrong version.  I can reproduce it now.  Thanks for your patience.  I informed the development team for the GCC MSP430 tools.

    Thanks and regards,

    -George

  • 0 in reply to David Schultz
    Intellectual 390 points
    Yup - this is a bug alright. The assembler is checking for a NOP instruction following the EINT instruction, rather the preceding it.

    I have created a patch which I will be checking in to the FSF sources shortly. Would you like a copy of this patch ?
  • 0 in reply to Nick Clifton
    Guru 18815 points

    Something else I noticed is that an older version (2.24.51.20140505) doesn't issue this warning even with the "-my" switch. Fortunately, the current version shuts up with the "-mY' switch.


    Perhaps because it switched from talking about the dint and eint instructions to setting and clearing GIE I missed that a dint should never immediately follow a eint. That seems extremely unlikely but I can think of ways for it to happen. So a nop after a eint instruction might sometimes be useful and is certainly consistent with the warning given. But if the assembler can check to see if a nop follows the eint, it ought to be able to check and see if a dint follows.


    But if the assembler warns about that I would think that it should warn about the lack of a nop before eint instructions just in case you cleared a peripheral interrupt enable or flag. Note that the C compiler inserts nops after eint/dint but not before the eint.


    The warning after the dint is not correct only in the sense that it doesn't correctly describe the reason why.


    Thanks, but I don't need the patch, thanks to the "-mY" switch working but at least this got me to read the documentation closely enough to learn something even if my code didn't need to change.

  • 0 in reply to Nick Clifton
    Prodigy 80 points
    Hi Nick, does this issue cause any critical errors to runtime code or is it just an (erroneous) warning? I'm running in to this issue.
  • 0 in reply to Clyde Byrd
    Intellectual 390 points
    Hi Clyde,

    It does not *cause* any critical errors, but it could fail to fix a critical error.

    Since the (unpatched) assembler is checking to see if a NOP instruction follows an EINT instruction it can issue bogus
    warning messages when it fails to find one. It could also insert an extraneous NOP instruction *after* the EINT instruction
    if the -n command line option is used. This would not be serious, just a waste of space. The real problem is that the
    (unpatched) assembler does not check for a NOP instruction *preceeding* the EINT instruction and so it could fail to
    warn/fix about it - thus letting the programmer think that their interrupt enabling code is OK, when in fact it is not.

    Cheers
    Nick
  • 0 in reply to Nick Clifton
    Prodigy 195 points

    In relation to this change, in430.h, line 67,

    #define _disable_interrupts()               __asm__ __volatile__ ("dint")

#define _enable_interrupts()                __asm__ __volatile__ ("eint { nop")

    While I don't really read assembly, combined with the warning this looks like the nop is inserted after the eint. Should this be changed / corrected?

    msp430/gcc$ cat version.properties 
Version=5.3.0.219
Vendor=SOMNIUM Technologies Limited