History

History. In 2004, I had the idea of creating an embeddable version XPL0 that could be inserted into any program to give users a macro language to automate program-specific tasks. For example, it could be inserted into Xedit to give it a more powerful and easier-to-use tool for manipulating text.

When I finished the compiler in 2004, I ran out of time and the project languished for eight years. I finally had some spare time more recently and decided to finish it. The result is quite interesting and different than the standard XPL0 distributions.

1. How It Was Written. Since the initial version didn't need to be blazingly fast, I chose to implement an interpreter. To allow the maximum flexibility, I wrote  everything in Pascal, which would allow it to be targeted to DOS, Windows, Linux or the Mac. Since the interpreter itself was written in Pascal, and not assembly language, it is several times slower than the original I2L version, and much slower than the native versions. However, it does have sophisticated and powerful new intrinsics that, in many instances, make up for the slowness of the language itself.

2. Optimization. Up to this point, I've done no optimizing, preferring instead to work out all the features needed to make it more device-independent and functional. There are lots of possible optimizations, from rewriting parts of the interpreter loop in assembly language, to generating native code. For more information on optimization options refer to the Future Plans section.

3. Compatibility. To test the language, I started by trying to run old XPL programs. Unfortunately, all but the simplest programs had dependencies that required many of the features of a standard VGA display under a DOS machine. To solve that problem, I designed a console simulation that duplicates all the features of the standard DOS window, including 61 standard CGA, EGA, VGA and VESA video modes.

However, as I moved on to ever more complicated programs, the code became ever more dependent on BIOS, DOS, VESA and accessing actual hardware registers. I thought about trying to simulate every hardware aspect of a DOS machine, but it seemed like a large and futile project, and philosophically wrong. Instead, I decided the correct solution would be to design a set of additional, general-purpose and portable intrinsics to provide the needed functionality. The idea was to design intrinsics that were completely device-independent, so their use and meaning wouldn't have to change if EXPL was moved to a different computer.

4. Loren's Programs. Loren's extensive library of graphics programs and games became the testing ground for the new version of EXPL. I gradually worked my way through Loren's programs, adding intrinsics as necessary to perform the tasks Loren had performed using DOS calls, BIOS calls and VGA register manipulation.

The result was quite interesting. While this version is relatively slow, I was able to run most of Loren's programs at reasonable speed because of the speed and efficiency of the new intrinsics.

5. The IDE. Since developing this version of EXPL required a lot of debugging, I needed tools that would make the process as easy as possible. To that end, I created an IDE that integrates Xedit, a VGA console, the compiler, loader and interpreter into one package.

6. Debugging Tools. Once the compiler and interpreter were integrated into the IDE, it was a relatively simple matter to add debugging tools. The compiler now provides all the information needed to translate between the source code and the runtime code. This enables the debugger to locate variables and display their values, single step and set breakpoints in the interpreter. All the debugging tools fall out of this simple idea.