Strange syntax highlighting

Anyone know why this syntax is highlighted incorrectly, or if there is a fix available?

See incorrect highlighting here:
http://download2.efilive.com/Software/V7/syntax1.png

See correct syntax highlighting here:
http://download2.efilive.com/Software/V7/syntax2.png

Regards
Paul

 Another reason to avoid inline assembler!

Presumably, the highlighter is detecting the language as 'C', and is getting confused by the non-C part (the inline assembler).

So why don't you just use the __nop intrinsic, instead of messing about with inline assembler:

http://www.keil.com/support/man/docs/armccref/armccref_cjabcdad.htm

 RE: Another reason to avoid inline assembler!

Nothing non-C about the inline assembler in this case.

The highlighter should never try to understand the contents of #define statements. It should just concentrate on comments and continuation characters.

 RE: Another reason to avoid inline assembler!

The highlighter should never try to understand the contents of #define statements.

"Never say never", as the saying goes. Sometimes it has to. #defines can contain all kinds of stuff --- sometimes there's so much code in there that you need syntax highlighting in there as much as you need it in normal code. And then there's the case of #defines containing unpaired parentheses that the highlighter has to keep track of to understand usage of those macros, e.g. the infamous C-for-Pascal-enthusiasts abominations

#define BEGIN {
#define END }

 RE: Another reason to avoid inline assembler!

But your example is an explicit example why the syntax highlighter should not try to understand the contents of preprocessor statements.

And people who are stupid enough to write BEGIN instead of a left brace really should not get any syntax highlighting of the rest of their code. A syntax highlighter that tries to solve the above problem will fail for people who write valid C/C++ code, just to possibly handle one or two abominations. I would consider that counterproductive.

If a user really wants to see syntax highlighting of preprocessed code, all real C/C++ compilers has an option to just preprocess the code.

 RE: Another reason to avoid inline assembler!

I don't think there is anything "non-C" in the #define. Well it is non-C, but it is not non-Keil-C, since the Keil documentation says to construct inline assembler that way.

It's no big deal, I'm just pointing out that there seems to be a problem with the syntax highlighter.

As a software developer, I appreciate my customers telling me when they find a problem (especially if they can also show how to reprodcue it) so it can be fixed, I'm just doing the same for Keil.

Regards
Paul

 RE: Another reason to avoid inline assembler!

Paul;
You do know that you are not communicating with Keil on this forum site.

As a software developer, I appreciate my customers telling me when they find a problem (especially if they can also show how to reprodcue it) so it can be fixed, I'm just doing the same for Keil.

I do note that Herr Keil does frequently answer on this forum but Keil support does not promise to monitor this forum. Any direct suggestion should be emailed to support@keil.com.
However, your post did create several good points and info. I, for one, thank you for posting.
Bradford

 RE: Another reason to avoid inline assembler!

As a C programmer, currently developing in Pascal (Delphi), I would prefer to change BEGIN into { and END into }. I think the curly braces are far more elegant. I can't understand anyone wanting to go the other way. :)

Regards
Paul

 RE: Another reason to avoid inline assembler!

I can't get the code to compile when using __nop - what is the correct syntax?
Regards
Paul

 RE: I can't get the code to compile when using __nop

Show the code that fails, and the message(s) produced...

"what is the correct syntax?"

Hopefully, the manual page reviously cited shows the correct syntax, doesn't it...?!

;-)