The Application Program Interface (API) for Linux services is C-based, as it is for all UNIX-like operating systems. This sets Linux apart from most other IBM mainframe operating systems such as OS/390 and VSE which have an assembler-based API. Programs that invoke operating system services are much easier to write in C than assembler for Linux, but easier to write in assembler than any other language for OS/390. For this reason, it is much less common for Linux programs to be written even partly in assembler than it is for OS/390 programs.
So, why is an assembler needed at all for Linux for S/390 and zSeries? The most common reason is to reuse existing assembler code when building Linux/390 programs or to build assembler programs that are portable to both Linux/390 and other mainframe operating systems. If existing assembler code is well structured, with the I/O and other operating system calls separated from the program logic, it can be relatively easy to port assembler code to Linux/390.
Linux is distributed with a rich set of tools. The most useful tool is the make utility, which can be used to drive the other development tools. Also included are compilers for many languages, an assembler and the linker. Most Linux compilers generate assembler code and invoke the GNU assembler, as. Unless the appropriate compiler switches are set, the compiler-generated assembler source files are deleted when the assembly is complete and never seen by the user.
The GNU assembler is mainly designed as a compiler back-end. Since Linux has been ported to many different machine architectures, using the GNU assembler to generate object files eliminates the need for compilers to be concerned with the many possible object file formats and machine differences. As a compiler back-end, the GNU assembler works well. As a stand-alone assembler, the GNU assembler does not provide many of the features that IBM mainframe assembler programmers depend on. The GNU assembler provides only basic assembler features. It supports a few assembler statements (called directives) to define program sections, define storage areas, constants and relocatable addresses. It performs symbolic address resolution, allowing locations to be assigned names and for those names to be referenced by machine instructions and directives. The GNU assembler does not have a real macro facility, it does not support DSECTs and it requires that the source be written in the same order as the object code will be generated. Since the GNU assembler is rarely used as more than a compiler back-end and the compilers can be expected to produce correct code, the GNU assembler provides only minimal error checking.
The Tachyon z/Assembler is designed to provide the rich assembler language environment needed for serious mainframe assembler program development. With minor modifications, the language supported by the Tachyon z/Assembler to develop Linux for S/390 and zSeries programs is the same language supported by IBM’s High Level Assembler. The Tachyon z/Assembler supports the HLASM macro language. It supports DSECTs. It supports the LOCTR and ORG statements, which allows assembler code to be written in a flexible sequence. It supports a rich set of options to control the production of object code, listing and ADATA files and to control the enhanced error checking.
The Tachyon z/Assembler can produce the object file in all of the common formats supported by mainframe operating systems. These formats include OMF (supported by MVS, VM/CMS, VSE and TPF), XOBJ and GOFF (supported by OS/390, z/OS and VM) and ELF (supported by Linux for S/390 and zSeries). The OMF and XOBJ formats can be produced by both the Tachyon 390 Cross Assembler and the Tachyon z/Assembler. GOFF and ELF can be produced only by the Tachyon z/Assembler.
The Tachyon z/Assembler can also assemble the output of the GCC compilers when gcc is configured to produce GNU assembler code for Linux for S/390 and zSeries. The PROCESS(GAS) option causes the Tachyon z/Assembler to read and translate the input file from GNU assembler format to HLASM format before assembling the statements. The PROCESS(GAS) option is ignored by the Tachyon 390 Cross Assembler.