21

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?

  • 3
    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
  • 2
    @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
  • 3
    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
  • 2
    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
30

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
  • pndc, can you not assign the output of the DIV to a FP variable? Or does that return an error? If its an error, I am very interested in benchmarking a few cases! – Maury Markowitz May 18 '18 at 11:03
4

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 says reinstate Monica Aug 12 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 at 15:31
  • 1
    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 at 20:18
3

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.

  • 4
    So, BBC Basic was fast because the BBC was fast? – wizzwizz4 Jan 3 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 at 16: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.