## Introduction to BBC BASIC

RichardRussell
Posts: 578
Joined: Thu Jun 21, 2012 10:48 am

### Re: Introduction to BBC BASIC

For language comparison purposes, here's a BBC BASIC version of the Fast Fibonacci program under discussion in another thread:

Code: Select all

``````      REM based on https://www.nayuki.io/res/fast-fibonacci-algorithms/fastfibonacci.py

@% = &1414
PRINT FN_Lhs_Fibonacci(92)
END

DEF FN_Lhs_Fibonacci(n)
LOCAL a, b
IF n = 0 THEN = 0
a = FN_Lhs_Fibonacci(n >> 1)
b = FN_Rhs_Fibonacci(n >> 1)
IF n AND 1 THEN = a * a + b * b
= a * (b + b - a)

DEF FN_Rhs_Fibonacci(n)
LOCAL a, b, d
IF n = 0 THEN = 1
a = FN_Lhs_Fibonacci(n >> 1)
b = FN_Rhs_Fibonacci(n >> 1)
d = a * a + b * b
IF n AND 1 THEN = a * (b + b - a) + d
= d
``````
92 is the largest parameter for which a precise result is returned (BBC BASIC's integers are 64-bits). The execution time is too short to measure accurately, but on a Raspberry Pi 3 it's about 0.003 seconds.

Heater
Posts: 13116
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Introduction to BBC BASIC

That's great. But for such small numbers isn't faster to do it with a naive iterative loop?

RichardRussell
Posts: 578
Joined: Thu Jun 21, 2012 10:48 am

### Re: Introduction to BBC BASIC

Heater wrote:
Tue Apr 16, 2019 8:49 am
That's great. But for such small numbers isn't faster to do it with a naive iterative loop?
Possibly. As I said, the purpose was for language comparison with the Python original and the ScriptBasic version listed in another thread. If you don't need a precise answer you can of course specify a much larger parameter, when the speed benefit of the 'fast' algorithm may be more significant. For example FN_Lhs_Fibonacci(9999) prints 2.079360823713349806E2089 and is still very fast!

A nice thing about 'my' BBC BASICs is the automatic promotion from integer to floating point when the value gets out of range. This is a feature of 'traditional' BASICs which have a single numeric variant data type. By contrast Acorn's versions (and I assume Brandy as well) don't work like that: a variable with no suffix is always floating-point and may suffer both a lack of precision and slower execution. If you run the code I listed in Matrix Brandy it prints 7540113804746346500 rather than the correct 7540113804746346429 from mine.

RichardRussell
Posts: 578
Joined: Thu Jun 21, 2012 10:48 am

### Re: Introduction to BBC BASIC

RichardRussell wrote:
Tue Apr 16, 2019 11:09 am
prints 2.079360823713349806E2089 and is still very fast!
On a PC, I should add, not a Raspberry Pi which does not have the floating-point range. On a RPi the furthest you can go without getting a 'Number too big' error is FIbonacci(1476).

jahboater
Posts: 4606
Joined: Wed Feb 04, 2015 6:38 pm

### Re: Introduction to BBC BASIC

RichardRussell wrote:
Tue Apr 16, 2019 11:10 am
RichardRussell wrote:
Tue Apr 16, 2019 11:09 am
prints 2.079360823713349806E2089 and is still very fast!
On a PC, I should add, not a Raspberry Pi which does not have the floating-point range. On a RPi the furthest you can go without getting a 'Number too big' error is FIbonacci(1476).
The Raspberry Pi in 64-bit mode provides 128-bit floating point (IEEE binary128 - quad precision).
This has a 15-bit exponent - the same range as Intels 80-bit floats, but with 33 decimal digits of precision!

LDBL_MAX is: 1.18973149535723176508575932662800702e+4932

plugwash
Forum Moderator
Posts: 3439
Joined: Wed Dec 28, 2011 11:45 pm

### Re: Introduction to BBC BASIC

Note that while arm decided to make long double 128 bits in their arm64 ABI, no current arm core has support for 128 bit floating point in hardware. So "long double" calculations on arm64 will be done with a software implementation.

jahboater
Posts: 4606
Joined: Wed Feb 04, 2015 6:38 pm

### Re: Introduction to BBC BASIC

plugwash wrote:
Tue Apr 16, 2019 11:43 am
Note that while arm decided to make long double 128 bits in their arm64 ABI, no current arm core has support for 128 bit floating point in hardware. So "long double" calculations on arm64 will be done with a software implementation.
Yes.
I have to say it is a very good implementation.
You can do the same on Intel with -mlong-double-128 but I found a few bugs which were not present in the ARM version.

Its better than 32-bit mode where long-double is 64-bits - the same as double.

RichardRussell
Posts: 578
Joined: Thu Jun 21, 2012 10:48 am

### Re: Introduction to BBC BASIC

plugwash wrote:
Tue Apr 16, 2019 11:43 am
Note that while arm decided to make long double 128 bits in their arm64 ABI, no current arm core has support for 128 bit floating point in hardware. So "long double" calculations on arm64 will be done with a software implementation.
There isn't currently a 64-bit build of BBC BASIC for the RPi, but the iOS build is 64-bits (compiled with clang). However I doubt that it would be sensible for BBC BASIC to make use of the software 128-bit long-double type: it would hit performance for a start.

If it gets implemented in silicon one day then that would be another matter, but compatibility with the x86 editions of BBC BASIC would depend on whether one can just throw away the surplus bits to obtain an Intel-compatible 80-bit data type.

Is there any practical application in science or engineering which needs more than 20 decimal digits of precision?

Heater
Posts: 13116
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Introduction to BBC BASIC

Engineering yes. Cryptography. Not that one will be doing that in BASIC.

RichardRussell
Posts: 578
Joined: Thu Jun 21, 2012 10:48 am

### Re: Introduction to BBC BASIC

Heater wrote:
Tue Apr 16, 2019 1:51 pm
Engineering yes. Cryptography.
I was meaning specifically floating point numbers (which was the context here): I assume that cryptography would normally be using integers, sometimes very big integers indeed! A language that natively supports arbitrary-precision integers, such a Liberty BASIC, may be the best choice for that. On the odd occasion that I've tackled cryptographic problems in BBC BASIC (why not?) I've tended to call one of the arbitrary-precision libraries, such as HIME. I wrote a library, HIMELIB.BBC, to make that easier.

Heater
Posts: 13116
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Introduction to BBC BASIC

Cool.

I think a high level language should do the same thing on whatever platform is used.

C, for example, has a lot of platform dependent things. The size of int for example. A language like BASIC should not.

Seems that is almost impossible when it comes to floating point types but one should try.

ejolson
Posts: 3424
Joined: Tue Mar 18, 2014 11:47 am

### Re: Introduction to BBC BASIC

RichardRussell wrote:
Tue Apr 16, 2019 2:37 pm
Heater wrote:
Tue Apr 16, 2019 1:51 pm
Engineering yes. Cryptography.
I was meaning specifically floating point numbers (which was the context here): I assume that cryptography would normally be using integers, sometimes very big integers indeed! A language that natively supports arbitrary-precision integers, such a Liberty BASIC, may be the best choice for that. On the odd occasion that I've tackled cryptographic problems in BBC BASIC (why not?) I've tended to call one of the arbitrary-precision libraries, such as HIME. I wrote a library, HIMELIB.BBC, to make that easier.
Is there any possibility of releasing your freeware compiler Liberty Basic Booster as open source or getting it to run on the Raspberry Pi?

RichardRussell
Posts: 578
Joined: Thu Jun 21, 2012 10:48 am

### Re: Introduction to BBC BASIC

ejolson wrote:
Tue Apr 16, 2019 3:23 pm
Is there any possibility of releasing your freeware compiler Liberty Basic Booster as open source or getting it to run on the Raspberry Pi?
As far as open-sourcing LBB is concerned, that has been suggested and discussed previously. Technically it's perfectly straightforward, LBB is written in BBC BASIC and consists of just two programs: the IDE/translator lb2bbc.bbc and the runtime library lblib.bbc. These could easily be published, and LBB built by anyone, using BBC BASIC for Windows.

The difficulties are rather ones of privacy and security. Firstly, publishing the source would reveal the technology behind how the user's BASIC program is compressed and encrypted in the 'compiled' EXE, making it much easier to reverse-engineer LBB's executables. Secondly, LBB contains code to decrypt the so-called 'tokenised' (.TKN) file format that Carl Gundel's original Liberty BASIC uses, which would allow anybody to reverse-engineer an application built in LB.

In principle it would be possible to redact these two components and publish the rest of the code, but that would result in a non-working application of limited value.

As regards "getting it to run on the Raspberry Pi", unfortunately both LB and LBB are wrappers around the Windows (GDI32) API. Indeed that's how it was possible to achieve such a remarkable degree of compatibility between my 'clone' (LB Booster) and the original (Liberty BASIC): a lot of the critical functionality is simply that of Windows. In the absence of that API layer on other platforms there's no practical way of porting it (you'd need to reproduce a significant proportion of the GDI32 functionality from scratch).

RichardRussell
Posts: 578
Joined: Thu Jun 21, 2012 10:48 am

### Re: Introduction to BBC BASIC

Heater wrote:
Tue Apr 16, 2019 2:42 pm
C, for example, has a lot of platform dependent things. The size of int for example. A language like BASIC should not.
I absolutely agree, in principle. Indeed I would argue that one of BBC BASIC's Unique Selling Points is the ability to write programs which run without modification on the full range of supported disktop and mobile platforms (Windows, MacOS, Linux, Raspberry Pi, Android, iOS) even if the program is leveraging what would usually be considered platform-specific features such as 3D graphics, audio input and output, network access, shader programming and so on. I doubt that there are many languages around that can offer that degree of cross-platform compatibility.

But it's not perfect, and as you say the size of BBC BASIC's native floating point data type is a case in point (80-bits extended precision on x86 CPUs, 64-bits double precision on ARM CPUs). When I started developing BBC BASIC for SDL 2.0 I didn't realise that the ARM didn't support 80-bits floats. I knew that the original ARM made provision for floating-point extensions (then implemented in software) which did include that data type, and I knew that Intel's rationale for providing that data type in the FPU was to allow 'chained' floating-point calculations which didn't lose precision even if they involved several steps.

So when I came to compile BBCSDL on ARM I was surprised to discover the absence of 80-bit floats, and had to work around that shortcoming. In practice the resulting incompatibility is small: the default numeric type written-to and read-from data files is still the old 40-bit (32-bit mantissa, 8-bit exponent) format used in the BBC Micro and my early BASICs, so that isn't affected. Suffixless ('variant') variables and arrays still allocate 10-bytes per member, even when compiled on ARM. And 64-bit integers can be stored in variants even when (as on ARM) the mantissa of the native floating-point type isn't big enough. Finally, you can force the use of 64-bit doubles, on all platforms, by adding a hash suffix to the variable name.

But it would have been better if ARM had supported 80-bit floats, and I'm still surprised that they don't, especially when the original Acorn ARM architecture anticipated that they would.

RichardRussell
Posts: 578
Joined: Thu Jun 21, 2012 10:48 am

### Re: Introduction to BBC BASIC

Heater wrote:
Tue Apr 16, 2019 2:42 pm
C, for example, has a lot of platform dependent things. A language like BASIC should not.
I should perhaps add that some of the very features that give BBC BASIC its strength also mitigate against cross-platform compatibility. One is the low-level indirection operators , which are comparable to the * operator in C. Because you can directly access memory via a pointer in BBC BASIC, something that very few BASICs support, that instantly introduces a potential incompatibility of needing to use a 64-bit pointer on a 64-bit architecture but only a 32-bit pointer on a 32-bit architecture.

Of course programs don't always need to make use of this feature, and it's better if they don't (adding support for structures in my versions made them less necessary), but it's another area where you need to keep your wits about you if you are writing BBC BASIC programs to run on a wide range of platforms. One can argue about the relative pros and cons of those language features, but they've been there since 1981 and it wouldn't be 'BBC BASIC' if they were removed!

jahboater
Posts: 4606
Joined: Wed Feb 04, 2015 6:38 pm

### Re: Introduction to BBC BASIC

RichardRussell wrote:
Tue Apr 16, 2019 4:07 pm
But it would have been better if ARM had supported 80-bit floats, and I'm still surprised that they don't, especially when the original Acorn ARM architecture anticipated that they would.
Could you just stick with 64-bit floating-point (IEEE binary64) - doubles in C, for the common floating point type?
It is universally available and with a range up to 10^308 and at least 15 decimal digits of precision its enough for most things.
And it is portable to most platforms.

In an earlier post it was noted that the estimated total number of photons emitted by all the stars in the universe since the universe began, was around 4e84 - easily representable in a standard 64-bit double.
Last edited by jahboater on Tue Apr 16, 2019 4:48 pm, edited 1 time in total.

jahboater
Posts: 4606
Joined: Wed Feb 04, 2015 6:38 pm

### Re: Introduction to BBC BASIC

RichardRussell wrote:
Tue Apr 16, 2019 4:30 pm
instantly introduces a potential incompatibility of needing to use a 64-bit pointer on a 64-bit architecture but only a 32-bit pointer on a 32-bit architecture.
Why? "char *ptr" in C works for all platforms without any change needed.

jahboater
Posts: 4606
Joined: Wed Feb 04, 2015 6:38 pm

### Re: Introduction to BBC BASIC

Heater wrote:
Tue Apr 16, 2019 2:42 pm
C, for example, has a lot of platform dependent things. The size of int for example. A language like BASIC should not.
I tend to assume that int is 32-bits and don't bother with int32_t (I know some old sparc platforms had int as 64-bits, but they are obsolete).
Can you mention any modern platforms where int is not 32-bits? I may have to change my code.
Heater wrote:
Tue Apr 16, 2019 2:42 pm
Seems that is almost impossible when it comes to floating point types but one should try.
Its easy with floating point - just stick with float or double and it should work anywhere.
IEEE floating point is very close now to becoming universal.

RichardRussell
Posts: 578
Joined: Thu Jun 21, 2012 10:48 am

### Re: Introduction to BBC BASIC

jahboater wrote:
Tue Apr 16, 2019 4:40 pm
Why cant you just stick with 64-bit floating-point (IEEE binary64) - doubles in C, for the common floating point type?
It's principally the issue of cascading multiple operations causing a loss of precision. A compiled language like C can recognise that a floating-point calculation involves many separate steps, and it can arrange that the intermediate values be stored in the 80-bit FPU registers, so that the final result retains the full precision of the 64-bit 'double' variable in which it will be stored. In BBC BASIC intermediate values are held with the precision of the regular floating-point variables, which if they were 64-bits would imply a cumulative loss of precision as the number of steps increases.

So to make it possible to perform calculations in BBC BASIC to the maximum precision that the CPU/FPU is capable of, floating-point varaibles are 80-bits, not 64. But as I said it's possible to force 64-bits by adding a hash suffix.
Why? "char *ptr" in C works for all platforms without any change needed.
In C variables are implicitly typed: when compiled on a 32-bit architecture ptr becomes a 32-bit type but when compiled on a 64-bit architecture ptr is 64-bits. In BBC BASIC, like many (but not all) BASICs, variables are explicitly typed by means of a suffix character, so the programmer has to know to use a 64-bit type if it is to hold an address. Of course he could choose to use a 64-bit type always for pointers, and that would work on both 32-bit and 64-bit architectures, but if he's used to programming on a BBC Micro or a RISC PC or in Brandy BASIC he won't have got into the habit of doing that (none of those support 64-bit pointers anyway).

jahboater
Posts: 4606
Joined: Wed Feb 04, 2015 6:38 pm

### Re: Introduction to BBC BASIC

RichardRussell wrote:
Tue Apr 16, 2019 5:01 pm
It's principally the issue of cascading multiple operations causing a loss of precision. A compiled language like C can recognise that a floating-point calculation involves many separate steps, and it can arrange that the intermediate values be stored in the 80-bit FPU registers, so that the final result retains the full precision of the 64-bit 'double' variable in which it will be stored.
OK. That was the case for 32-bit x86.
Also very handy because you can store any 64-bit integer, signed or unsigned, in an 80-bit float without any loss.

It caused problems with naive users because, depending on the level of optimization, the points at which the 80-bit intermediate results were rounded down to 64-bits for storage varied - giving slightly differing results from time to time.

That's all gone now.
On modern 64-bit x86 platforms everything is done with 64-bit floating point only. The old stack based x87 FPU is deprecated by Intel, and not used by compilers anymore (unless you specifically ask for it). The reason is dramatically faster speeds, and ease of use - instead of a stack, the register file is laid out just like the integer registers, and with AVX, three address instructions are available.

I find it very sad that all the modern FPU's (SSE, AVX, NEON etc) do not support any precision greater than 64-bits

Even more bizzare is that on both x86 and ARM the 64-bit floats are just lane zero of a wide SIMD register - even on AVX512!

Heater
Posts: 13116
Joined: Tue Jul 17, 2012 3:02 pm

### Re: Introduction to BBC BASIC

jahboater,
Why? "char *ptr" in C works for all platforms without any change needed.
Potential problem: Is that char signed or unsigned? If it's pointing into anything other than a byte wide value there may be endianness issues.
Can you mention any modern platforms where int is not 32-bits?
Arduino. That is to say avr-gcc. There are still many C compilers around for which int is 16 bits.
Its easy with floating point - just stick with float or double and it should work anywhere.
IEEE floating point is very close now to becoming universal.
Yes but when calculating with the hidden bits of precision on Intel your results may well be different from the same calculation done on systems that are strictly IEEE compliant.

RichardRussell
Posts: 578
Joined: Thu Jun 21, 2012 10:48 am

### Re: Introduction to BBC BASIC

jahboater wrote:
Tue Apr 16, 2019 5:21 pm
That's all gone now.
On modern 64-bit x86 platforms everything is done with 64-bit floating point only ... unless you specifically ask for it
True, and with Microsoft's compilers you can't even "ask for it": they give you only 64-bit precision even if you explicitly specify 'long double' type! But that's no reason for BBC BASIC to follow suit; it's a challenge for all BASICs to distinguish themselves from the crowd and this is one way that I try to do so.

jahboater
Posts: 4606
Joined: Wed Feb 04, 2015 6:38 pm

### Re: Introduction to BBC BASIC

Heater wrote:
Tue Apr 16, 2019 5:40 pm
Yes but when calculating with the hidden bits of precision on Intel your results may well be different from the same calculation done on systems that are strictly IEEE compliant.
No. Those hidden bits are never used anymore. Not since Intel PC's became 64-bit.
Its always IEEE binary64 on all modern platforms, even for intermediate results.

You are right for legacy 32-bit mode only, but when did you last see an Intel PC in 32-bit mode? Its not common.

jahboater
Posts: 4606
Joined: Wed Feb 04, 2015 6:38 pm

### Re: Introduction to BBC BASIC

RichardRussell wrote:
Tue Apr 16, 2019 5:48 pm
But that's no reason for BBC BASIC to follow suit; it's a challenge for all BASICs to distinguish themselves from the crowd and this is one way that I try to do so.
I admire you for that. I had exactly the same attitude for years. But it eventually became too much and I gave up.
There were many little annoying things. The invaluable valgrind run-time check tool emulates the x86 instruction set and checks every single instruction. Except that it no longer supports legacy x87 instructions. It is very happy with modern SSE and AVX instructions though.
Also the "long double" type changes size all the time - we have 64-bits on 32-bit ARM, 128-bits on 64-bit ARM, 64, 80, or 128 bits on Intel.
Sometimes its in software, sometimes in hardware which has all sorts of implications (only hardware sets all the exceptions correctly).
The path of least resistance is 64-bits only!!!

John_Spikowski
Posts: 1336
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA

### Re: Introduction to BBC BASIC

I think BBC BASIC and ScriptBasic address different needs. I don't see the two BASIC languages having to compete for users.