General structure

• The compiler is designed as a library to be called by a program through the driver interface exposed in lib/driver/driver.c. The current driver program is statically linked against the compiler modules, but this will change at some point.
• The design should be usable in a threaded environment. All working data is maintained in heap-allocated context structures. Static variables are only used for read-only data. One compilation per thread/context.
• The design is loosely divided into front-end and back-end parts, with the driver interface sitting above both and connecting them.
• The C code should be generally portable. If there is a need to include code that is specific to the host OS that the compiler runs on, it should be kept to a minimum and isolated into its own module.

Language reference

• BLISS Language Reference Manual, DEC part number AA-H275E-TK, from May 1987.
• BLISS-64AN release notes Both of these are available on-line in various forms, such as the OpenVMS Freeware BLISS package.

Front-end design

The front end is divided into two layers:

• The lexical processing layer, which manages the sequence of lexemes the compiler operates on.
• The expression layer, which builds a set of data structures representing the routines and data specified in the input stream.

Lexical processing

The lexical processing layer consists of the following sublayers:

• Low-level management of lexeme and name table structures (lexeme.c and nametable.c).
• Input tokenizer in scanner.c
• Lexeme sequence management in lexer.c.
• Analysis of the lexeme stream, the core of which is in parser.c. That module also implements most of the lexical function handlers.
• Macro processing, in macros.c. This module includes declaration and expansion of macros.

Expression layer

The expression layer consists of the following modules:

• expression.c is the core of expression processing, handling primitives and operator expressions.
• expr_control.c handles control expressions.
• declarations.c handles all data, routine, and module declarations.
• structures.c handles structure declarations and structure references.
• symbols.c manages the symbol tables that track data segments, literals, labels, and routines. It is layered on top of the nametables module.
• execfuncs.c processes BLISS executable functions, and includes implementations of the standard functions.
• charfuncs.c processes the character-handling functions. The expression layer calls into the back-end modules to convert the parsed expressions and declarations into code.

Miscellaneous supporting routines

• In the front-end:
  • the listings.c module handles output of compiler listings.
  • the libgen.c module handles library files (reading as well as writing)
• In the lib/support directory, there are modules for
  • File I/O, in fileio.c
  • String management, in strings.c
  • Miscellaneous utility routines, in utils.c
  • Status codes, messages, and logging, in statcodes.c and logging.c

LLVM Back-end

The back-end layer in the lib/llvmgen directory generates LLVM IR from the expression and symbol structures constructed by the expression layer. Since BLISS is a fairly low-level language that provides access to target machine specifics, LLVM facilities for generating, for example, in-line assembly language are used. Note that the current implementation does not fully break the target-specific code away from the generic LLVM yet.