Overview of the Toolchain

\crexx{} is built as a small set of separate tools with visible boundaries. That is deliberate: users can inspect the generated assembly, assemble it directly, link modules, disassemble bytecode, or package a program for native deployment.

\begin{wrapfigure}{l}{0.4\textwidth} \includegraphics[scale=0.3]{charts/buildflow.pdf} \end{wrapfigure} \fussy

The common flow is:

1. rxc compiles .rexx source to .rxas assembly.
2. rxas assembles .rxas assembly to .rxbin bytecode.
3. rxvm, rxvme, rxbvm, or rxbvme executes one or more .rxbin files.
4. rxlink optionally combines modules into a linked image with a shared constant pool.
5. rxcpack can package a linked image as C data for native executable builds.

The crexx driver wraps the usual compile, assemble, run, link, and package steps for day-to-day use.

Source, Assembly, and Bytecode

Source files are UTF-8 text and normally use the .rexx extension. The compiler output is RXAS assembly:

rxc hello.rexx

The assembler output is RXBIN bytecode:

rxas hello.rxas

RXBIN is the module format consumed by the VM, linker, disassembler, and packager.

Module Discovery

The compiler separates source discovery from binary discovery:

• source roots contain .rexx files
• binary roots contain .rxbin, optional .rxas, and .rxplugin files

Use rxc -s path to add a source import root and rxc -i path to add a binary import root. The crexx driver exposes the same distinction for compilation.

The runtime library path is separate. Use crexx -l... or the VM’s own library loading rules when a compiled program must load bytecode or plugins at runtime.

Linking

rxlink combines one or more .rxbin modules into a linked image with one shared constant pool. This reduces duplicate constants and resolves module and interface-provider relationships up front while preserving the module records needed by the VM loader.

Use rxlink for release-style deployable images and for native packaging.

Native Packaging

Native packaging uses rxlink before rxcpack. The linked image is serialized to C data and linked with the VM runtime library by the platform C toolchain. The generated executable contains the program image and the runtime pieces selected by the build.

Static and dynamic plugin choices depend on how the project was built. Do not assume every distribution contains every optional native plugin.