LX Compiler Status

Christophe de Dinechin
Version 1.4 (updated 2001/10/25 17:54:06)

Overview

There is an LX compiler today. It is integrated in the Mozart distribution. I recommend getting the latest source from CVS (either directly using CVS or by accessing the nightly-generated CVS tar balls.) If you don't know how to access projects hosted on SourceForge, please read the SourceForge documentation. From a Unix system, you would typically issue the following:

export CVS_RSH=ssh
export CVS_ROOT=:pserver:anonymous@cvs.mozart-dev.sourceforge.net:/cvsroot/mozart-dev
cvs -z9 checkout mozart

There will be a lx directory in the Mozart source tree, and that's where the compiler lives. To compile it, you need to link Makefile.config.platform to Makefile.config at the top-level, and type make. If there is no Makefile.config for your platform, feel free to create one, add required information in the configuration.h file, and submit a patch.

The compiler currently can compile simple programs (hello world, factorials, this kind of things...) It's biggest drawback at the time is that it doesn't do object layout, so you can't generate correct code for programs with records or objects.

Which platforms are supported?

Mozart and LX are currently being developed on MacOS X, which is probably the best supported platforms. Every week or so, I test the builds on Linux, which is therefore the second best supported platform (this include a 64-bit variant of Linux.) The compiler being used is GCC in both cases. The LX compiler generates C code that is also being tested with GCC.

Other platforms have been tested with various degrees of success. A while back, Attila Lendvai contributed a port to BeOS. Bernard Hurley and Ingo Bruss contributed a Windows port using CygWin. Solaris used to work, but has not been tested in a very long time. HP-UX works as long as you use gcc and not the HP ANSI C++ compiler (aCC), which has a bug preventing it from compiling the "perform" macro correctly (I filed a bug report, and hopefully this will be fixed soon.)

Syntax

LX uses a recursive descent parser (not a yacc-based parser), which is complete as far as I can tell. A couple of things may change for which I am still a bit undecided:

• Whether LX will support a 'finally' clause in try/catch blocks. While finally is useful, I've been told that it also causes a serious problem to optimizers because of the many additional control flow arcs it adds.
• Whether LX will support multiple spellings for keywords such as return/returns, other/others, const/constant, etc. My current preference is to support them.
• What the notation for based numbers is. It is currently 16#FFFF_124E. An alternative could be 16'FFFF_124E. Both cause problem with the standard C preprocessor, which is a bit annoying.
• How to parse F(0) := 1. This currently result in an error (you have to write (F(0)) := 1.) This is because procedure calls in LX don't take parentheses, so F(0) is seen as a procedure call with a first parenthesized argument. F(0,1) would be rejected.

Semantics

Many things now work almost correctly:

• Symbol lookup (finding what 'N' means in a given context)
• Import (importing global entities from other files)
• Using statements (makeing a reference to a X in X.Y implicit)
• Type checking (finding whether two objects have the same type)
• Function overloading (allowing f(1) and f(1,2))
• Expression reduction (transforming A+B into a function call or generic type.)
• User-defined implicit conversions (knowing when to convert 1 to a real)
• Variable argument-size functions (WriteLn-style using the other keyword, not the type-unsafe printf style)
• Basic generic instantiation, that is the possibility to create pointer[integer] from pointer[T].
• Pragmas, which in LX are indications to the compiler to invoke an external or internal plug-in (currently, there are only internal plug-ins)

The rest doesn't work. This includes the following big items:

• Object layout, which is required for correct code generation of any code containing record or object instances. When this is achieved, you will already be able to do more with LX than with C (assuming there is a library :-)
• Constructors and destructors are not invoked automatically. Explicit invokations are fine.
• Assertions, preconditions, postconditions are ignored.
• Exceptions are not supported
• Generic specializations (special-casing pointer[integer])
• Variant types (the LX powerful equivalent of C union types, which might get implemented as part of object layout.)
• Child modules (the possibility to extend a module from within, which is quite necessary if I want the LX standard library to have its final, non-flat structure.)
• Specification and bodies (that is, the possibility for a second declaration to be recognized as identical to a previous, specification-only declaration)
• Separate template instantiation and inlining, the possibility to define the body of a template or inline function in a body file rather than in a specification file.
• Multi-file binding, which is most likely required for separate template instantiation and for reasonably efficient code generation on unknown types.

Code generation

The LX compiler currently generates C code (you can see the output using the -C option), or a pseudo assembly (with the -S option). I am not outputting real assembly at that stage because I don't want to go into the "back-end" business (register allocation, data flow analysis, optimizations). At least not until the front-end part is complete.

The C code being emitted looks ugly, but this is by design. Operations are decomposed to the extreme, as they would be with a real assembly language.

Library

The LX library is almost totally empty at that stage. The only things in there for now is a very simplified LX_BUILTINS module containing declarations for integer/real arithmetic, comparison, etc. There is no real I/O (although you can connect to C I/O routines). Some basic elements of the existing library don't even have their final form because of lack of support in key areas such as generic specializations.

Tips for debugging the compiler

While you are debugging (assuming you use GDB), you can print the value of a String S using print pstring(S), the value of a code tree (Coda * or derived, including LXSymboLTable) using print lxtree(S), and the value of a LXGenericMap * using print lxgenmap(map) (beware, you most often need to take the address of a map in the compiler.)