As I look over old versions of BASIC trying to piece together their history, I come across repeated indications that BBC Basic was really fast. One list puts it running the Ahl benchmark (for all its warts) in 21 seconds, compared to just over 30 for the Apple II, 123 for the C64, and a whopping 400 for the stock Atari.

Now I know that the Atari issue is the terrible, terrible floating point. Replacing those improves it to 123 seconds. Much of the rest is due to the GOTO/NEXT issue, and replacing those improves it again to 101 for MS BASIC, and 41 for TURBO-BASIC, which caches the line numbers for GOTO/GOSUB.

Now TURBO was one of the fastest BASICs out there, yet here the BBC version is besting it by about 2x. I would really like to explore how it did this. I contacted some of the original authors, but have not heard back. I also did a bunch of googling, but it returns too many off-topic hits, I can't seem to find anything relevant.

So, does anyone know of a description, or can simply type one, of why this was so fast? Did it cache line numbers for GOTOs? Use a reverse parser (as in Altirra)? Use p-code (like FastBasic?). And what about it's math routines... did they unroll the loops?

  • 5
    As an aside: a commented disassembly for the original BBC BASIC can be downloaded here. – Jules May 14 '18 at 17:05
  • 3
    Also, assuming you're using it on a BBC Micro, don't forget that you're running on a 2Mhz 6502 processor with no wait states, stoppages, etc. So you'd expect the exact same machine code to be a bit more than twice as fast as a C64 and almost twice as fast as an Apple II. Even an Election gets 2Mhz access to ROM, so don't think you can use that machine to even the score. – Tommy May 14 '18 at 17:17
  • 3
    @MauryMarkowitz faster memory; it uses a fixed interleaving of CPU access, video access, CPU access, video access, etc, regardless of mode and the RAM is fast enough that it can do that while running the CPU at a constant 2Mhz. – Tommy May 14 '18 at 23:16
  • 4
    This is a total tangent, but I was surprised to learn that you can still get a commercial version of BBS Basic for Windows as well as other platforms. I wouldn't know this, but I actually had a developer request an approval to use the software because he'd written a fairly extensive test suite for a particular use case back in the old days that he'd continually updated. It was very impressive, considering it's lineage. – KJ Seefried May 15 '18 at 2:24
  • 4
    Faster memory. The BBC had 100ns access / 200ns cycle time 4816A-3 RAM chips, which are substantially faster than the 4164-150 (150ns access / 375ns cycle time) chips in the Atari. Critically, they can fit 2 full read or write cycles inside a single processor cycle, which the Atari's memory can't. – Jules May 15 '18 at 4:23

Most of BBC BASIC's speed advantage came from Acorn's use of a 2 MHz 6502 with fast 4816A RAM chips. It's a good interpreter, but it's the hardware that makes it near-mythically fast.

To confirm this, one can run J. G. Harston's port of 6502 BBC BASIC for Commodore 64. This is essentially the Acorn BBC Micro's interpreter lightly patched to talk to KERNAL routines. Running the ClockSp 3.00 BBC BASIC benchmark on an NTSC C64 (1.023 MHz 6510 or 8500):

ClockSp 3.00 (RTR)

INTEGER FOR LOOP             0.96MHZ
TRIG/LOG TEST                0.97MHZ
PROCEDURE CALL               0.97MHZ
GOSUB CALL                   0.94MHZ
COMBINED AVERAGE             0.96MHZ


A just-switched-on BBC Micro would return 1.92 MHz. To get to the 2 MHz value, you have to turn off some interrupts. So a C64 clocks in at half the speed of the BBC Micro, as you might expect from the clock speed.

To verify that the Acorn interpreter is not much faster that Commodore BASIC 2.0, one can run my bench64 portable BASIC index program on the C64 BBC BASIC interpreter. With Commodore BASIC, an NTSC C64 scores 100 on each test:

>I GOOD. NTSC C64=100

1/8 - FOR:
      57.8S;700/S; I=104
2/8 - GOTO:
      87.8S;302.1/S; I=68
3/8 - GOSUB:
      45.3S;465.1/S; I=133
4/8 - IF:
      43.3S;336.5/S; I=139
5/8 - FN:
      60.2S;60.5/S; I=100
6/8 - MATHS:
      63.3S;6.1/S; I=95
7/8 - STRING:
      56.6S;87.1/S; I=106
8/8 - ARRAY:
      55.2S;30.3/S; I=109


So Acorn's interpreter might only be very slightly faster on the same hardware as Commodore BASIC.

