Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Assembly language keywords and directives

Hi Toni,

 

I see that I can returns directive keywords and preprocessor keywords from IAsmLanguage, and some others. I would like to return my own scanning rules in addition to the AsmCodeScanner. I have tried to provides my own ILanguageUI adapter as well, and it is somewhat more involved than providing a scanner adapter for IAsmLanguage.

 

If having a scanner adapter for IAsmLanguage is not the right thing to do, then I’ll switch back ILanguageUI.

 

Thanks,

Patrick

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Leherbauer, Anton (Toni)
Sent: Monday, April 11, 2011 2:45 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Assembly language keywords and directives

 

You can have your assembly language implement IAsmLanguage and return your custom set of keywords or make it adaptable to ILanguageUI to provide your own code scanner. I don’t see a reason why there should be another way to provide your own scanner.

 

Regards,

Toni

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Chuong, Patrick
Sent: Friday, April 08, 2011 17:24
To: CDT General developers list.
Subject: Re: [cdt-dev] Assembly language keywords and directives

 

Within the AsmSourceViewerConfiguration#getCodeScanner, if we make the language adaptable to RuleBaseScanner, than it should be possible to provide your own code scanner.

 

Is this something acceptable? I can file a bug and provide the patch. The change is only a few lines of code.

 

Regards,

Patrick

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Chuong, Patrick
Sent: Friday, April 08, 2011 10:59 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Assembly language keywords and directives

 

HI Aaron,

 

We also have the same issue, multiple families for one debugger. One way to handle this is to have an assembly language defined for each family, you can associate a specific language to the project. This can be done during project creation. The only thing you will need to do is to provide your own asm scanner for each assembly language. I am looking in the case where I want to extend the standard CDT assembly scanner to provide my additional set of token highlight (keywords/directives, etc…). I think this is what you need as well.

 

Regards,

Patrick

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Aaron Spear
Sent: Friday, April 08, 2011 10:47 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Assembly language keywords and directives

 

This brings up a possibly more general issue of how people are managing the assembly editor.  I know that at Mentor we had a single debugger that could target multiple families (ARM, PowerPC, MIPS, …) and the fact that there was not a flexible mechanism for choosing which assembly was in use was problematic (we ended up creating our own assembly editor).  I think that ideally there should be any number of named sets of the keywords/directives (extension point?), and which one is used by the editor in any given file is an attribute possibly inherited from the containing project, or something like that. 

 

As multi-core becomes more prevalent, being able to mix different families would be key.

 

Cheers,

Aaron Spear, VMware

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Chuong, Patrick
Sent: Friday, April 08, 2011 8:06 AM
To: CDT General developers list.
Subject: [cdt-dev] Assembly language keywords and directives

 

Hi,

 

Our compiler supports additional assembly keywords and directives, is it possible to add additional keywords and directives to the existing set for assembly editor? I am looking at the code and couldn’t find a way to do so. Do I need to make my language adaptable to ILanguageUI and duplicate assembly language code scanner provided by CDT?

 

Thanks,

Patrick


Back to the top