My teen years: The Pascal compiler for transputer

Transputer homebrew board
Once upon a time when I was a teen, I wrote an almost full Pascal compiler for a transputer processor (the FILE type wasn't never completed). The Pascal language was designed in 1971 by Niklaus Wirth, as an educative version of the language Algol, which dates from 1960. It reached its highest popularity with Turbo Pascal and Delphi from Borland. Borland was founded by Philippe Kahn, who studied Pascal with Wirth.
This year 1993 was the convergence of several things I had been learning: Pascal (through The BYTE Book of Pascal), code generation (Compilers: Principles, Techniques and Tools), and transputer programming.
It was a time when the INMOS transputer promised parallel computing for everyone, but it was too expensive. They did a few good things, like 32-bit processing, and a very fast T805 transputer with 64-bit floating-point before the Intel 486DX2 was a thing.

In the start there was a transputer

Transputer homebrew board
My father got a pair of transputer chips and the required peripheral chips. It was 1992, and the transputer chip price was $500,000 Mexican pesos. In case you want a reference, the US dollar price was $380 pesos, an Intel 8087 math coprocessor was selling for $297,000 pesos, a liter of milk had a price of $2,300 pesos, and a kilo of tortilla was available for $1,000 pesos.
He made schematics and my duty was redoing these using my schematic drawing software. He wrote also long pages of handwriting explaining how it worked, and I would type in everything and print clean documents.
My father wrote small test programs, and he would go on a long discussion about how the fastest Fibonacci algorithm would demonstrate something, and it would form the basis for higher-level algorithms. He was delighted trying algorithms and optimizing for whole days, and he also said that this processor was the fastest in the world.
The year 1993 came fast, I was a teen (age 14), and I was bored. I thought that if the processor was so fast then there should be a way to test its potential. Whenever he was testing new instructions for the processor, I would read surreptitiously the processor manual, trying to find a way in my mind to bootstrap something, and doing a mental comparison of my Z80 and 8086 knowledge against the strange stack-based transputer processor.
I also studied some FORTH (named as the herald to the fourth generation languages, but the operating system of its developer only allowed five letters for the name), but I never fully understood how the compiler built its word set.

This thing was fast!

Book Transputer Assembly Language Programming (front)
In a complete serendipity, I was reading The BYTE Book of Pascal which talked a lot about reverse-Polish notation (another name for calculations made over a stack), and I had got recently the Spanish edition of Compilers: Principles, Techniques and Tools book, which I was struggling to understand.
I started my exploration in unknown lands with a loop. A barebones simple loop to see how fast was the processor. I typed the code for the loop, made it to count 1 million times (well, 1048576 times), and I was astonished to see that in fact, the processor ran faster than anything I had tested before. The Z280 processor could run a 65536 times loop in under a second, but the transputer was counting one million in under a second.
The transputer board was essentially the T805 processor surrounded by 32K of high-speed RAM memory, and only able to send and receive serial data through a transceiver. No screen, no keyboard, no sound. The Z280-based computer developed previously served as a host.
Of course, I was enticed to do something more complex, and my first project was writing an assembler for the T805. This way I could code more complex projects for testing.
Book Transputer Assembly Language Programming, back detail
The transputer has this weird thing that its basic instructions are of different length. Loading a constant from 0 to 15 was achieved with a single byte instruction, but each further 4 bits required another byte. Loading a full 32-bit constant would require 8 bytes. Implementing an assembler for this beast required a complete rethinking of my approach to assemblers. It took me several months of the year 1993 to get it running.
This first assembler was written in Z280 machine code. It took the source code from a file, assembled it, and expanded the transputer instructions as needed until it achieved a zero-change stability.
The Z280 processor has the ability to run as a common Z80 getting code and data from $0000-$ffff, and setting up a 64K MMU area for system and another 64K for user. I used the extended instructions to get a 64K text buffer for my text editor, and to build there the data required for the assembler.
Once I had a working assembler, I built easily a system monitor to develop programs. It was a whole new world for me, as I never had worked with a 32-bit processor.
My success with the assembler directed me to another objective, P-code portability. I already had adapted the Tiny Pascal compiler written in BASIC that appeared in The Byte Book of Pascal to run in the Z280 machine, not a great effort as the original compiler run on an 8080 machine, as it is pretty compatible with Z80. It generated P-code (a pseudo code) that was interpreted to run the compiled Pascal programs.
But what if instead of a P-code interpreter, I could write a P-code translator to transputer assembler? I went to work and I made a quick&dirty converter of P-code to transputer, and I was pretty happy although the compiler running in BASIC language was incredibly slow.
Also the generated code was incredibly inefficient.

Enter the dragon

It was July 1993 when I finally understood the utility of the tree generation for expressions. The function gencode from the Dragon's book (section 9.10, figure 9.25) was a complete inspiration.
Up to that point in time, all my compilers suffered from an excess of unnecessary push and pop instructions along some pretty basic peephole optimization, because I didn't knew how to optimize it properly. Now, the total number of registers in the transputer was 3 (A, B, and C), and just by ordering the tree I could optimize it in an amazing way and the generated code was very compact.
Still the BASIC language was too slow for bigger programs, even more as I started to figure that the Pascal compiler could be written in Pascal. I decide to code it using Turbo Pascal in MS-DOS.
In September 27, 1993, I started porting the compiler to Pascal. It took me two days to complete the basic compiler, and I was pretty happy to see it working. To my dismay, it exceeded the 32K of memory I had available in the transputer board.
I needed 25K of RAM to execute the compiler, and if it was going to self-compile I needed another 25K for the data. I tried all the possible ways to optimize it, to no avail, until two days later, my father surprised me putting 128K of RAM in the board, and I was able to load it.
I got back to the Z280 machine where I used my text editor to keep developing the compiler. I made a "driver" program that feed all the source code to the transputer, and get back the compiled code to the disk drive. The resulting assembler code was still assembled over the Z280 machine.
I found the few errors in the compiler and the assembler, and my Pascal compiler was up and running. I was ecstatic after managing to get the Pascal compiler to compile itself in the transputer board.
I was also learning there were standards. Niklaus Wirth did an amazing job specifying the Pascal language, and I was fortunate enough to have some Pascal books around.
Soon I had my first objective: a full Pascal compiler. Wasn't more like teens should be losing time in arcades? Anyways, I worked step by step on improving the Pascal compiler, and each little achievement was pretty rewarding for me. It was an enormous success implementing the floating-point support, although made easier because the transputer had the integrated floating-point instructions. Some optimizations got almost 100% speed-up for compiled programs.
At the end, it took me a little over a month to create an almost full Pascal compiler. I never made the final milestone of doing the FILE type, mostly because I didn't understand how it worked. I also divided the compiler in several pieces (each one less than 64K) so I could edit the growing compiler with my own text editor.
I had a Ray Tracing book and I started ported the code to Pascal, and the whole November 1993 I was debugging my Pascal compiler and improving the optimization to generate ray traced images. I was incredibly happy. I'll update this if I find the source code and images.
I was pretty sure Pascal was the future, until I started to become uncomfortable with the Pascal's strong typing, as it was pretty limiting when trying to do system programming.
I built confidence with this Pascal compiler, and it served me as a good experience for my next achievement: a C compiler for transputer. But that will be another history.

32 years later

I cannot believe now is the year 2025. My Pascal compiler today stands out as a curiosity, and a testament to my effort. An almost full Pascal compiler written by a tech-savvy teen, I never noticed I could have sold it. Every software development tool at the time had a very high price, even more for the transputer.
For this article I've extracted the last version of my Pascal compiler, and given we don't have the host Z280 computer, I had to write the support software in modern C. Namely the emulator for the transputer processor, and the assembler.
The source code is released at https://github.com/nanochess/transputer
Enjoy it!

Related links

Last modified: Feb/04/2025