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

[kesselhaus@xxxxxxx]

> 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