This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Extending Gcc For a New Language
- From: Kevin Atkinson <kevina at gnu dot org>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 05 Mar 2003 20:21:45 -0500 (EST)
- Subject: Re: Extending Gcc For a New Language
On Wed, 5 Mar 2003, Kevin Atkinson wrote:
Oops. I forgot the question.
> For my Ph D I am seriously considering designing a new System Program
> language. Unlike many other new languages, my new language will be
> designed to be suitable for low-level programming tasks such as written
> kernels and operating systems, It is designed to replace C and C++
> (wishful thinking I know).
>
> For the implementation I am considering two choices
>
> 1) Writing the compiler in its own language that emits C (or perhaps
> C++) code and then uses gcc to compile it.
>
> 2) Extending Gcc to support the new language.
>
> Because my language will offer features not currently supported by C or
> C++ (and probably Java, Ada, and Fortune but I don't know enough about
> those languages to be sure), it will me more than simply writing a new
> front end.
I would like to know what would be involved in extending Gcc to support
the features, or if it is even possible to do so without a rewrite of a
significant part of gcc.
> Some of the features the language may offer:
>
> * Type inference in the style of most functional programming languages, but
> perhaps a bit more limited. Generally global variables and function
> parameters will have the types specified, but the compiler will be
> expected to infer the types for local variables.
>
> * No user written header files, instead the compiler will emit the
> necessary information. When no optimizations are used it will only emit
> function phototypes and the like. When using optimization it will emit
> more such as function definitions for functions which are good inlining
> candidates.
>
> * An optional garbage collector. When active the collector will only be
> used for some objects, AND the user will be allowed to free objects
> explicitly. (I know has support for garbage collection but I don't know
> how powerful it is and if it can handle objects being freed by the user)
>
> * Very precise typing of objects. Types can be limited by arbitrary
> boolean expressions such as limiting an integer to a particular range. If
> the compiler can not verify the conditions at compile time it is expected
> to be able to optionally emit code to check for it at runtime.
>
> I think that should cover it for now. I will be about a year before I
> give any serious thought into my new language. So don't expect to much
> specific information.
>
>
--
http://kevin.atkinson.dhs.org