This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Extending Gcc For a New Language
On Thursday 06 March 2003 01:49, Kevin Atkinson wrote:
> 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).
>
I did some of this for my Bachelor degree project. (I didnt finish the
compiler though, only the very basics of the language compile).
I called the language M (a factor greater than C, or a cross between ML and
C(++)). The object-oriented extention would then be called MOO (M
Object-Oriented) ;-)
> 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.
>
3) writing you own compiler. It's quite fun, and if using state-of-art
techniques as the foundation it's not hard to beat gcc in performance (for
RISC processors atleast, I wouldnt want to write an x86 compiler though).
> 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. 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.
>
Check, So do my language
> * 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.
>
Check. Uses export keyword to mark functions to be exported. You are also
supposed to be able to write binary interfaces (for ELF object-files), but
this is not implemented.
> * 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)
>
Check. I had the idea of language supprted arenaes(Memory Regions), you could
then decide if an arena was garbage collected or explicit memory managed. You
could even have a non-managed arena, and just free all the allocated memory
in one go, when freeing the arena.
> * 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.
>
Very interesting.
> 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.
If you want to discuss ideas, feel welcome to email me. I love language
design, and there are simply to many high-level languages out there. We
_need_ a better system-programming language if we want to escape C and C++.
`Allan