What would AArch64 BASIC look like?
Jeffrey Lee (213) 6048 posts |
Question is in the title. If/when we make an AArch64 version of RISC OS, what will happen to BASIC?
I know that some of RISC OS BASIC’s relatives (BBC BASIC for Windows, Matrix Brandy, etc.) have struggled with the issues of supporting 64bit pointers/integers and different syscall methods, so it’s probably worth looking at the solutions they’ve come up with. To make software development using BASIC easier we’ll want to support cross-assembly – the ability for the 64bit version of BASIC to assemble 32bit code, and vice-versa. It probably makes sense to implement this via a plugin system (an idea that’s come up once or twice before). |
Chris (121) 472 posts |
The great thing about BASIC is, as you say, that it ‘just works’. Whatever solution is adopted, it would be ideal if this feature could be retained as much as possible. Question: will BASIC ever need to use 64bit integers/pointers, etc? Could it function perfectly well using 32bit integers etc on a 64bit OS, or will that cause compatibility issues? The reason I ask is that BASIC is mostly used these days for smaller utilities and apps – if you want to push things a bit, you’re probably already using C. So would it be a massive problem if BASIC remained stuck in a 32bit world (so long as everything worked correctly)? |
Clive Semmens (2335) 3276 posts |
It crosses my mind that bifurcating BBC BASIC has been done before, with BASIC V having 5-byte reals, and BASIC VI having 8-byte reals, but otherwise being very little different. BASIC VII probably shouldn’t simply make integers 8-byte because the twos complement wraparound effect might well cause compatibility issues; but introducing a new Long Integer type, with say two % signs on the end of a variable name, should surely be possible? I can see that being very useful. Would it be horribly difficult? |
Rick Murray (539) 13803 posts |
Or use a different symbol like ^ to specify 64 bit? In “normal” use, it probably doesn’t matter much, but it will be restricting BASIC to the sorts of things it can do. It seems to me that if RISC OS moves to really big memory (8GiB), then BASIC would be physically incapable of handling pointers to anything that lives in locations that won’t fit into 32 bits. |
Chris Johns (8262) 242 posts |
I imagine your BASIC program will live within the 32bit limit, but things like dynamic areas could be outside of that range. |
Chris (121) 472 posts |
How much would that issue affect existing BASIC programs? If a program uses, say, file handles or pointers to blocks of memory returned by the Wimp, could those end up being over the 32bit limit on a 64bit system? |
Dave Higton (1515) 3496 posts |
Please look forwards as well as backwards. We do need a 64 bit integer type in BASIC, both to address memory beyond the first 4GiB, and to handle files longer than 4GiB. We already have computers that run RISC OS and have more than 4GiB of memory. We are long overdue for an upgrade to the filing systems to handle files longer than 4GiB, although some of the 64-bit calls are already in place (nominally, at least). The idea of 64 bit integers with %% suffix occurred to me years ago too. |
Chris (121) 472 posts |
Just to be clear, I’m not objecting to anything! Just trying to understand a little bit about what’s involved :) |
Clive Semmens (2335) 3276 posts |
Perhaps, although there’s an issue with avoiding ascii values that are actually tokens for keywords. |
GavinWraith (26) 1563 posts |
Standard Lua has always used 64-bit numbers, with options for 32-bit numbers when compiling for platforms that need them. But RiscLua’s |
Alan Adams (2486) 1147 posts |
As just one example, handling the 5-byte system timestamp. |
David Gee (1833) 268 posts |
Shouldn’t that be a Type Mismatch (x% = y%%) ? |
Steve Fryatt (216) 2103 posts |
The 64-bit indirection operator “over there” is |
GavinWraith (26) 1563 posts |
If I had my way, yes ;). But the very admission that there are different sorts of numbers is seen by some as making life too hard for the innumerate. Coerce, coerce was their watchword, but I think the tide is turning against this attitude. |
Dave Higton (1515) 3496 posts |
No more than assigning a floating point value to an integer, i.e. no. |
Chris Hall (132) 3554 posts |
However x% = y%% should give a run time error if y%% is outside bounds 0 to &FFFFFFFF or &7FFFFFFF to &FFFFFFFFFFFF80000000 as it would do now if you said x%=2^34. |
Kuemmel (439) 384 posts |
…as it seems the case the %% is already implemented in the BBC Basic for Windows…looks okay to me… x%=y%% IMHO shouldn’t be an error, should be handled like Chris said…either it fits to the range or not. In assembler there are instructions for signed/unsigned extension and also shrinking/narrowing which trigger flags EDIT: General opinion: Basic (32 or 64) should be always a part of Risc OS, even an ‘emulated’ 32 Bit Version in a 64 Bit Risc OS would be essential for me. It’s such an easy access to the system unmatched by other platforms ever. |
Steve Drain (222) 1620 posts |
Interesting. Here’s a random set of comments.
But ^ is an operator, so
As BASIC stands you cannot use any top-bit-set characters. There are surprisingly few characters that can be used for this sort of thing and be backward compatible.
But there it is used as a prefix, where Basalt uses the
I agree. It is a notation has has been mooted several times, like
Ah! Indirection syntax, the fly in the ointment. ;-( I have a couple of alternatives that I have used with Basalt, but they are probably not a realistic solution. The first is to extend the use of the float variable, with no suffix. This requires some form of declaration of type, eg Enclose an integer variable in (), A related problem was the syntax for structure variables, which needed byte ‘?’ and float ‘|’ suffices as well as substucture, ‘{}’ and fixed length buffer, ‘[]’ syntax. |
Chris Hall (132) 3554 posts |
Is there any reason why strings should not just be allowed to be 64k long vice 256? BB4W allows long strings in an ordinary string variable. |
Rick Murray (539) 13803 posts |
Yeah, I forgot. I’m just a little worried that the %% syntax may confuse things that attempt to parse BASIC.
BASIC historically doesn’t care in the slightest about backwards compatibility when it comes to new features. RISC OS 3.5 introduced the syntax of RISC OS 5 (?) introduced the syntax of Did you realise that you can use Then there’s the ability to pass a string to Not to mention, the current assembler is a lot more capable than previous versions of BASIC. The only viable option for backward compatibility is to have a softloadable version of new BASIC for older machines. With that in mind, don’t worry too much about few features failing on older BASICs. There’s already plenty of that. I’d rather if my 64 bit program wasn’t understood by (older) BASIC, that it abort rather than retry or ignore. ;-) Note: what older versions of BASIC do with new keywords or new use of existing keywords is an entirely different proposition to BASIC being able to run older programs in a compatible way. Indeed, plain (non-FP) BASIC still supports MOS call points so BASIC programs written for the BBC Micro will work without issue. Even if RISC OS transitions to a 64 bit system, I don’t see BASIC changing at all in this respect, just as it didn’t make any difference to plain BASIC programs that the underlying 6502 based hardware suddenly because ARM based hardware. About the only thing that crashed and burned there were programs that screwed around with PAGE. What was the old trick, setting it to &E00 or something? I forget…
Whoo, that ought to make for some freaky looking code for people like me who bracket practically everything everywhere.
I suppose it’s not that different to C’s long long type. Which is a dumb construct if you ask me (what will 128 bit numbers be? long long long?) but it is what it is. |
Paolo Fabio Zaino (28) 1850 posts |
Premise: I’m not a BBC BASIC expert developer, but I used it back in the days with the Archimedes and loved it :) IMHO:
IF the 64bit related changes are accompanied by a new “API” (which in BASIC means a lot of bits, most likely BBC BASIC developers will refer to it as “notation”) then I don’t see why not, at least for the pure BBC BASIC applications (aka no ASM included). The ASM part of BBC BASIC will unavoidably present some issues, for example: - If AArch32 support is left in then on a AArch64 without AArch32 things will go wrong, unless some other trick is added (we discussed that on other topics)
Not necessarily, in my experience at work familiarity always helps in choosing a programming language. For what concern interaction with a 64bit OS I personally think that a new “API” should be introduced, so as mentioned already my vote goes to things like %% for 64bit integers etc. to ensure BBC BASIC VII (is this going to be the name?) can interact with the new 64bit APIs offered by RISC OS NG (is this going to be the name? I mean it is going to be 7 or NG? lol)
The presence of a new “API” will obviously generate a new dialect, so I don’t think this can be avoided, unless there is the possibility to back port the “API” back to 32bit, but even do, you still have the issue of running AArch64 ASM on a 32bit system if the BBC BASIC developer did not write the correspondent code in AArch32 for the ASM section. So in terms of use I don’t see another way. In terms of implementation however, what about migrating it to C where handling of both the two dialects or the new BASIC VII would be easier than do that in ASM? Is it still relevant to keep BBC BASIC written in ASM? Just my 0.5c, hope it helps. |
David Feugey (2125) 2709 posts |
Good question. You can use a lot of tricks in C (opcodes mapped to call function by name, etc.). But, IMHO, you can obtain something even faster with some ASM tricks. |
Steve Drain (222) 1620 posts |
ARM BASIC uses a 5-byte string information block (SIB) which only has 1 byte for the length. BB4W has a 6-byte SIB, hence 64k. ARM BASIC also uses a 256-byte string allocation table (SAT) which similarly limits lengths to 255 bytes. I am not sure how BB4W allocates string memory, but I think Brandy has 6-byte SIBs and a logairthmic SAT. The details of the SIB and SAT are intimately tied into the BASIC code, which is a ‘joy’ to read. ;-)
Up to 64k. It also has a library for strings of any length using a normal string variable, which uses a very simialr technique the the long strings built into Basalt. |
Steve Drain (222) 1620 posts |
With a bit of a stretch I can just about reconcile these, but they do look contradictory. Any new version of BASIC has to run old programs unless, like BASIV VI, it is really treated as completely separate. If it is to be a default BASIC it must accomodate all the quirks allowed by BASIC V, even if it also adds new features.
That is very old in the versions of BASC with RISC OS 5, added by another Steve. It was also in the original Basalt, because I wanted to allow it to be used on RO 4. |
Steve Drain (222) 1620 posts |
And who will bell that cat? Brandy is a pretty good example, but it is not ‘backward compatible’ as I laid out above. |