This is not to say that you couldn't do efficient things with BBC BASIC — its integer FOR loops are around 3x the speed of Commodore BASIC's floating point ones on the same hardware, and it's undoubtedly a better dialect — but for portable code it was the Acorn hardware that made most of the difference.

  • Nice statistics. Love the effort. – Raffzahn Dec 26 '20 at 23:16
  • 1
    It's the sort of thing you find when you write your own benchmark — absolutely the last thing I expected to find out was that C64 BASIC is bearably fast, if lacking in features. – scruss Dec 27 '20 at 0:32
  • Well, yeah, what we imagine of not what reality tells. Given, a good BASIC implementation may gain noticeable advantage, but it will be confined to a 10-15% corridor. The whole issue is in my opinion part of an over all 'law' what with a given technology and goal implementation will only differ by less than 15% up or down. Best example are CPUs. Endless discussions about Z80 vs. 6502 have been made focusing on instruction set, but in reality it's all about memory speed. With a given access RAM time both perform about the same. Similar for all other CPU until levelled cache took over. – Raffzahn Dec 27 '20 at 1:08

There are a number of optimisations which, in aggregate, will improve performance somewhat:

  • There are multiple linked lists for the variables, one per first letter of the variable name. This makes name lookup faster compared to a more typical implementation with one linked list.
  • The integer variables @% through Z% have fixed memory locations and do not require a lookup at all.
  • The existence of integer variables avoids using expensive floating point unnecessarily.
  • The rich control flow primitives mean that one can avoid GOTO and GOSUB, which perform expensive linear searches across the program to find a line by number. PROC and FN locations were cached.
  • The heap is never garbage-collected. This is why extensive string manipulation will cause BBC BASIC to quickly run out of memory.
  • Excellent post pndc! Many of the replacement BASICs on the Atari cached all the line numbers, not just PROC and FN. The multiple-list var lookup is an interesting addition! And the Ints, so they just left a stack of (32?) ints somewhere for indexed lookup? – Maury Markowitz May 15 '18 at 17:22
  • Actually a string benchmark would be interesting... Atari didn't have strings, they had FORTRAN-like CHARACTER arrays, so they were perhaps even faster. The downside... no concat! – Maury Markowitz May 15 '18 at 17:25
  • do you have any additional color on the integers? Did they use their own math functions, or call into the FP code? Or was it like MSv.2, where they only changed the storage, and still treated them as FP otherwise? – Maury Markowitz May 17 '18 at 19:19
  • @MauryMarkowitz A quick skim of the source code suggests that some overloaded operators ("+" being an obvious example as it does strings as well) do indeeed have an integer fast path. Operators like DIV and MOD are integer-only anyway. – pndc May 18 '18 at 9:05
  • 1
    As well as having a faster CPU to work with, BBC BASIC benefited from a larger ROM than most other BASICs, which allowed the interpreter to be implemented using table jumps on keyword token values. This was a major improvement over completely re-parsing each keyword as it was encountered at runtime. Notably, the principle author of the interpreter went on to design much of the ARM CPU. – Chromatix Aug 13 '19 at 15:04

I believe that the bbc master turbo had a 4mkz 65c02 and ran basic 4, so expect better than 2X again. I don't know about 6809, but the BBC range had the fastest processing from their introduction until the Archimedes range took over even excluding the ARM processor that was developed as a BBC coprocessor.

  • 5
    So, BBC Basic was fast because the BBC was fast? – wizzwizz4 Jan 3 '19 at 10:28
  • I feel like the BBC Master and Atari ST were priced closely enough together to be bracketed for speed comparison during that slightly awkward period running up to the launch of the Archimedes. Is my memory at fault? – Tommy Jan 3 '19 at 16:33
  • BBC BASIC was fast and AFAIK the fastest BASIC at most things, but probably not all. Running in MODE 7 (Teletext), it is one byte per character and uses hardware scrolling, so even printing is fast. It also had the fastest CLS of any 8 bit AFAIK. – Richard Broadhurst Mar 30 '20 at 10:59

Personally I also found that running in MODE 7 (the teletext mode) was far faster than any of othe other screen modes. The video had to handle 20K of screen memory in MODEs 0-2, 16K in MODE 3, 10K in MODEs 4 and 5, and 8K in MODE 6. MODE 7 required just 1K. So, not only were screen updates massively faster, the hardware had to spend less time accessing the RAM.

  • Welcome on the site! I think the OP wants to compare the benchmarks of the BASIC interpreters, not the screen resolutions. – peterh - Reinstate Monica Aug 12 '19 at 15:04
  • 2
    Fair point. But, the point I'm making is that different screen resolutions can have an effect on how fast BASIC runs - the bigger screen modes require more memory access time, leaving less to BASIC. – Soruk Aug 12 '19 at 15:31
  • 3
    The BBC Micro's video circuitry accessed the RAM in the portion of the clock cycle when the CPU was executing an instruction, so drawing the screen didn't slow the CPU at all. (Changing or updating the screen's contents would be done by the CPU, so redrawing a low-memory display mode would be quicker, by virtue of there being less to redraw.) To my mind, the main advantage of the low-memory modes was leaving more memory available for writing a long BASIC program. – Kaz Aug 12 '19 at 20:18
  • 3
    However, the Electron stole cycles from the processor, so the high resolution modes were genuinely slower than the low resolution ones. It didn't have mode 7, either, which wasn't helpful. – David Given Feb 26 '20 at 14:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.