BBC BASIC - 64 bit integer support, long string support

I am sure this has been mentioned before, but I am wondering:

Have we made any decisions on this? It would be a good addition to BASIC;

There would be issues with overflow converting back to 32 bit integer numbers. On the flipside, implementing 64 bit support with a ‘new’ variable type would allow old programs to still run, with % still representing 32-bit (signed…) integers;

Have there been any thoughts on what ‘character’ we would use for 64-bit integers? % is for 32-bit, $ is for strings (~252 bytes)

Also – long string support – any thoughts on how this might be added.

I am willing to have a go at adding 64-bit integer support to BASIC, but with the way ARM BBC BASIC is written (a true masterpiece of coding!), one would need to know how you intend to encode the variable type from the outset (%% may be nice, but a single symbol is probably much, much easier to encode!)

I believe Basalt does this for ARM Basic, and BBC Basic for Windows also has it. It would seem sensible to adopt the same scheme as either of those.

Any additions should use the same syntax as Richard Russell’s BBC BASIC versions. Or just port his version back to RISC OS!

Lots of info in this talk by Richard – https://www.youtube.com/watch?v=LZqeA0Koxxo

I’d keep any long string support separate for now; it should be possible to add a%% 64-bit integer support to current BASIC without compatibility breaking?

While I can understand having two %s for an integer twice as large, I do wonder about the potential for typos over how many %s…

But is it three %s for 96-bit integers, or for 128-bit integers?

I have thought for many years that %% was the logical choice for 64 bit integers.

But is it three %s for 96-bit integers, or for 128-bit integers?

This is up there with billion, is it a proper million million or the currently used thousand million?

So, long long long or long long long long…

This is up there with billion, is it a proper million million or the currently used thousand million?

That was exactly the thinking behind my post, James! 8~)

You could be very British about it and do the proper million million :)

The way the Americans do it sort of makes sense. Each time (to billion, to trillion…) you are adding three digits to the number.

In the UK, traditionally, we went from 1,000,000 straight to 1,000,000,000,000.
However now that millions are kind of “meh” ¹, we need non-cumbersome ways of referring to numbers that might once have been unthinkably massive.

¹ Once upon a time – “The sixty-four thousand dollar question”, and gameshows had prizes measured in mere thousands – the prize in Treasure Hunt (original series) and the similar-ish Interceptor was a mere £1,000… Follow-ups on the footnote → Aldershot.

The way the Americans do it sort of makes sense.

Either way makes perfect sense. What doesn’t make sense – except for those who actually want to obfuscate stuff (right wing economists…?) – is having a confusion between the two…

Billion – continued in Aldershot

I would like strings greater than 256 charactes

I would like strings greater than 256 charactes

As would many of us, I suspect.

I can more imagine wanting long strings than 64-bit integers, personally. If I was doing anything these days with big integers, I’d want integers of arbitrary length, rather than just 64 bits – stuff I used to do in embedded assembler, but haven’t actually touched since the 26 → 32-bit transition.

64 bit integers will become necessary when RISC OS gains the ability to handle files over 4 GiB.

Ah, true. Whereas my use for arbitrary length integers is pretty niche – and it might be quite a while before RAM or even offline storage runs out of 64-bit addresses.

I’d want integers of arbitrary length

Have you tried Zahl ? It has both 32-bit integers and arbitrary size integers. I made it to atone for giving up on maintaining Nick Craig-Wood’s BigNum module (1989), so that there would at least be something for RISC OS users wanting to experiment with big integers. There were some bugs in BigNum, and debugging ARM assembler is painful. By contrast, Zahl uses Michael J. Fromberger’s C library, imath , with Lua bindings by Luiz Henrique de Figueiredo.

Have you tried Zahl ?

No – “If I was doing anything these days with big integers…[I] haven’t actually touched since the 26 → 32-bit transition.”

When, long ago, I was doing things with big integers, I wanted to use assembler for the sake of speed. I suppose were I to do anything with them again I’d still want the maximum speed I could possibly get, and end up writing 64-bit ARM assembler, not using any high level language at all. But in reality I’m unlikely ever to do such stuff again.

The advantage of the BigNum module was that any programming language with the equivalent of BASIC’s SYS could exploit it. The disadvantage was that ARM assembler was not very readable. One of the first bugs I came across was in the code for calculating square roots. The natural algorithm for sqrt(x) to use is Newton’s method: make a guess, say y = 1, then repeat y → (y + x/y)/2 until y*y – x is sufficiently small. This is OK for floating point numbers but not for integers. You will find that when x is one less than a power of two something nasty happens. The advantage of using imath was that it has been thoroughly debugged, and I doubt whether there is much to be gained by hand assembly over the GNU C compiler.

I doubt whether there is much to be gained by hand assembly over the GNU C compiler.

Probably not, but I don’t think that existed when I wrote my stuff, and I’m not a C programmer anyway. I’m familiar with the limitations of Newton’s method – or was! I don’t even remember exactly what I did about it now – and used it not merely for square roots, but for n th roots.

Technically speaking, using assembler to write programs instantly put said software in amber, which started (for our crowd) when Arm Ltd. ditched 32-bit support in their latest CPU/(GPU?) architecture update. Meaning their market for 32-bit functionality is so minuscule that space used by 32-bit support is thousands of times less profitable since new 64-bit functionality can be added.

Which is the key reason for my 1-man campaign for RISC OS’ 64-bitification by some cunning means. Github? Pensioners? Crowdfunded?

Anybody happen to sell their Arm shares? 8)

I sold the last of my ARM shares as soon as the options matured after I retired in 2007.

I’ve not written any assembler in anger since the 26 → 32-bit transition – just loads of tiny bits to check my understanding when I was documenting it all. I’m unlikely ever to write any ever again, and if I do it’s most likely to be 64-bit instructions.

Hi,
Just for fun!
2^32 = 4294967296
2^64 = 18446744073709551616
2^128 = 340282366920938463463374607431768211456
Sum = 340282366920938463481821351509772730368