New: Console Mode editions of BBC BASIC

[Deleted User 9295]

Running with only 1GB of RAM should be possible if you use Raspberry Pi OS Lite

I don't know whether it's "Lite". It's not the NOOBS OS, it's the 'unofficial' 64-bit PiOS (what used to be Raspbian Buster) although I have the 32-bit version on another SD card somewhere. My current setup, to avoid the hassle (and risk) of swapping SD cards, is 32-bit PiOS on the RPi 400 and 64-bit PiOS on the RPi 4.

Would you like me to try this out, or do you have further concerns?

Don't do anything yet. I will try to check the amount of memory and how much space I have on my existing SD card (do you know what commands I should use?) to assess how much work would be involved in setting it up, and whether I can safely share it with my existing BBCSDL build platform which is obviously more important.

[Deleted User 9295]

For the benefit of others, this is the performance I'm seeing:

Code: Select all

BBC BASIC CPU Timing Program
Really real REPEAT loop     78.24MHz
Integer REPEAT loop         92.99MHz
Really real FOR loop       188.92MHz
Integer FOR loop           103.48MHz
Trig/Log test             1764.10MHz
String manipulation        144.63MHz
Procedure call             173.86MHz
GOSUB call                 153.84MHz
Combined Average           346.00MHz

Compared with a 2.00MHz BBC B

