Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] How to extend the C99 / GCC LR Parser

Hi Sebastian

I used #pragma instead of IAR extended keywords everywhere. I failed to find the way of configuration of existing CDT parsers so they understand IAR extended keywords and writing Eclipse plugin is not the thing I am good at.

I believe using #pragma is better way - it is standard but using extended keywords is deviation from standard.

Regards,
Alexey

On Mon, Jul 11, 2011 at 14:28, Sebastian Wagner <se.wagner@xxxxxx> wrote:
Hi Alexey,

indeed I'm workin on a plugin to integrate the IAR C compiler. It does not cover the complete functionality, I needed to focus on the functionality and options we need here. But now it basicly provides me the functionality I need and I want to fix the parsing issues.

You are right, that I could use the #pragma instead - did you do it in your projects or does your plugin support the @? I would rather spend some time to support the @ than telling the developers they must replace the @ everywhere.

regards,
Sebastian

Von: "Alexey Mikoyan" <ami@xxxxxxxxx>
Gesendet: Jul 11, 2011 1:07:04 PM

An: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Betreff: Re: [cdt-dev] How to extend the C99 / GCC LR Parser

Hi Sebastian,
 
Are you interested in integration of you compiler with Eclipse or in writing new plug-in for Eclipse?
 
If the answer is "integration" than what compiler are you using?
 
I successfully integrated IAR C/C++ compiler with Eclipse so if this is the purpose I can help you.
 
In general try to use #pragma instead of extended keywords. IAR provides the alternative for keywords (like __regvar, __no_init, @) through using proper #pragma. Might be you compiler also support this way.
 
Regards,
Alexey Mikoyan

On Mon, Jul 11, 2011 at 14:02, Sebastian Wagner <se.wagner@xxxxxx> wrote:
Hi Markus and Mike,

I understood that I could make a request to extend the internal parser to support this type of variable definitions.
Of course I don't have a very good overview, but my feeling is that the LR parser is a bit more flexible. Is it correct that I could implement the extension for this variable definition without waiting for a fix of the CDT core when I use the LR parser?

Mike, could you give me just the basic steps how you would implement the extension using the LR parser to just accept the @ <address> after a variable definition? Which functions/ modules do I need to modify?


Thanks in advance


Sebastian




-----Ursprüngliche Nachricht-----
Von: "Schorn, Markus" <Markus.Schorn@xxxxxxxxxxxxx>
Gesendet: Jul 11, 2011 11:01:54 AM
 
An: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Betreff: Re: [cdt-dev] How to extend the C99 / GCC LR Parser

>Hi Sebastian,
>You need an additional parser extension, you can ask for it via bugzilla. Please add a specification of the extension, ideally you can point to a document in the Web.
>We have added support for similar custom extensions in the past, see ICParserExtensionConfiguration.
>Markus.
>
>-----Original Message-----
>From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sebastian Wagner
>Sent: Monday, July 11, 2011 10:43
>To: CDT General developers list.
>Subject: Re: [cdt-dev] How to extend the C99 / GCC LR Parser
>Importance: Low
>
>Hi Markus,
>
>first thanks for your proposal. Your are right,  I also have the feeling that in my case this would be much easier, even if I also would like to understand the parsers a bit better.
>
>In implementation I simply added macros to replace the new keywords by an empty space. This worked so far and was not perfect but acceptable. My problem is the following extension to the variable definitions, which is used for register defintions in the microcontroller and sometimes for variables :
>
>volatile short int PORT_A @ 0x0100;
>
>While it is simple to replace fixed keywords I didn't know how to manage the @ and the memory address after the definition. Do you have any idea how I could solve this?
>
>
>best regards
>
>Sebastian
>
>
>-----Ursprüngliche Nachricht-----
>Von: "Schorn, Markus" <Markus.Schorn@xxxxxxxxxxxxx>
>Gesendet: Jul 8, 2011 8:22:15 AM
>An: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
>Betreff: Re: [cdt-dev] How to extend the C99 / GCC LR Parser
>
>>Hi Sebastian,
>>While extending the parser is a valid option, it will be much easier, if you manage to configure the existing parser.
>>Clearly, it is not possible to handle every language extension in that way, but it may work in your case.
>>For instance, depending on what __data16 does, I would try to map it to either 'short' or to the empty token.
>>
>>To configure the existing parser you need to subclass GCCLanguage and provide a customized IScannerExtensionConfiguration and/or ICParserExtensionConfiguration.
>>
>>Markus.
>>
>>-----Original Message-----
>>From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
>>On Behalf Of Sebastian Wagner
>>Sent: Thursday, July 07, 2011 17:11
>>To: cdt-dev@xxxxxxxxxxx
>>Subject: [cdt-dev] How to extend the C99 / GCC LR Parser
>>Importance: Low
>>
>>Hello all,
>>
>>I am working on a parser for a C based language which contains some small extensions, e.g. special type qualifiers. Therefore I would like to extend the C99 or GCC LR Parser.
>>
>>I read a lot of content in the web and CDT source code. I managed to generate the Parser from the grammar file and I'm able to compile the generated files. I also understood that today the lexer is not generated using the LPG, but is a part of the preprocessor.
>>
>>Now, nevertheless I didn't get the complete overview where I need to do changes if for instance I want to add a new type qualifier "__data16". Do I have to do modifications on the preprocessor and do I do that? I think keywords can be added using the ScannerExtensionConfiguration, but I don't know how to do this correctly. Do I also need to do adaptations to the AST?
>>
>>It would be great if one of you could give me a short overview in which modules I need to do modifications, so that I understand the behavior better.
>>
>>Thanks in advance!!
>>
>>
>>Sebastian Wagner
>>
>>___________________________________________________________
>>Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar
>>eingebaut! http://produkte.web.de/go/toolbar
>>_______________________________________________
>>cdt-dev mailing list
>>cdt-dev@xxxxxxxxxxx
>>https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>_______________________________________________
>>cdt-dev mailing list
>>cdt-dev@xxxxxxxxxxx
>>https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
>___________________________________________________________
>Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar _______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/cdt-dev
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/cdt-dev


___________________________________________________________
Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
  

Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die   
Toolbar eingebaut! http://produkte.web.de/go/toolbar

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev



Back to the top