Developers

Currently, development of GLBCC is taking place via the SourceForge project page .

There is a developer mailing list for discussing bugs and for planning the future of GLBCC.  The archives of the list can be viewed here and you can subscribe to the list here.  Please do not ask questions on the list until you have read all the Frequently Asked Questions on the documentation page .

Anyone interesting in obtaining the latest and greatest version of GLBCC, can accessing the current development code via CVS.  To access the CVS archive, you can use the following command on any Unix system:

  cvs -d:pserver:anonymous@cvs.lbpp.sourceforge.net:/cvsroot/lbpp login
  cvs -z3 -d:pserver:anonymous@cvs.lbpp.sourceforge.net:/cvsroot/lbpp co glbcc

There are many Windows CVS clients available too.  I have used WinCVS in the past but there should be a great number of programs available at any software site (Tucows, download.com, etc.).

You can view the CVS archive interactively online here .

The only guarentee made with code from CVS is that it will (most likely) compile.  Otherwise, your on your own.

Development Status

Currently, development around GLBCC stems on builing a GCC front end for Liberty Basic. This will solve so many of the problems that were faced in the previous version. The other benefit of this is that it sheds the dependency on a C compiler forever which is a very good thing.

What follows is a quick overview of how this is all going to work. I've included a bunch of good links on the links page to give the reader the oppertunity to explore in more detail the concepts presented here.

GCC Overview

The goal of GCC was to create a compiler suite that could support as many languages targetted to as many platforms as possible. It has indeed done this as it is by far, the most portable and extendable compiler in existance.

GCC achieves platform independence by creating an assembly language that has common concepts found in all higher level languages - common math operators, function calls, functions, etc. . This language is called RTL. RTL is a stack based assembly language so it also avoids all the complication of registry allocation. A GCC front-end reads in a source file from a high level language, and then performs almost a one-to-one translation of that language into RTL. GCC, in fact, accepts the RTL in the form of a tree to make it even easier for the front end. As if that wasn't easy enough, GCC also provides all the function calls neccessary to create all the RTL nodes so the front-end developer merely needs to call a few functions.

Where GLBCC Currently Stands

I have completed a grammar for LB and built a syntax tree for it. What this means is that I am currently at a point where all I have to do is transverse a tree and call the corresponding functions in the GCC back-end to generate an RTL tree. Before this though, I want to perform some checking on the tree in order to make sure that variables are of the right type and such things.

I've also made a quick proof of concept program that dumps the LB syntax tree to standard output in XML format. This program is available in the CVS repository under the glbc module. You can download either a Linux binary or a Windows binary. To use it, you must pipe a file through it and specify the -x option on the command line. On Linux, this will look something like this:

[anthony@lbpp.sourceforge.net $] cat filename.bas | ./glbc -x > filename.xml

On Windows, it will look something like this:

C:\> cat filename.bas | glbc.exe -x > filename.xml

You can go directly to the glbc repository to download the programs by clicking here.

---