32

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?

Improve this question
11
  • 9
    As an aside: a commented disassembly for the original BBC BASIC can be downloaded here.
    – Jules
    May 14, 2018 at 17:05
  • 4
    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, 2018 at 17:17
  • 4
    @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, 2018 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, 2018 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, 2018 at 4:23

4 Answers 4

Reset to default
17

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):

BBC BASIC CPU TIMING PROGRAM
REALLY REAL REPEAT LOOP      0.97MHZ
INTEGER REPEAT LOOP          0.96MHZ
REALLY REAL FOR LOOP         0.97MHZ
INTEGER FOR LOOP             0.96MHZ
TRIG/LOG TEST                0.97MHZ
STRING MANIPULATION          0.97MHZ
PROCEDURE CALL               0.97MHZ
GOSUB CALL                   0.94MHZ
COMBINED AVERAGE             0.96MHZ

COMPARED WITH A 2.00MHZ BBC B

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:

BASIC BENCH INDEX
>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

OVERALL INDEX=102

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.

Improve this answer
7
  • 1
    Nice statistics. Love the effort.
    – Raffzahn
    Dec 26, 2020 at 23:16
  • 4
    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, 2020 at 0:32
  • 1
    @Raffzahn: I would expect a good BASIC implementation which optimizes integer math performance to run more than twice as fast as MS-BASIC for tasks that involve primarily integer math.
    – supercat
    Jul 19, 2021 at 15:43
  • 1
    @supercat depends on the version of MS BASIC: not all of them have the egregious bug that CBM BASIC has in handling integers. A BBC Micro will do 30 FOR I%=1 TO 5000 / 40 LET J%=J%+1 / 50 NEXT I% in under 5 s. MSX BASIC will do it in 14 s. Removing all '%' integer sigils, a C64 completes in 22 s. Keeping J as J% slows it down to 25 s. Using % harms portability, though. To me, Richard Russell's BBC BASIC (v3) for the Z88 is the cleverest: it runs the all-integer test in 16 s, but removing all %s only slows it to 18 s — it uses aggregate types to keep integers for as long as it can
    – scruss
    Jul 19, 2021 at 17:49
  • 1
    @scruss: I wouldn't think one would need the % if a zero exponent indicated that two bytes of the significand should be interpreted as an unsigned 16-bit value, which would be positive or negative based upon the MSB of another significand byte. Add to that a feature in the tokenizer that will check if a number in source code is a maximally-compact representation of an integer and write one of four special tokens followed by the integer's binary value if so, and integer math speed would be massively improved [tokens would indicate whether MSB, LSB, both, or neither was non-zero].
    – supercat
    Jul 19, 2021 at 17:54
38

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.
Improve this answer
15
  • 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, 2018 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, 2018 at 17:25
  • 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, 2019 at 15:04
  • 1
    @Chromatix - 8KB BASIC + 2kB FP ROM + 8kB OS ROM. So about the same size in the end. The FP code was slow simply because it was slow, they just didn't know what they were doing (and freely admitted that).
    – Maury Markowitz
    Aug 14, 2019 at 23:49
  • 1
    @Chromatix: I think the DFS ROM (at least the 0.9 version) was only 8K.
    – psmears
    Dec 8, 2020 at 14:47
6

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.

Improve this answer
4
  • 5
    So, BBC Basic was fast because the BBC was fast?
    – wizzwizz4 ♦
    Jan 3, 2019 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, 2019 at 16:33
  • 1
    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, 2020 at 10:59
  • 1
    Note that the basic "Master 128" ran at the same speed as the original BBC micro. The Master turbo had an extra board in it with a second 6502 running at 4MHz. chrisacorns.computinghistory.org.uk/docs/Acorn/Brochures/… quotes a RRP of £499 for the basic master 128 an an additional £125 for the extra board to turn it into a master turbo.
    – Peter Green
    Jul 20, 2021 at 2:48
6

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.

Improve this answer
4
  • Welcome on the site! I think the OP wants to compare the benchmarks of the BASIC interpreters, not the screen resolutions.
    – peterh
    Aug 12, 2019 at 15:04
  • 4
    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, 2019 at 15:31
  • 4
    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, 2019 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, 2020 at 14:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .