Howto setup alt. embedded assembler color coding in C ?

[hs2]

@SlickTeam: What can I do to let SE recognize also this notation

Code: [Select]

__asm__ __volatile__ ( );as embedded assembler (along with 'asm volatile') ?
C-PP setup didn't help.

One more issue:
Color coding stops/breaks if quoting is divided into parts due to a macro (here: PPC405_ERR77(0,%3)):

Code: [Select]

// Erratum #77 on the 405 means we need a sync or dcbt before every stwcx.
#define PPC405_ERR77(ra,rb)   "dcbt " #ra "," #rb ";"

static __inline__ void atomic_add(int a, atomic_t *v)
{
   int t;

   __asm__ __volatile__(
"1:   lwarx %0,0,%3     # atomic_add\n\
   add   %0,%2,%0\n"
   PPC405_ERR77(0,%3)
"  stwcx.   %0,0,%3 \n\
   bne-  1b"
   : "=&r" (t), "+m" (v->counter)
   : "r" (a), "r" (&v->counter)
   : "cc");
}

Any possibilty to solve that ?

HS2

[Dennis]

__asm__ will be supported in 12.0.1.

[g] did we need yet another non-standard way to embedded assembly?  (asm, _asm, __asm, now __asm__)

Maybe I should go ahead and also add support for __a__s__m__ ...

[hs2]

  (HP++)
HS2

[hs2]

Hello Dennis,

sorry for bugging you again.
It seems that the embedded asm colorizer requires the opening '(' to be on the same line as 'asm inline' (thanks for the '__asm__' support, which was not my idea. It's used e.g. in linux).

Do you think it's possible to support:
1. the opening paren also on the next line (below)
2. to take care of nested parens ?
The colorizer stops imm. after the first closing ')' regardless if it's in a comment or part of a macro (here PPC405_ERR77).
Be aware of the constraint section (it's GNU asm) which also contains parens

See the example below which contains all these use cases. Hope it helps.

Code: [Select]

int   LifoPush (tLifo *pLifo, tCell *pCell)
{
   int t;

   __asm__ __volatile__
   (
      "1:                           \n"
      "     lwarx    %0, 0, %1      \n"   // get Top reserved
      "     stw      %0, 0(%2)      \n"   // store Top -> Link
      PPC405_ERR77(0,%1)
      "     stwcx.   %2, 0, %1      \n"   // store pCell -> Top reserved
      "     bne-     1b             \n"
      "2:                           \n"
      "     lwarx    %0, 0, %3      \n"   // get Cnt reserved (informal)
      "     addic    %0, %0, 1      \n"   // inc Cnt
      PPC405_ERR77(0,%3)
      "     stwcx.   %0, 0, %3      \n"   // store Cnt reserved
      "     bne-     2b"
      : "=&r" (t)
      : "r" (&pLifo->Top), "r" (pCell), "r" (&pLifo->Cnt)
      : "cc", "memory"
   );

   return t;
}
Halfway colorized embedded code is a bit annoying...

Thanks a lot,

HS2

[Dennis]

I'll file a defect report including your example.  The open paren on a separate line problem is very difficult, however, I can put in a simple fix for 12.0.2 to deal with nested parens that do not span line boundaries.

[hs2]

Thanks a lot ! Even the quick fix for 12.0.2 will be a big help !
I assume this will also solve the find-matching-paren problem I didn't mention.
In this example the asm volatile - parens are not recognized as pair correctly.

Code: [Select]

#define  maxp(a,b) asm volatile("cmpw    %1, %2; bge+ 1f; mr %0, %2; 1:": "=r" (a) : "0" (a), "r" (b): "cc")
HS2

[Dennis]

That is a separate problem.  I'll file another bug report.

[hs2]

Stupid question: Which lexer is used for coloring inline assembler in C/C++ and how can it be configured ?

HS2

[Dennis]

On Windows, it is the "ASM" Lexer.

On Unix, it is whatever lexer the "s" extension is configured to use.

[hs2]

Thanks a lot for this information Dennis !
Just to be sure it's the lexer named 'asm' and not the lexer associated with extension 'asm' on Windows ?
In that case I'd prefer the Unix method also on Windows which avoids patching the asm lexer for each type of inline assembly I've to deal with (yes - I've to).

Thanks,
HS2

[hs2]

Thought about it and I'd like to change the term 'prefer' to a 'feature request'.
I'm heavily using SE on Windows for cross-platform (embedded) development. In that field it's not unusual to use inline assembly and multiple processor types even for 1 product. Hence it really makes sense to be able to configure the inline assemby lexer in charge.
(BTW: Quite a number of these embedded toolchains are GNU based so good GNU inline assembly support is important.)

Thanks,
HS2

[Dennis]

OK.  I'll add it to SlickEdit 2008, so it will use whatever lexer is associated with the "asm" extension for Windows and whatever lexer is associated with the "s" extension on Unix.

The reason to keep them separate is backward compatiblity.  Also, by default, "s" is referred to "asm390" (OS/390 assembler language) on Windows -- because a ".s" file on Windows is more likely to be legacy System/390 code than actual Unix assembly for the majority of our customers.

[hs2]

Ok - great ! For the time being I'm maintaining a small set of user.vlx but that's doable b/c I quickly see if it's the wrong one
I hope you agree that this is a further improvement of SE as embedded / cross-platform IDE #1.
To be clear I've absolutely no concerns using diff. extensions for diff. platforms as assembly reference extension.
I only tried to say that the method used on Unix should be used for Windows too.

Thanks again,
HS2

BTW: Embedded linux is getting more and more popular.
Who knows - one day the majority of your customers are referring to GNU assembly files when talking about '.s' files