BBC BASIC - 64 bit integer support, long string support
tymaja (278) 172 posts |
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!) |
Alan Adams (2486) 1147 posts |
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. |
Bryan Hogan (339) 589 posts |
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 |
Stuart Swales (8827) 1349 posts |
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? |
Rick Murray (539) 13806 posts |
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… |
Clive Semmens (2335) 3276 posts |
But is it three %s for 96-bit integers, or for 128-bit integers? |
Dave Higton (1515) 3497 posts |
I have thought for many years that %% was the logical choice for 64 bit integers. |
James Pankhurst (8374) 126 posts |
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… |
Clive Semmens (2335) 3276 posts |
That was exactly the thinking behind my post, James! 8~) |
Steve Pampling (1551) 8155 posts |
You could be very British about it and do the proper million million :) |
Rick Murray (539) 13806 posts |
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. 1 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. |
Clive Semmens (2335) 3276 posts |
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… |
Rick Murray (539) 13806 posts |
Billion – continued in Aldershot |
Kevin (224) 322 posts |
I would like strings greater than 256 charactes |
Dave Higton (1515) 3497 posts |
As would many of us, I suspect. |
Clive Semmens (2335) 3276 posts |
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. |
Dave Higton (1515) 3497 posts |
64 bit integers will become necessary when RISC OS gains the ability to handle files over 4 GiB. |
Clive Semmens (2335) 3276 posts |
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. |
GavinWraith (26) 1563 posts |
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. |
Clive Semmens (2335) 3276 posts |
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. |
GavinWraith (26) 1563 posts |
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. |
Clive Semmens (2335) 3276 posts |
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. |
Sveinung Wittington Tengelsen (9758) 237 posts |
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) |
Clive Semmens (2335) 3276 posts |
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. |
Jean-Michel BRUCK (3009) 351 posts |
Hi, |