![]() |
![]() |
![]() |
![]() |
12 HLA Internal Operation
To effectively use HLA, it helps to understand how HLA translates HLA source files into executable machine code. This information is particularly useful if you install HLA incorrectly and you cannot successfully compile a simple demo program. Beyond that, this information can also help you take advantage of more advanced HLA and OS features.
As noted earlier in this document, HLA is not a single application; the HLA system is a collection of programs that work together to translate your HLA source files into executable files. This is not unusual, most compilers and assemblers provide only part of the conversion from source to executable (e.g., you still have to run a linker with most compilers and assemblers to produce an executable).
The HLA system offers a rich set of different configurations that allow you to mix and match components to efficiently process your assembly language applications. First of all, HLA is relatively portable. The compiler itself is written with Flex, Bison, C/C++, along with some platform-independent assembly language code (written in HLA, of course). This makes it fairly easy to move the compiler from one operating system to another. Currently, HLA is supported under Windows and Linux. A couple of different FreeBSD ports have been done (though official support for FreeBSD must wait until the HLA standard library gets ported to FreeBSD). Plans include porting HLA to MacOS (Intel Macintoshes) at some point in the future. Even within a single operating system, HLA offers multiple configurations that you can employ, based on your needs and desires. This section will describes some of the possible configurations you might create.
The compilation of a typical HLA source file using a command line such as "hla hw" goes through three or four major phases:
- The HLA.EXE (Windows) or hla (other OSes) program processes command-line parameters and acts as a "traffic cop" directing the execution of the remaining components of the HLA system.
- The HLAPARSE.EXE (Windows) or hlaparse (other OSes) program is responsible for translating the HLA source file into either an object file or into the syntax of some other assembler. Usually, the HLAPARSE program is run automatically by some other program such as HLA.EXE/hla or HIDE (the HLA Integrated Development Environment). You would not normally run HLAPARSE directly from a command-line (though it is certainly possible to do this if you are so inclined).
- If you elect to have HLA produce an assembly language output file rather than an object module, then the next step towards producing an executable file is to run the associated assembler on the source output that HLA produced. This step isn't strictly necessary because HLA can produce an object file directly without using some external assembler, but there are some (rather esoteric) reasons why you might want to go through some other assembler rather than having HLA directly produce the object file. Generally, the HLA.EXE (hla) program will automatically run the assembler for you.
- The last step is to run a linker to combine the object module the previous steps created with the HLA Standard Library and any other necessary object modules for the project. The output of the linkage step is an executable file (assuming, of course, there were no errors in the compilation of your program). Generally, the HLA.EXE (hla) program will automatically run the linker for you.
There is a fifth, optional, step that can also take place under Windows. If you are creating an application that makes use of compiled resources, as the fourth step (before the linking stage) the HLA.EXE (Windows only) program can run a resource compiler to translate those resources into an object module (.res) that the linker can link into your final executable.
As it turns out, the HLA system can employ a wide variety of linkers, librarians, assemblers, and other tools based on the underlying operating system. Here is the list of tools that HLA has been qualified with:
- Microsoft's MASM assembler
- Microsoft's linker
- Microsoft's resource compiler
- Microsofts LIB library manager
- The Flat Assembler (FASM)
- Pelles C POLINK linker
- Pelles C POLIB library manager
- Pelles C PORC resource compiler
- Borland's Turbo Assembler
Note: you can use Borland's TLINK and TLIB utilities with HLA, but you will have to manually run these applications; the HLA system will not automatically execute them.
A couple of obvious questions that might come up: "Why provide all these options? Why not simply pick a single configuration and go with that?" Well, as it turns out, there are advantages and disadvantages to each configuration and allowing multiple configurations affords you the most flexibility when writing code.
12.1 Standard Configurations Under Windows
The "standard" HLA configuration under Windows consists of HLA.EXE, HLAPARSE.EXE, PORC.EXE, and POLINK.EXE. This standard configuration generates object files directly, compiles any resource files using the Pelles C PORC.EXE resource compiler, and links the object modules together using the Pelles C linker (POLINK). The Pelles C tools were chosen for the standard configuration under Windows because they are freely distributable (unlike the Microsoft tools). For those who care about such things, HLAPARSE.EXE produces object modules directly using components built from the Flat Assembler (FASM), so you know you're getting the optimal output code that FASM produces (generally, the code quality is a little bit better than MASM or TASM).
So why would anyone want to have HLA produce assembly language output to be run through a different assembler (much like GCC does)? For common applications, there is no need to do this. However, in some specialized situations having this facility is quite useful. For example, rather than using an internal version of FASM as HLA's back-end native code generator, you may elect to have HLA generate FASM source code to be processed by the FASM assembler. There are three reasons for doing this:
- You want to see how HLA would translate the HLA program (in HLA syntax) to a lower-level assembly language (in FASM syntax); this is great, for example, for seeing how macros expand or how HLA processes high-level control constructs.
- Because the internal version of FASM that HLA uses has to coexist in memory with HLA, the amount of memory allocated to this internal FASM is much less than is available to a standalone version of FASM. Therefore, it is possible that some very large projects will not compile using the internal version of FASM but will compile if you produce a FASM source file and run the external version of FASM on it.
- If there is a defect in the internal version of FASM that prevents HLA from directly generating an object code file, you can probably produce a source file and successfully compile your program using the external version of FASM (the internal version was a rewrite of the FASM assembler, so the fact that it contains a defect does not suggest that the external version contains the same defect).
Another configuration is to have HLA produce a MASM compatible output file and use Microsoft's MASM to translate that output source file into an object file. There are several reasons why you might want to use MASM:
- MASM can inject symbolic debugging information (usable by OllyDbg or Visual Studio's debugger) into the object file, making it easier to debug HLA applications.
- FASM (internal or external) may have some code generation defect that you can't work around.
- FASM's output might not be completely compatible with some other object module tool you're using.
- You want to take HLA output and merge it with some MASM projects you've got.
Although MASM is not a freely distributable program (and, therefore, is not included in the HLA download), you may download a copy for free from the Microsoft Web site or obtain a copy as part of the MASM32 package.
One last assembler choice under Windows is Borland's Turbo Assembler (TASM). There is one main reason why you would want to use TASM to process HLA output - you want to link HLA output with a Borland Delphi project. Delphi is very particular about the object files it will link against. Effectively, you can only use TASM-generated output files when linking with Delphi code. Therefore, if you want to link your HLA modules into a Delphi application, you'll need to use the TASM output mode. Like MASM, TASM is not a freely distributable product and cannot be included as part of the HLA download. However, Borland will provide a free copy as part of their free C++ download on their website (registration required).
Under Windows, you may use either the freely distributable Pelle's C linker (Polink) or the Microsoft linker to process the object code output from the HLA system. Polink is provided with the HLA download (subject, of course, to the Pelles C license agreement). Microsoft's linker is a commercial product (and as such, it is not included as part of the HLA download), but it is available as a free download from Microsoft's web site and as part of the MASM32 package. HLA will use either linker as the final stage in producing an executable. The Microsoft linker has been around longer and has, arguably, fewer bugs than Polink, but the choice is your's. Another possible linker option is the Borland Turbo linker (TLINK). Just note that HLA.EXE will not automatically run TLINK; you will have to run it manually after producing an OMF object file with HLA. Also note that only MASM and TASM are capable of producing OMF files. FASM and HLA's internal code generator do not generate OMF object code files, so you cannot use TLINK with their output.
To produce libraries, you may optionally employ a librarian such as Microsoft's LIB.EXE, the Pelle's C POLIB.EXE, or Borland's Turbo Librarian (TLIB.EXE). The HLA.EXE program does not automatically run these programs; you will have to run them manually to create a .LIB file from your object files. Please see the documentation for these products for details on their use. The HLA download includes the POLIB.EXE program and the HLA standard library source code includes a make file option that will use any of these three librarians to produce the HLA hlalib.lib library file.
Note that it is possible to mix and match modules in the HLA system, within certain reasonable limitations. For example, you could use the FASM assembler and the Microsoft linker, the TASM assembler and the POLINK linker, or even the MASM assembler the TLINK linker. In general, FASM output works fine with the Microsoft linker and librarian or the Pelle's C linker and librarian, MASM output works best with Microsoft's linker and librarian, and Turbo assembler works best with the Borland tools or the Microsoft tools.
Under Windows, the default configuration is to generate an MSCOFF object file directly and use the POLINK linker to process the resulting object file(s). See the section on "Customizing HLA" for details on changing the default configuration.
12.2 Standard Configurations Under Linux
Under Linux, HLA supports fewer configurations than under Windows but this is primarily because the main tools available for Linux are all freely distributable and there is no need to support commercial tools. There are three different ways to generate object code files and only one linker and one librarian option available under Linux. There is no resource compiler (that HLA would automatically use).
HLA can generate object files in one of three different ways under Linux:
- The hlaparse program can directly generate an object (.o) file in the ELF form (executable/linkable format).
- The hlaparse program can generate a FASM-compatible source file that can be further processed by the Linux version of the FASM assembler to produce an ELF file.
- The hlaparse program can generate a Gas-compatible source file (using the .intel_syntax mode) that the FSF Gas assembler can convert to an ELF file.
Under Linux you don't get a choice of linkers. Everyone uses the FSF/GNU ld (load) program as the standard system linker. The HLA package also uses ld. In a similar vein, your only librarian choice is the FSF/GNU ar (archive) program. These tools work great and they're freely distributable, so they're the perfect back ends to the HLA system.
The HLA download for Linux includes the FASM assembler but it does not include Gas (as), ld, or ar. These are standard GNU tools that ship with nearly every version of Linux, so there is no need to duplicate that code in the HLA package. Note that you must be using a 32-bit version of Gas, version 2.10 or later (64-bit versions may not work automatically with HLA).
Under Linux, the default HLA configuration generates a Gas compatible assembly language file and then runs Gas to produce an ELF object code file. If you would prefer to produce FASM output and use the FASM assembler, or generate ELF output directly using the internal version of FASM, then see the section on "Customizing HLA" for more details.
12.3 Non-Standard Configurations Under Windows and Linux
It is possible, though uncommon, to use HLA in ways that aren't 100% compatible with the underlying operating system. For example, under Windows you can use HLA to produce a Gas-compatible assembly language source file. Likewise, you can use HLA under Linux to produce a MASM or TASM compatible assembly language source file. However, note that when HLA produces a Gas file, it includes certain start-up code that is only appropriate for Linux; this is true even if you do this under Windows. Similarly, producing a MASM or TASM source file includes start-up code that is only appropriate for Windows, even if the file is produced under Linux. So even if it were possible to run these products under the "wrong" operating system (e.g., MASM under Linux), the resulting object files would not be in a format acceptable to the OS and the code emitted by the HLA compiler wouldn't run properly. Nevertheless, if you just want to view the assembly language file that HLA produces, it doesn't really matter what operating system you're running under, so you may as well pick an output format that you are most confortable with.
![]() |
![]() |
![]() |
![]() |
![]() |