Multi-threading annoyance

[Richard Russell]

One limitation of BBC BASIC is that (like most interpreted BASICs, I expect) the interpreter is single-threaded. This means that if you want to spread a compute-intensive task between multiple cores or CPUs you're forced to spawn separate processes rather than separate threads.

That's not to say that doing so will necessarily be difficult, that will depend on what degree of coöperation or synchronisation between the tasks is required. Such inter-task communication is likely to be easier when they are running on separate threads (which share memory) than in separate processes (which don't).

BBC BASIC could in principle be made multi-threaded if one specific requirement was met: that two key global pointers (the pointer to the currently-running program and the stack pointer) are guaranteed to be held in registers - which are specific to a thread - rather than in memory - which isn't.

And indeed in the versions of BBC BASIC written in assembly language (e.g. BBC BASIC for Windows and the 32-bit x86 editions of BBC BASIC for SDL 2.0) and the versions compiled by GCC (e.g. the Linux and Raspberry Pi editions) those global pointers are guaranteed to be held in registers.

But - and this is where the annoyance arises - when compiled by Clang they are not. Although Clang is by design highly compatible with GCC, the specific feature which allows you to put global variables into registers is not implemented. This omission has been much discussed over the years but it seems unlikely ever to be resolved.

Unfortunately Clang is used to compile the MacOS, Android, iOS and in-browser editions of BBC BASIC, which rules out multi-threading on those platforms. I did try telling Clang to make the pointers thread-local, in the hope that it would realise that the easiest and fastest way is to keep them in registers, but instead the performance plummeted.

So there we have it. Some of my current versions of BBC BASIC could in principle be capable of multi-threading, but others can't.

[hellomike]

Wow, I didn't realize that the Windows versions of BBCSDL are also coded in assembly language, rather than pure C-language. That must seem hard to maintain between the different BBCSDL versions.

[Richard Russell]

Wow, I didn't realize that the Windows versions of BBCSDL are also coded in assembly language, rather than pure C-language.

Both of my 32-bit Windows interpreters - BBC BASIC for Windows and the Windows edition of BBC BASIC for SDL 2.0 - use (virtually) the same assembly language code. That's why they run at near enough exactly the same speed, and share pretty much exactly the same features.

It's difficult enough as it is to persuade dyed-in-the-wool BB4W users to migrate to BBCSDL - or at least to use them both depending on which is more suitable for a particular application - without the additional objection that BBCSDL runs more slowly, as it would if coded in C.

That must seem hard to maintain between the different BBCSDL versions.

Not really, because the BBC BASIC interpreter itself is very rarely changed, and if it is the likelihood is that you would want BB4W and BBCSDL to stay in step anyway.

I think I'm right in saying that the only outstanding change to the BBCSDL interpreter which has not been 'back-ported' to BB4W is the ability of whole-array assignments to write to a destination array which is not the same type as the source array(s). If I ever update BB4W again I would expect that to be incorporated, but I have no plans to, and almost certainly won't unless a serious bug is found.

I had not planned, or expected, to update BB4W to v6.16 last year, but a serious issue - which made its execution speed extremely dependent on variable alignment with some CPU types - had been identified and had to be fixed.