Re: [cdt-dev] Extending the C language recognized by the parser

[kesselhaus@xxxxxxx]

> I would just try to work around it by adding a macro to your project so 
> along the lines of 
> 
> #define __at(x) 
> 
> so that it would just get skipped over by the parser. 

Yes, but it would add another file/whatever into the actual code.
I might do it in the Compiler-switch too.

> Enabling a full variant/target model will require significant systemic 
> change in CDT that we have not committed to doing in CDT 3.0. 

Well, thats why I ask to consider this at the beginning, not having to do
redesign/rework later. The GCC language extensions should be removed from
the cdt-core anyway and moved some place else (like a GCC-toolchain plugin).

> JohnC
> www.eclipse.org/cdt
> 
> cdt-dev-admin@xxxxxxxxxxx wrote on 02/15/2005 04:59:28 PM:
> 
> > > Your question is definitely outside of the scope of the Managed Build
> > > System.  I've given it a different "subject" that may get a response.
> > 
> > Well, the proposal also declared a change of the whole toolchain per
> > project. I think there should also be some kind of change of the
> > indexer/parser per toolchain. The main problem I currently encounter is
> > C-language extensions, GCC does not know of or expects it in different
> > matter. Using the TASKING C-compiler, there are extensions like __at() 
> which
> > also can provide information and/or need information from the toolchain.
> > 
> > * __at(0xC000000) for example puts a variable/structure at a certain 
> place
> > in memory. The toolchain needs to setup the sections anyway, though one 
> can
> > check, if this memory exists anyway and require the developer to think 
> about
> > its declaration if this memory area is missing in the linker script.
> > But GCC can't handle this, and currently GCC language is 
> hardcoded/included
> > in the main core/parser plugin. Maybe a toolchain could also 
> automatically
> > can create linker sections if it encounters #pragmas e.g. for locating
> > specific sections in Code-RAM instead of default ROM/FLASH, with
> > automatically enabling startup assembler fragments.
> > 
> > * Another example is the __asm() in TASKING, which seems to be a little
> > different than GCC, at least the indexer is complaining about it in my 
> code.
> > Also a toolcain can introduce a new ASM-dialect in the ASM-editor, if it
> > handles multiple processor/controller types.
> > 
> > * Also a toolchain could add/remove intrinsic functions to the indexer 
> on
> > project basis and the current project toolchain selection.
> > 
> > * pragmas are something really toolchain specific feature and should be
> > enabled/disabled by the current toolchain.
> > 
> > But in all three examples, no toolchain-specific extension to C-language
> > extension should interfere with other toolchains, when switching, 
> meaning
> > that if one toolchain doesn't know of an extension, it should mark it as
> > wrong, but the other toolchain not.
> > 
> > 
> > 
> > > Leo
> > > 
> > > -----Original Message-----
> > > From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On
> > > Behalf Of kesselhaus@xxxxxxx
> > > Sent: Friday, February 11, 2005 7:46 AM
> > > To: cdt-dev@xxxxxxxxxxx
> > > Subject: RE: [cdt-dev] MBS Plan items for CDT 3.0 (proposed)
> > > 
> > > Is the C-language extension out of this scope?
> > > I mean, if compiler understand some Non-ANSI-C extensions, like
> > > __at(...)
> > > and the like, though, Parser and Indexer don't yell on such 
> statements,
> > > because one toolchain supports this and the other something else.
> > > 
> > > > Here are the MBS proposed tasks in the requested format. The 
> bugzilla
> > > > entry number will change as we complete individual designs.
> > > > 
> > > ...
> > > > 
> > > > _______________________________________________
> > > > cdt-dev mailing list
> > > > cdt-dev@xxxxxxxxxxx
> > > > http://dev.eclipse.org/mailman/listinfo/cdt-dev
> > > > 
> > > 
> > > -- 
> > > Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS
> > > GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail
> > > _______________________________________________
> > > cdt-dev mailing list
> > > cdt-dev@xxxxxxxxxxx
> > > http://dev.eclipse.org/mailman/listinfo/cdt-dev
> > > _______________________________________________
> > > cdt-dev mailing list
> > > cdt-dev@xxxxxxxxxxx
> > > http://dev.eclipse.org/mailman/listinfo/cdt-dev
> > > 
> > 
> > -- 
> > DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen!
> > AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/cdt-dev
> 

-- 
Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS
GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail