Source code has been shipped with the HLA releases since HLA v1.18. However, until Bison 1.875 became available, compiling HLA required a special, hacked, version of Bison that ran under Linux. This made development of HLA (particularly under Linux) a bit painful. Fortunately, as of Bison 1.875, it is now possible to compile the HLA source code using standard versions of Flex and Bison available from the Free Software Foundation (the GNU folks). You must, however, have Bison 1.875 or later to successfully translate the HLAPARSE.BSN file. Under Windows, the CYGWIN package containing Flex and Bison works great. I (Randy Hyde) have never actually built HLAPARSE.BSN under Linux, so I don't have any experience with this process. It may be trivial, it may be impossible. I've never tried it. I always generate HLAPARSE.C under Windows using Bison and then I copy the C file over to Linux for compilation there.
First, a couple of comments about the source code: HLA v1.x is a prototype system. This means that there are massive kludges in the code. The whole system evolved over time rather than being designed properly in the first place (no apologies for this, that's the whole purpose of a prototype). So if you looking for wonderfully structured code that's easy to follow, HLA will disappoint you. I learned quite a bit about FLEX and BISON while writing HLA and, unfortunately, it shows. There are many ways I've done things that someone who was more familiar with FLEX/Bison would have done differently (heck, there are a lot of things I would do differently, in hindsight). None of this is worth fixing since such work is better put to writing v2.x of HLA.
The HLA source code is almost 120,000 lines long. The Bison file alone is over 75,000 lines of code. Messing with HLA source code is not an undertaking for the weak of heart. Although much of the code is commented, there is very little "high level documentation" (i.e., design documentation) available that would explain why I've done certain things or to provide the general philosophy behind the code. I offer the source code in this form; it is up to you to decide whether you want to spend the time needed to figure it all out.
One note about support: I will be more than happy to answer questions about HLA in the comp.lang.asm.x86 or alt.lang.asm newsgroups. However, I do not have time to answer individual questions asked via email concerning the source code. I apologize ahead of time, but releasing a program of this magnitude to the public could wind up burying me with questions. Because of the possible volume of emails this product could produce, I must ignore all requests for help that arrive via email. Of course, bug reports are always welcome via email. Send everything else to one of the two aforementioned newsgroups.
I have developed HLA with the following tools:
CodeWright Editor (it takes a decent editor to handle files in excess of 100,000 lines of code).
Borland C++ v5.x (HLA generally sticks to straight C, though some C++ might have slipped in).
Bison (must be 1.875 or later)
HLA (one module is written in HLA itself).
I have supplied a makefile that should automatically build the HLA system for you. See the makefile in the main source directory for details. For Linux, there is a "makefile.linux" file that you should use.
In addition to the main makefile, the HLA source code includes several makefiles to construct things like the HLA Standard Library, the example files, the AoA_Software files (for the HLA version of "The Art of Assembly Language Programming"), and the HLA test suite.
HLA is probably not portable. I have made no attempt to ensure that the code compiles with anything other than Borland C++, GCC, and, occasionally, MSVC++, so undoubtedly it won't compile on anything else without some effort. I have eliminated *most* of the compiler warnings, so porting to some other compilers shouldn't be too difficult.
Porting HLA to generate assembly code for an assembler other than MASM is a major undertaking. TASM took a couple of weeks to pull off and TASM is mostly compatible with MASM. Gas took about a month of evenings and FASM took several weekends.
To modify HLA to generate NASM code should be fairly easy (syntax is similar to FASM). However, I'm not sure if NASM can handle the EQUs that HLA emits. Have to check into this at one point or another.
Porting to other operating systems (other than Windows and Linux) is certainly possible. The compiler should be fairly easy to port. The real work is in porting the Standard Library. I've looked into porting HLA to QNX, but haven't pursued this for a couple of reasons: (1) QNX's version of GCC is older and has problems compiling the source code, (2) QNX doesn't really support assembly level calls to the OS so I'd have to port the HLA standard library on top of the C standard library code (which is ugly). BSD should be easier, but I haven't looked at that at all. At one time I looked into a BeOS port, but then BeOS died, so I gave up.