There's one feature of that table which I don't understand at all. At first glance it's exactly what you would expect from BBC BASIC running on a 'modern' CPU, i.e. that the Trig/Log performance is disproportionally better than the other tests (by a big margin) because of the availability of an FPU with native instructions for those operations. But the Cortex-M0+ doesn't have an FPU, or indeed any floating point registers or instructions at all (at least, I didn't think it did)!

If the Trig/Log functions are having to be implemented with power-series or continued-fraction expansions, like they are in Sophie's BASICs, then the performance shouldn't be better than the other tests, it should be worse, because of being required to work to 64-bit precision rather than 40-bit. Yet if we believe your table the Trig/Log tests are running at about the same relative speed as they do on an x86 or ARM CPU with floating-point registers and an FPU.

I am mystified by this.

[hoglet]

Don't do anything yet. I will try to check the amount of memory and how much space I have on my existing SD card (do you know what commands I should use?) to assess how much work would be involved in setting it up, and whether I can safely share it with my existing BBCSDL build platform which is obviously more important.

The command to check disk space is df with the -h option

Code: Select all

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        15G  2.9G   11G  21% /
devtmpfs        299M     0  299M   0% /dev
tmpfs           428M     0  428M   0% /dev/shm
tmpfs           428M   12M  417M   3% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           428M     0  428M   0% /sys/fs/cgroup
/dev/mmcblk0p1  253M   48M  205M  19% /boot
tmpfs            86M     0   86M   0% /run/user/1000

You are looking for the /dev/root line which shows the space available on the root file system.

I would strongly suggest you purchase a new 16GB MicroSD card and start afresh with a new Raspberry Pi OS Lite installation. I've just tried this myself, and managed to do a fresh install of the OS and the embedded ARM GCC tool chain, then compiled the Pico version(s) of BBC Basic from Bill's fork of BBC SDL.

The whole installation process took about 30 minutes on a 1GB Raspberry Pi 4. The base OS takes about 1.3GB. The tool chain and compilaton artifacts takes a further 1.6GB.

A clean compile of the Pico BBC Basic Console version (in console/pico) takes 33 seconds.

A clean compile of the Pico BBC Basic GUI version (in bin/pico) takes 68 seconds.

Here's a complete log of the commands I needed, starting with a completely fresh Raspberry Pi OS Lite install:

Code: Select all

#
# Enable SSH access, so rest of commands can be cut/pasted (optional)
#
sudo raspi-config nonint do_ssh 0

#
# Install ARM GCC Embedded tool chain, Git and CMake
#

sudo apt-get update
sudo apt-get install git cmake gcc-arm-none-eabi

#
# Create a working directory to keep things tidy
#

mkdir bbc_basic_pico
cd bbc_basic_pico

#
# Install the Pico SDK
#

git clone https://github.com/raspberrypi/pico-sdk.git
cd pico-sdk/
git submodule update --init
cd ..
export PICO_SDK_PATH=$(pwd)/pico-sdk

#
# Install the Pico Extras (needed for the GUI versipn)
#

git clone https://github.com/raspberrypi/pico-extras.git
export PICO_EXTRAS_PATH=$(pwd)/pico-extras

#
# Clone Bill's fork of BBCSDL
#

git clone https://github.com/Memotech-Bill/BBCSDL.git
cd BBCSDL

#
# Build the GUI version
#

cd bin/pico
make
ls -l *.uf2
cd -

#
# Build the console version
#

cd console/pico
make
ls -l *.uf2
cd -

The first command (raspi-config) enables SSH access so you can login from another machine and then more easily cut/paste the rest of the commands. That's just how I prefer to work. You can, of course, manually re-type then on the keyboard, but that's more prone to errors.

I hope this helps you, or indeed anyone else, who wants to build this from scratch.

Dave

[Deleted User 9295]

I would strongly suggest you purchase a new 16GB MicroSD card and start afresh with a new Raspberry Pi OS Lite installation.

Many thanks. I can't promise that I will proceed with this, but if I do your instructions will be extremely valuable.

[Deleted User 9295]

I can't promise that I will proceed with this, but if I do your instructions will be extremely valuable.

Because I prefer not to disturb my BBCSDL build setup (and anyway I don't have a suitable SD card) I tried following your instructions on my Raspberry Pi 400 without starting with a fresh OS. It wouldn't let me do a sudo apt-get update (by all accounts because Debian stable is now Bullseye rather than Buster) but that didn't seem to matter and the Pico console build appears to have succeeded!

[hoglet]

Because I prefer not to disturb my BBCSDL build setup (and anyway I don't have a suitable SD card) I tried following your instructions on my Raspberry Pi 400 without starting with a fresh OS. It wouldn't let me do a sudo apt-get update (by all accounts because Debian stable is now Bullseye rather than Buster) but that didn't seem to matter and the Pico console build appears to have succeeded!

That's great news Richard.

The Pico SDK doesn't rely on a specific version of ARM Embedded GCC. You might be using a slightly older version than you would be with a fresh install, but that's unlkely to be important.

What version does the following return:

Code: Select all

arm-none-eabi-gcc -v

I'll compare it with what I have on a fresh install.

Dave

[Deleted User 9295]

What version does the following return:

Code: Select all

arm-none-eabi-gcc -v

It says (if I've transcribed it correctly):

Code: Select all

gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (15:7-2018-q2-6)

Assuming 2018 is the year that is quite old!

[BigEd]

Just to add my encouragement:

I personally think BBC Basic on the Pico is very interesting, otherwise I wouldn't be investing the time in trying it out. It makes the Pico accessible to a whole host of new people (those who are comfortable with BBC Basic, but not C or Python). It includes graphical output (including 640x480 in two colours and 320x256 in 16 colours). It has a built-in ARM thumb assembler. This is all really good stuff, especially if you want an environment for experimentation/rapid prototyping.

Indeed - boot to an autorunning Basic program, assembly readily available, no specific IDE or toolchain needed to get going. Using copy and paste to manage small programs or tweaks to larger ones.

... I tried following your instructions on my Raspberry Pi 400 without starting with a fresh OS ... the Pico console build appears to have succeeded!

That's great news Richard.

Indeed it is!

For the benefit of others, this is the performance I'm seeing:

Code: Select all

BBC BASIC CPU Timing Program
Really real REPEAT loop     78.24MHz
Integer REPEAT loop         92.99MHz
Really real FOR loop       188.92MHz
Integer FOR loop           103.48MHz
Trig/Log test             1764.10MHz
String manipulation        144.63MHz
Procedure call             173.86MHz
GOSUB call                 153.84MHz
Combined Average           346.00MHz

Compared with a 2.00MHz BBC B

There's one feature of that table which I don't understand at all. At first glance it's exactly what you would expect from BBC BASIC running on a 'modern' CPU, i.e. that the Trig/Log performance is disproportionally better than the other tests (by a big margin) because of the availability of an FPU with native instructions for those operations. But the Cortex-M0+ doesn't have an FPU, or indeed any floating point registers or instructions at all (at least, I didn't think it did)!

If the Trig/Log functions are having to be implemented with power-series or continued-fraction expansions, like they are in Sophie's BASICs, then the performance shouldn't be better than the other tests, it should be worse, because of being required to work to 64-bit precision rather than 40-bit. Yet if we believe your table the Trig/Log tests are running at about the same relative speed as they do on an x86 or ARM CPU with floating-point registers and an FPU. :shock:

I am mystified by this.

It certainly is an oddity. I didn't spot it as such, but what I did spot is the Real tests running faster than the Integer tests, which seemed odd.

Your released version, built with different tools and a slightly earlier version of sources, we'd suppose, reported this:

Code: Select all

>CH."speed"
BBC BASIC CPU Timing Program
Really real REPEAT loop     96.47MHz
Integer REPEAT loop         81.56MHz
Really real FOR loop       175.94MHz
Integer FOR loop            90.81MHz
Trig/Log test             1678.04MHz
String manipulation        182.78MHz
Procedure call             160.35MHz
GOSUB call                 142.63MHz
Combined Average           334.44MHz

Compared with a 2.00MHz BBC B

which is also interesting for the various differences.

(I'd be happy to start a new thread for these observations if you don't think they belong in this one.)

[hoglet]

It says (if I've transcribed it correctly):

Code: Select all

gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (15:7-2018-q2-6)

Assuming 2018 is the year that is quite old!

My "fresh" Raspberry Pi OS build has exactly the same version.

I agree that 7.3.1 is rather old now, but as it works, I would be tempted to stick with it.

Is it important that you and your co-developers create identical .uf2 files? If so, then you would need to agree on a common compiler version.

It's possible to re-build any version from source, but it's a rather slow/involved processes.

There is a later version (9.2.1) pre-built here:
https://github.com/vanbwodonk/gcc-arm-e ... f/releases
I've just tried this out, and it successfully compiles BBC Basic.

But honestly, unless you need to, I would stick to 7.3.1

Dave

[hoglet]

Here's some benchmarking of the different compiler versions, which is the only variable I'm changing here.

I'm using the Console version, not the GUI version (which may well overclock the Pico)

Three runs of each to check for benchmark consistency.

Conclusion: BBC Basic compiled with 9.2.1 runs ~3% faster than when compiled with 7.3.1.

7.3.1

Code: Select all

BBC BASIC for Pico Console v0.38
(C) Copyright R. T. Russell, 2021
>CH."speed"
BBC BASIC CPU Timing Program
Really real REPEAT loop     87.04MHz
Integer REPEAT loop         86.90MHz
Really real FOR loop       175.34MHz
Integer FOR loop            90.35MHz
Trig/Log test             1127.86MHz
String manipulation        168.01MHz
Procedure call             159.40MHz
GOSUB call                 131.57MHz
Combined Average           262.27MHz

Compared with a 2.00MHz BBC B
>RUN
BBC BASIC CPU Timing Program
Really real REPEAT loop     87.04MHz
Integer REPEAT loop         86.90MHz
Really real FOR loop       175.94MHz
Integer FOR loop            90.81MHz
Trig/Log test             1146.66MHz
String manipulation        168.01MHz
Procedure call             159.40MHz
GOSUB call                 131.57MHz
Combined Average           262.22MHz

Compared with a 2.00MHz BBC B
>RUN
BBC BASIC CPU Timing Program
Really real REPEAT loop     87.04MHz
Integer REPEAT loop         86.90MHz
Really real FOR loop       175.94MHz
Integer FOR loop            90.81MHz
Trig/Log test             1146.66MHz
String manipulation        168.01MHz
Procedure call             159.09MHz
GOSUB call                 131.57MHz
Combined Average           262.22MHz

Compared with a 2.00MHz BBC B
>

9.2.1

Code: Select all

BBC BASIC for Pico Console v0.38
(C) Copyright R. T. Russell, 2021
>CHAIN "speed"
BBC BASIC CPU Timing Program
Really real REPEAT loop     72.56MHz
Integer REPEAT loop         91.22MHz
Really real FOR loop       188.23MHz
Integer FOR loop           103.48MHz
Trig/Log test             1228.57MHz
String manipulation        100.90MHz
Procedure call             175.00MHz
GOSUB call                 152.54MHz
Combined Average           270.85MHz

Compared with a 2.00MHz BBC B
>RUN
BBC BASIC CPU Timing Program
Really real REPEAT loop     72.56MHz
Integer REPEAT loop         91.22MHz
Really real FOR loop       188.23MHz
Integer FOR loop           102.89MHz
Trig/Log test             1228.57MHz
String manipulation        101.04MHz
Procedure call             175.00MHz
GOSUB call                 152.54MHz
Combined Average           270.87MHz

Compared with a 2.00MHz BBC B
>RUN
BBC BASIC CPU Timing Program
Really real REPEAT loop     72.69MHz
Integer REPEAT loop         91.57MHz
Really real FOR loop       188.23MHz
Integer FOR loop           102.89MHz
Trig/Log test             1228.57MHz
String manipulation        100.90MHz
Procedure call             175.38MHz
GOSUB call                 152.54MHz
Combined Average           270.85MHz

Compared with a 2.00MHz BBC B
>

10.2.1

Code: Select all

Fails to compile due to multiple definitions of `libtop'

10.3.1

Code: Select all

Fails to compile due to multiple definitions of `libtop'

[hoglet]

A few more "SPEED" benchmark numbers, comparing the Console and GUI version (Git Commit d219854f)

Console Version

(Pico is running at the default speed of 125MHz)

7.3.1 - 262.27 MHz

9.2.1 - 270.85 MHz

10.3.1 - 274.37 MHz (after locally fixing the libtop compile error)

GUI Version

(Pico is overclocked to 150MHz)

7.3.1 - 340.76 MHz

9.2.1 - 347.86 MHz

10.3.1 - 364.69 MHz (after locally fixing the libtop compile error)

These numbers are higher than I would expect given the overclock, so possibly more code is running from RAM?

[Deleted User 9295]

Code: Select all

Fails to compile due to multiple definitions of `libtop'

What does "multiple definitions" mean in this context? These are the only occurrences of libtop in the sources at my upstream repository:

Code: Select all

---------- BBEXEC.C
                if((&al < (signed char *)libtop + 0x800) && (&al >= (signed char *)userRAM))
                                                libtop = ebx ;
                                libtop = newtop ;
                                        libtop = n ;

---------- BBMAIN.C
        libtop = edx ;

---------- BBPICO.C
void *libtop;

[hoglet]

What does "multiple definitions" mean in this context? These are the only occurrences of libtop in the sources at my upstream repository:

I suspect the problem is line 12 of include/BBC.h:

Code: Select all

void *libtop;

This line is defining libtop. If this header file is included in multiple places, there will be multiple definitions.

One of the changes in GCC 10.x is to now report this as an error by default:
https://gcc.gnu.org/gcc-10/porting_to.html

C language issues

Default to -fno-common

A common mistake in C is omitting extern when declaring a global variable in a header file. If the header is included by several files it results in multiple definitions of the same variable. In previous GCC versions this error is ignored. GCC 10 defaults to -fno-common, which means a linker error will now be reported. To fix this, use extern in header files when declaring global variables, and ensure each global is defined in exactly one C file. If tentative definitions of particular variables need to be placed in a common block, __attribute__((__common__)) can be used to force that behavior even in code compiled without -fcommon. As a workaround, legacy C code where all tentative definitions should be placed into a common block can be compiled with -fcommon.

int x; // tentative definition - avoid in header files

extern int y; // correct declaration in a header file

[Deleted User 9295]

This line is defining libtop. If this header file is included in multiple places, there will be multiple definitions.

I see (I think); I thought multiple non-conflicting definitions were OK. It seems entirely wrong to me that a feature which previously didn't even result in a warning should now throw a fatal error! That kind of transition is poor practice, in my book.

The recommended 'fix' seems to be to add extern in the header file, but that won't work in this case because it would mean that when I build a non-Pico version but with the libtop feature enabled (which I need to do for testing purposes), libtop itself won't be defined anywhere!

Fundamentally the issue is that there isn't a direct correspondence between PICO being #defined and bbpico.c being included in the build. If there was the extern fix would work, but in practice I want to be able to #define PICO but not include bbpico.c,

There's probably some way this could be reconciled, but it's easier just to say it can't be compiled with GCC 10.

[hoglet]

I see (I think); I thought multiple non-conflicting definitions were OK. It seems entirely wrong to me that a feature which previously didn't even result in a warning should now throw a fatal error! That kind of transition is poor practice, in my book.

You are correct...

Non-conflicting definitions (termed tentative definitions) were (and still are) allowed n certain limited circumstances. The rational was for compatibility with very old C code that pre-dated the addition of the extern keyword. But they were (and are) only allowed within the same translational unit (i.e. C file).

GCC was apparantly very lax at enforcing this latter part.

You can still get the old behavior in GCC 10 using the -fcommon flag.

I agree with your observation that it would have been better to first make this a warning!

Dave

[hoglet]

Fundamentally the issue is that there isn't a direct correspondence between PICO being #defined and bbpico.c being included in the build. If there was the extern fix would work, but in practice I want to be able to #define PICO but not include bbpico.c,

Can't the definition just be moved from bbpico.c to bbmain.c, which I think is always linked. There are other global variables defined there.

There's probably some way this could be reconciled, but it's easier just to say it can't be compiled with GCC 10.

Very soon GCC 10 will be the default with newer Linux distributions.

I think it's better to address this now, if that can be done in a straightforward manner.

Dave

[hoglet]

Performance numbers updated to include 10.3.1:
viewtopic.php?p=339841#p339841

[Deleted User 9295]

Very soon GCC 10 will be the default with newer Linux distributions.

Maybe, but I won't be able to upgrade to "newer" Linux distros anyway, because I'm distributing 'universal' Linux binaries that have to be built with old versions of the libraries. Currently I can't even use Ubuntu 20.04 LTS as my build platform, let alone anything newer, I have to use 18.04 LTS to make a binary that will run on every likely target machine. Of course this is a craziness specific to Linux but I have to live with it.

I think it's better to address this now, if that can be done in a straightforward manner.

Whilst it may be straightforward to address this in the console editions, I suspect it wouldn't be at all easy to adapt the (more important) BBCSDL GUI editions, indeed I'm not even sure that SDL 2.0 itself (plus SDL2_ttf, SDL2_net and SDL2_gfx) will successfully compile with GCC 10. I've also got to consider Box2D which is written in C++.

As I've often said, what may seem to be a trivial change isn't for me, because of the number of editions I build. For example if I make a change to bbmain.c I've got to rebuild and test every single edition of BBC BASIC for SDL 2.0 and the BBC BASIC Console Mode editions, which means something like nine GUI builds and seven console builds, on at least eight different hardware platforms!

[Deleted User 9295]

what I did spot is the Real tests running faster than the Integer tests, which seemed odd.

Except that they don't run faster, in an absolute sense: the figures reported by speed.bbc are relative to the BBC Micro! So all it is saying is that, relatively speaking, floating-point operations have benefitted from the faster CPU in the Pico more than integer operations have, and that doesn't surprise me at all.

It can for example be explained by recognising that moving from 32-bit integers to 64-bit integers (on a 32-bit CPU) is likely to approximately double the execution time of simple operations such as addition, subtraction and multiplication. By contrast moving from 40-bit floats to 64-bit floats probably won't involve a penalty of as much as that. So integer arithmetic will see a bigger hit.

To see how the speed of integer and floating-point operations compare in an absolute sense on the Pico one can run the timing.bbc program. Here are the relevant results that I get:

Code: Select all

 A%=B%+C%:                12939 ns 
 A%=B%-C%:                12916 ns
 A%=B%*C%:                12683 ns 

 A%%=B%%+C%%:             18399 ns
 A%%=B%%-C%%:             18367 ns
 A%%=B%%*C%%:             18107 ns
 
 A=B+PI:                  19286 ns 
 A=B-PI:                  19374 ns
 A=B*PI:                  19500 ns

[BigEd]

Ah, of course, relative speeds! That makes a great deal of sense.

About the high speeds for log and trig, I believe the Pico's inbuilt firmware offers optimised library routines. (Ah yes, see here.) So I would expect those to run at an impressive rate, whereas any reimplementation using the multiply and divide would run at a more pedestrian rate. Whereas, on the Beeb, the arithmetic used within the transcendental functions is the same arithmetic used for multiply and divide.

About having to build Linux binaries on older distributions - I well remember we needed to do this in our engineering environment at work. Until such time as the oldest distribution was retired, we needed to build packages on that oldest distribution, for use everywhere. (Although the argument doesn't apply to Pico builds, as they are self-contained once built, I well understand the difficulty of managing so many diverse builds on diverse environments. The <10% speedup from the latest compiler isn't worth too much pain - and in any case, the very interested party can always build their own. Possibly there are source-level tweaks which can improve performance anyway. And there's always overclocking!)

[Deleted User 9295]

Comment deleted.

[davidb]

But these "optimised routines" can only use the same ARM Cortex-M0+ instructions as anybody else can, surely; they're not some 'secret' facility built into the CPU chip that only the C compiler can access! So I assume they are based on the regular integer instructions, just like the floating-point routines are in Sophie's BASICs and mine, before an FPU became available in the CPU.

The Raspberry Pi Pico C/C++ SDK document available from here says this in section 2.7.2 ("Floating-point Support"):

The SDK provides a highly optimized single and double precision floating point implementation. In addition to being
fast, many of the functions are actually implemented using support provided in the RP2040 bootrom. This means the
interface from your code to the ROM floating point library has very minimal impact on your program size, certainly using
dramatically less flash storage than including the standard floating point routines shipped with your compiler.

It also talks about using fixed point representations and covers some of the assumptions and limitations of the implementation. I don't know where you would find the source code of the "bootrom" to investigate further.

[Deleted User 9295]

Comment deleted.

[hoglet]

I don't know where you would find the source code of the "bootrom" to investigate further.

Try here:
https://github.com/raspberrypi/pico-boo ... er/bootrom

The source for the single precison FP library is here I think:
https://github.com/raspberrypi/pico-boo ... /mufplib.S

And the double precision is here:
https://github.com/raspberrypi/pico-boo ... b-double.S

Dave

[davidb]

Try here:
https://github.com/raspberrypi/pico-boo ... er/bootrom

Thanks. I didn't scroll down far enough in the repository list, it seems.

[Deleted User 9295]

Comment deleted.

[dp11]

Do also remember that RP2040 has a hardware divider which most cortex M0 implementations don't. This can skew the implementation methods to get higher performance.

[Deleted User 9295]

Comment deleted.

[hoglet]

Do we know whether GCC can take advantage of it in compiled C code such as BBC BASIC? Does the floating-point code in the bootrom use it?

My understanding is the / and % operators in C will indeed make use of the hardware divider

I think it's also used for the division when computing TAN(x) = SIN(X)/COS(X).

The C/C++ SDK Reference says:

The SDK includes optimized 32- and 64-bit division functions accelerated by the RP2040 hardware divider, which are
seamlessly integrated with the C / and % operators. The SDK also supplies a high level API which includes combined
quotient and remainder functions for 32- and 64-bit, also accelerated by the hardware divider.
See Figure 1 and Figure 2 for 32-bit and 64-bit integer divider comparison.

Follow this link to see the figures:
https://datasheets.raspberrypi.com/pico ... df#page=27

Dave

[Deleted User 9295]

I don't think it is version 0.37, because Bill rebuilt it after the v0.38 changes

I have replaced the 'merged' (single uf2 file) console edition for the Pico with one that reports correctly as v0.38; hopefully this will reduce the potential for confusion. There shouldn't be any other functional changes, although as discussed it may not have been compiled with exactly the same version of GCC as Bill's.