Compiler driver and command-line frontend. It parses driver options, manages the compile/assemble/link pipeline, invokes external tools, adds libraries, and performs final driver-side actions such as linking or post-link commands.

Generic driver flow belongs here. Target-specific OS behavior should usually live in fbc-platform or one of the fbc-*-platform files instead of being added directly to fbc.bas.

Compiler-driver platform hook dispatcher. This module defines the hook table used by fbc.bas and includes one platform module for each target in the FB_COMPTARGET table.

The current platform hooks cover:

• choosing the linker tool
  
• adding target default library search paths
  
• adding graphics library dependencies
  
• adding sound library dependencies
  
• adding ordinary target default libraries
  
• adding linker framework or target flag fragments
  
• mapping library names when one target needs a different library spelling
  

The platform hook layer is for compiler-driver behavior tied to the selected OS target. It is not the place for parser rules, AST behavior, ABI layout, or backend code generation policy.

Per-target driver modules. One compile target maps to one file named fbc-[target-id]-platform.bi, where [target-id] matches the target id from fb.bas:targetinfo().

These files keep target-specific linking and packaging rules out of fbc.bas. Examples include Win32 default system libraries, Darwin linker tool selection, JavaScript and Wii linker-driver selection, devkitPro library paths, X11 library search paths, OpenBSD library spelling differences, and other target toolchain quirks.

Platform modules currently exist for Win32, Cygwin, Linux, Android, Haiku, DOS, Xbox, FreeBSD, DragonFly, Solaris, illumos, OpenBSD, Darwin, NetBSD, JavaScript/Emscripten, and Wii.

Object/library information section reader/writer, used by fbc. Includes small ELF/COFF object file readers.

Compiler-wide state and parser interface. It owns the target information table, initializes target state, and starts the parser for each input/include file.

Recursive parser. It asks lex for tokens and builds up the ast.

Lexer/tokenizer and preprocessor directive parsing.

Error reporting functions used by many parts of fbc, especially the parser.

Helper functions that build ast nodes for rtlib/gfxlib/sfxlib function calls. Declarations here must match the actual functions in the runtime, gfxlib2, and sfxlib source code.

Symbol lookup and storage: variables, functions, scopes, namespaces, and name mangling. Used by the parser, ast, and emitters.

Abstract syntax tree for per-function code flow and expressions.
astNew*() creates and connects nodes for the parser.
astLoad*() is the first step in emitting and calls ir after each function is parsed.

Intermediate representation layer used to emit the ast.
ir-hlc emits high-level C.
ir-llvm emits LLVM IR.
ir-tac is the three-address-code path used by the asm backend and calls emit.
ir-gas64 contains GAS-oriented 64-bit asm support.

Register allocator for ir-tac.

Assembler emitter abstraction plus the x86/SSE-specific emitters.

Stabs debug format emitting for emit_x86.

Dynamic z/wstrings, used mostly by lex.

Generic hash table, used by symb and fbc.

Helper functions used throughout the compiler, plus another dynamic z/wstring implementation.

Generic linked list with built-in memory pool, used heavily throughout the compiler. It is often used as a pooled allocator, for example for AST nodes or symbols.

list-based container for append-only lists.

list-based allocator using multiple lists with node sizes from small to large. Used to store symbol identifiers with less wasted memory.

Generic list-based stack.