Modelling of Language Syntax and Semantics: The Case of the Assembler Compiler.

Abstract

Application of software language technologies, whether analytical, transformational, or generational, in an industrial context is usually a taxing endeavour, with high demands in qualification levels of developers involved in it. Yet, if applied successfully, in the right places and with the right amount of effort, they promise high returns in terms of optimisation, effectiveness, validity and verifiability. In this paper, we report on our experience on writing a compiler for a complex second generation legacy programming language originally intended to be used on a mainframe. The business case for this product deals with companies migrating their software systems off the mainframe to cloud native or PC. Leveraging the documentation, available domain knowledge, several sample projects and a test suite, as well as several proprietary DSLs, we successfully modelled syntax and semantics of hundreds of instructions of that language, to the point of producing a compiler with a very limited group of compiler developers in limited time. The compiler is currently deployed at some of our customers and has received a top technology award from Microsoft.This report is meant to serve as a sample snapshot of how compilers can be built in the industry with software language engineering techniques. Traditional problems of compiler construction such as parsing or code optimisation either did not present a noticeable challenge or did not manifest themselves altogether in the course of this project, but MDE matters such as model transformation, modular design, the use of DSLs and meta-tools, were a constant concern. The focus of the report is in truthful representation of the domain as well as the details of the project, on reflection of the choices that were taken or could have been taken in the meantime, and on lessons learnt during the project.

Software language engineers’ worst nightmare

“…There are essentially two families of line continuation policies, which we will explain with example of HLASM and COBOL. In HLASM [11,57,78], which is the second generation language used on IBM mainframes since System/360, the continuation marker is set on the continued line: adding any nonspace character on column 72 will cause the line directly following it, to be concatenated into it. The inconvenience of having only one fixed place to initiate a line break, is alleviated by the option of duplicating the splitting symbol at column 72 leftwards, in which case the entire group is ignored.…”

“…We did use HLASM as an example when discussing line continuations in § 3.2, but ended up not using that much of the language itself for BabyCobol, even though it contains almost a thousand instructions and several hundreds macros. In particular, HLASM instruction EXECUTE was considered for inclusion: its semantics is to take several bytes from an arbitrary given place in memory, apply a mask to it and execute them as code [78]. Even if it is raised from the low level of assembler, it would mean treating arbitrary data as codea feature known as "eval" [54] in mainstream languages such as JavaScript, PHP, Perl, Python, Ruby, Lua, Forth, as well as Smalltalk and LISP.…”