TOC PREV NEXT INDEX

Put your logo here!


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:

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:

Under Windows:

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.

Under Linux:

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:

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:

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:

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.



TOC PREV NEXT INDEX