It is therefore required to pair each closing loop statement (e.g. NEXT or ENDWHILE) with its corresponding opening loop statement(s), and this is turn requires that the possible paths of execution through the program can be determined statically (i.e. at compile time) so that for each closing statement we can trace backwards through the program execution to the previous opening statement. This also makes it possible to identify illegal constructs, such as ending a WHILE loop with a NEXT statement.

To achieve this, we must build a data structure called the Control Flow Graph (CFG). For each statement in the AST we determine all possible following statement. Ordinarily this is simply the next statement in the program, but we must also resolve line number references in GOTO, GOSUB, etc. and at each IF statement control flow may go in either of two directions. We do not resolve function or procedure calls when building the CFG, so each function or procedure becomes a separate connected-component in the resulting graph.

I’ve been working with the code to Acornsoft’s Sphinx Adventure from 1982 as a real-world BBC BASIC test program for the BBC Micro.

I don’t know who the author is, but I’m willing to bet they never imagined their by now long-forgotten code would undergo the sort of analysis its about to receive! Maybe the code in Sphinx Adventure is intentionally obfuscated, or maybe its just badly written, but some of the non-structured programming techniques such as jumping out of the middle of procedures never to return, are ‘interesting’ to say the least.

Each node in this image is a single statement in the program, and the arrows between the nodes indicate the program flow. Each connected group of nodes is a separate procedure, and the largest group of nodes to the top-left of the chart is the main program starting from the first line through a long trail of DATA statements.

The Sphinx.graphml is browsable with yEd, which was also used to produce these diagrams.

Zooming in, we can see the CFG for a single procedure – in this case PROCF,

462 DEF PROCF(W): IFW=28 THEN PROCR(21): GOTO465
463 IFO?W <> L  ANDO?W <> 1 THEN PROCR(7): PRINTA2$;" here.": GOTO465 ELSE IFO?W2 <> 1 THEN PROCR(8): PRINTA2$;".": GOTO465
464 IFW=27 ANDL=O?28 ANDWA=0 THEN PRINT"Your bottle is now full of water.":WA=1 ELSE IFW=27 ANDL=O?28 THEN PRINT"your bottle is already full." ELSE PROCR(21)
465 ENDPROC

The label in each node indicates its logical line number in the original code and the type of statement the node represents at the abstract syntax level.

Now we have the basic CFGs we can analyse them to match up corresponding loop statements, and optionally perform optimizations such as moving invariant code out of loops and eliminating dead (unreachable) code fragments.

During a nostalgic poke around the web relating to Acorn hardware, over 12 years since my last contact with BBC BASIC, I stumbled across Richard Russell’s BBC BASIC for Windows (BB4W) which reminded me of my formative years learning to code on the BBC Model B and later various Acorn Archimedes computers under RISC OS. This led me to start down the road of implementing a BBC BASIC compiler for the CLR, although the original BBC BASIC, and BB4W are interpreted. The original BBC BASIC II resided in only 16 kB of ROM, so it can’t be that much work. Can it?

The BBC Basic for Windows implementation, from Russell actually goes to long lengths to provide good backwards compatibility with software originally developed for the Beeb or RISC OS, such as providing a Teletext MODE 7 equivalent, and ‘emulated’ sound and graphics support.

I will be taking a different tack with this project. Rather than focus on getting old code reliant on obsolete hardware features to run, I will focus on making a viable BBC BASIC compiler for the CLR, which could be used to port existing programs to .NET/Mono. It is likely that OS or machine specific functionality such as sound and graphics will be implemented in significiantly different ways compared to the originals, for example, by giving good language-level integration with the System.Console class in .NET, rather than trying to emulate screen modes from Acorn hardware.

The toolset I settled on is as follows:

• IronPython in which to write the compiler
• PLY – the Python Lex/Yacc-a-like
• BeebEm – BBC Micro emulator with BBC BASIC II
• Arculator – Acorn Archimedes emulator with BBC BASIC V
• Documentation in the form of BBC Micro and Archimedes user manuals, and various other information and examples on the web

Mostly its an experiment, and for the fun of writing a compiler. I don’t expect anybody to start creating large software systems in BBC BASIC as a result of my efforts. Far from it; there are much better tools today. However, I must admit to a secret aim of producing the fastest BBC BASIC implementation yet!

In terms of the hardware of the time, the BBC Microcomputer was something special. It had 32 kB of RAM for programs and the display and 32 kB of ROM containing the operating system and BBC BASIC, occupying the 64 kB address space of the 6502 CPU. We had a somewhat unreliable cassette deck for storing programs.

I probably spent thousands of hours over the next four years learning to program, mostly in the fantastic BBC BASIC (real prodecures with parameters, REPEAT..UNTIL loops and no real need to use GOTO, and of course integrated 6502 assembler) which gave me an excellent grounding in structured, procedural programming. I had a good line in writing software for my father to help in his land and engineering surveying work, which was my first introduction to writing mathematical and engineering software – all in BBC BASIC.

I also spent time fiddling with the hardware side of things, very much encouraged by the massive expandability of the BBC Micro. Usuually this would involve connecting home-made devices, motor controllers and the like, to the User Port (pretty raw access to a 6522 VIA chip) or to the Analogue Port. All of this was inspired by a series of articles by Mike Cook in The Micro User (later Acorn Computing) Magazine called The Beeb Body Building Course.

So why the nostalgia?

Well, two reasons. The first is that this early exposure computing is largely responsible for my career path, and the fact today that I now work as a software developer. The second reason is that last week I downloaded an impressively good BBC Micro emulator for my PC called BeebEm.

Obviously, a BBC emulator isn’t much use to me these days for software development, and all the interesting hardware aspects of the Beeb are of course not relevant. Nonetheless, it did give me the opportunity to indulge in some serious nostalgia playing old games such as Thrust, Elite and Exile.