What would AArch64 BASIC look like?

Question is in the title. If/when we make an AArch64 version of RISC OS, what will happen to BASIC?

• BASIC programs are one of the few things that generally “just work” whenever there are major upheavals in the RISC OS world. Can we carry that compatibility through to a native AArch64 version of BASIC (running on an AArch64-only version of RISC OS)?
• Will the backwards compatibility restrict the ability to interact with the 64bit OS, making the language less attractive to developers?
• Will we end up with separate 32bit and 64bit dialects of BASIC, or will it be possible to support both within the same program/interpreter?

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).

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)?

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?

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.

I imagine your BASIC program will live within the 32bit limit, but things like dynamic areas could be outside of that range.

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.

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?

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?

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.

Please look forwards as well as backwards.

Just to be clear, I’m not objecting to anything! Just trying to understand a little bit about what’s involved :)

Or use a different symbol like ^ to specify 64 bit?

Perhaps, although there’s an issue with avoiding ascii values that are actually tokens for keywords.

Standard Lua has always used 64-bit numbers, with options for 32-bit numbers when compiling for platforms that need them. But RiscLua’s riscos library has had to follow Basic’s confusion of integers with addresses to fulfill its purpose – to be able to call SWIs. Some versions of RiscLua used only 32-bit arithmetic, others, the current version included, use 64-bit arithmetic. The only circumstances when this has been a potential problem for users have been where the PRMs conflate -1 and 0xffffffff. No difference as far as ARM registers are concerned, but plenty for Lua variables. But I cannot see 64-bit integers as much of a problem for BASIC – it is just that arguments to SYS will have to be truncated to 32-bit. Statements like x% = y%% would presumably put the bottom 32 bits of y%% into x%.

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?

As just one example, handling the 5-byte system timestamp.

Shouldn’t that be a Type Mismatch (x% = y%%) ?

Or use a different symbol like ^ to specify 64 bit?

^ already has a different use in another dialect of BBC BASIC, which also happens to use a %% suffix for 64-bit integers. For this reason, %% seems like the way to go.

The 64-bit indirection operator “over there” is ].

Shouldn’t that be a Type Mismatch (x% = y%%) ?

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.

Shouldn’t that be a Type Mismatch (x% = y%%) ?

No more than assigning a floating point value to an integer, i.e. no.

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.

…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.

Interesting. Here’s a random set of comments.

Or use a different symbol like ^ to specify 64 bit?

But ^ is an operator, so float^ expects a following number.

Perhaps, although there’s an issue with avoiding ascii values that are actually tokens for keywords.

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.

^ already has a different use in another dialect of BBC BASIC, …

But there it is used as a prefix, where Basalt uses the PTR keyword instead. Richard told me he “wished he had thought of that”. ;-)

… also happens to use a %% suffix for 64-bit integers. For this reason, %% seems like the way to go.

The idea of 64 bit integers with %% suffix occurred to me years ago too.

I agree. It is a notation has has been mooted several times, like $$ for long strings.

The 64-bit indirection operator “over there” is ].

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 DEF, and interpretation according to context. I called these ‘entities’ and they work by reference. I did write some code for long integers using this, but never included it.

Enclose an integer variable in (), (integer%) for a long integer. Again, this works by reference and context, and is my preferred method if I ever get around to releasing that feature. The equivalent long string syntax (string$) has been in Basalt for a while, and it should also work for double floats.

A related problem was the syntax for structure variables, which needed byte ‘?’ and float ‘|’ suffices as well as substucture, ‘{}’ and fixed length buffer, ‘[]’ syntax.

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.

But ^ is an operator

Yeah, I forgot. I’m just a little worried that the %% syntax may confuse things that attempt to parse BASIC.

and be backward compatible.

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 COLOUR r,g,b and GCOL r,g,b which on 3.1x would report “Missing ,” because it thinks you’re trying to set a palette colour.

RISC OS 5 (?) introduced the syntax of COLOUR OF x ON y which will probably tell you “Unknown or missing variable” on earlier versions.

Did you realise that you can use VDU to read Mode/VDU variables? I didn’t until I spotted it in the changes. So PRINT VDU 7 will return with the byte size of the screen, and VDU 4/VDU 5 can read the X/Y eigen values. That’s a lot simpler than all that farting around with OS_ReadVduVariables.

Then there’s the ability to pass a string to MODE.

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.
And, besides, a failure is probably the best outcome, as compared to – say – an older BASIC attempting to run a program that wants to deal with 64 bit values. I am reminded of the horrific mess that early DOSFS made of one of my 4GB USB keys because it could, at the time, only cope with 2GB, but it was too stupid to reject larger things. So it… broke the filesystem in a way that managed to bluescreen XP during a chkdsk (the vfat driver basically had a nervous breakdown).

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…

Enclose an integer variable in (),

Whoo, that ought to make for some freaky looking code for people like me who bracket practically everything everywhere.
Why? Because no, I don’t want to know or remember all the quirks of operator precedence, because this language is not like that language is not like this other language. So everything will be bracketed to be extremely obvious what goes with what.

It is a notation has has been mooted several times,

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.

Premise: I’m not a BBC BASIC expert developer, but I used it back in the days with the Archimedes and loved it :)

IMHO:

BASIC programs are one of the few things that generally “just work” whenever there are major upheavals in the RISC OS world. Can we carry that compatibility through to a native AArch64 version of BASIC (running on an AArch64-only version of RISC OS)?

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)
- If AArch32 and AArch64 are both included then it’s probably wise to think of a DIRECTIVE section for the BBC BASIC Assembler to help detecting if we are on a AArch32 or an AArch64 (for example, something like __ARM64 )
- If only AArch64 is implemented, obviously we’ll have issues with BBC BASIC code that has ASM in it, but given that it’s in source format is it that of a big problem? (I personally do not know)

Will the backwards compatibility restrict the ability to interact with the 64bit OS, making the language less attractive to developers?

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)

Will we end up with separate 32bit and 64bit dialects of BASIC, or will it be possible to support both within the same program/interpreter?

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.

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?

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.

Is there any reason why strings should not just be allowed to be 64k long vice 256?

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. ;-)

BB4W allows long strings in an ordinary string variable.

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.

BASIC historically doesn’t care in the slightest about backwards compatibility when it comes to new features.

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.

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.

Did you realise that you can use VDU to read Mode/VDU variables? I didn’t until I spotted it in the changes.

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.

In terms of implementation however, what about migrating it [BASIC] to C

And who will bell that cat?

Brandy is a pretty good example, but it is not ‘backward compatible’ as I laid out above.