What would AArch64 BASIC look like?

A large portion of RISC OS BASIC programs call SWIs with a 32-bit interface or use 32-bit pointers internally. These programs will not become 64-bit when run with a 64-bit interpreter unlike recompiling a C program.

The transition from 6502 was easier as BASIC integer variables and most of the in memory pointers in the OS API that were already 32-bit. Furthermore BBC Micro applications typically did not interact with other applications, so having BBC Micro applications interact with RISC OS applications was a non-issue.

BBC BASIC needs pointer(-sized) types and structures to support portability between pointer sizes.

Furthermore interaction between 32-bit and 64-bit applications will causes further problems for programs in any language that call RISC OS APIs, as pointers are often used in inter application communications either directly or via the state of a shared module instance. Other operating systems mostly avoid this by isolating application in separate address spaces and therefore avoiding use of memory pointers in inter application communication.

@ Steve Drain

And who will bell that cat?

We can try also as a team effort if anyone wants to work together, unfortunately I already have to code many hours a day for my day-job, so I can only offer few hours a week and, obviously, I can only speak for myself. Anyway if I can be of any help with the amount of hours I have, I am happy to help.

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

Yes, but was Brandy designed with the same intents as of here?

I think the main reasons for migrating BBC BASIC source to C are:

- Keep it optimised for multiple ARM architecture (harder to achieve in ASM, not impossible, just harder)
- Keep it easier to maintain two dialects (harder to achieve in ASM, again not impossible, just harder)
- Provide infrastructure so that BBC BASIC VII could benefit from multi-core (internal threads for the future or even adding multi-thread support to the BASIC itself??? Defo a “don’t do this in asm”)
- Provide the bases to extend it in the future with more powerful functionalities (what about OOP? and no I am not suggesting it expressly, so just an example)

But again, just an opinion.

With a bit of a stretch I can just about reconcile these,

Taking the concept of backwards compatibility and applying it to BASIC’s ability to run older programs, or to older BASIC running programs using newer features.

It’s similar to the problem of CLib, and that one gets backported to be available for older machines to resolve the issue.

Any new version of BASIC has to run old programs

Of course. That’s why I added a note, highlighted in bold, to point out that I wasn’t talking about that. BASIC, as I said, includes support for the MOS call addresses so can run Beeb era software including those who interact with the OS using stuff like CALL &FFF1…

That is very old in the versions of BASC with RISC OS 5,

Is there a softload BASIC, or is any program using it restricted to RISC OS 5 (and newer)? That is what I was getting at. Because if the OS goes 64 bit, is a developer going to want to maintain two code bases (32 and 64) in parallel?

[write BASIC in C] We can try also as a team effort if anyone wants to work together.

It is a lovely thought. Apart from the shortage of suitable programmers – not I – there is the nature of the existing assembler source. Have you look at it? I can find my way through it, but those who really comprehend it are few and far between, I think.

Yes, but was Brandy designed with the same intents as of here?

It is some years since I looked at Brandy and there have been developments, but I do not think it was. I think of it as another dialect. It does provide a model for BBC BASIC in C.

Is there a softload BASIC, or is any program using it restricted to RISC OS 5 (and newer)?

An so the world turns and the topic of softloading BASIC appears again.

Yes it can, but only once. To make this work properly would require ALL users of ‘modern’ BASIC programs, whatever the OS version, modify their !Boot to load the latest BASIC module. That will not happen easily, although we all did this with the SCL in the early days.

IF – a big IF – that became the norm THEN updating BASIC V with new features ¹ would be a reasonable proposition.

Back on topic, BASIC V might have additional 64-byte integers, but for the reasons mentioned above it will have to work around 32-byte integers as now. A BASIC working only with 64-byte integers will have to be a separate entity following the BASIC VI model.

¹ I do not mean things like COLOUR, which are to accomodate new machines.

Apart from the shortage of suitable programmers – not I – there is the nature of the existing assembler source. Have you look at it? I can find my way through it, but those who really comprehend it are few and far between, I think.

Send it to Sofie Wilson and ask her if she would like to convert it to C for old times sake – she may take pity on us.

Almost any piece of long-lived software, such as BBC BASIC, sprouts into differing versions, unless it has been thoroughly tied down with a formal specification for its syntax and its semantics. A long while ago I enquired whether anybody had actually specified BBC BASIC, and got my head chewed off for mentioning such an uncomfortable modernism. Nevertheless, there is nothing stopping somebody trying, though whether they can get anybody else to look at their specification, let alone agree with it, is another matter.

Because “pure” BASIC programs (those which don’t use SYS calls or assembler) are relatively useless, I think we’ll eventually end up with three variants of BASIC:

1. AArch32 BASIC. This is essentially the current version of BASIC. 32bit versions of RISC OS, and 64bit versions of RISC OS which support running 32bit code, will include this version.
2. AArch64 BASIC. A 64bit version of BASIC which allows full access to the features of a 64bit RISC OS (full access to the larger memory map, full access to SYS calls, support for executing AArch64 assembly, etc.). Possibly this would use a different filetype to make it clear that old BASIC programs aren’t likely to work.
3. “AArch32 emulation” BASIC. A 64bit version of BASIC which provides limited emulation of 32bit RISC OS. Will be available on 64bit versions of RISC OS which can’t run 32bit code. The 32bit emulation will handle mapping some of the 32bit RISC OS SWIs to their 64bit equivalents, so that BASIC programs containing commonly used SYS calls will still work.

So 32bit versions of RISC OS will include AArch32 BASIC. 64bit versions will include AArch64 BASIC, and either AArch32 BASIC or “AArch32 emulation” BASIC, depending on whether the CPU supports 32bit code.

Perhaps the correct way of structuring the 64bit OS will be to make a distinction between the 32bit syscall emulation layer and the AArch32 instruction set support. I.e. so that on CPUs which lack AArch32 support, we can still include the 32bit syscall emulation layer, so that 64bit code which uses the old RISC OS APIs / 32bit address space (like the “AArch32 emulation” version of BASIC) can run directly instead of having to emulate the 32bit environment themselves. I’d imagine that this would also help with porting RISC OS to 64bit (we can start off by running 64bit code using a 32bit address space and the old APIs, and then later on extend the address space & APIs for 64bit and add in the 32bit API translation layer)

convert it to C for old times sake

You’re more likely to get an AArch64 assembler version than that!

Send it to Sofie Wilson and ask her if she would like to convert it to C for old times sake

While you talk to Sophie, don’t forget to ask for an AArch64 variant of Replay.

The 32bit emulation will handle mapping some of the 32bit RISC OS SWIs to their 64bit equivalents, so that BASIC programs containing commonly used SYS calls will still work.

Ben made a subtle, almost throw away, comment to me when talking about something else. It’s that in a 64 bit world, we have a problem that pointers which are currently 32 bit might need to be 64 bit (so, in C, void * is an 8 byte thing).

However AArch64 brings with it 64 bit registers, so hey presto that effectively respecifies all our existing SWIs to be 64 bit. For example

OS_GSTrans r0,r1,r2
OS_GSTrans x0,x1,x2

I thought that was significant anyway.

The SVC instruction has only a 16-bit immediate field, so we would probably have to SVC #OS_CallASWI with some higher register for non-kernel SWIs

Stupid question: does someone have documentation of the different BBC Basic versions?

I would need precise specs for all of these:
http://mdfs.net/Software/BBCBasic/Versions

Beginning with Basic I.

However AArch64 brings with it 64 bit registers, so hey presto that effectively respecifies all our existing SWIs to be 64 bit.

Yeah, that’s probably the best way of handling it. And that’s basically how the CPU maps the registers (AArch32 user mode R0-R14 are mapped to W0-W14 on AArch64 exception entry). The only thing to be careful of is that the upper 32bits of each register are undefined, so some thought is needed on who’s going to be responsible for zero/sign extending them to 64bit (should the kernel zero-extend everything by default for clients with 32bit address space, or should it be the responsibility of each module to deal with it? Maybe for simple modules/SWIs the module header can describe the type of each argument and the kernel can generate suitable wrapper code for dealing with the different cases, while for more complex cases the module must deal with 32/64bit address space issues itself)

The SVC instruction has only a 16-bit immediate field, so we would probably have to SVC #OS_CallASWI with some higher register for non-kernel SWIs

That would also have to include any ‘X’ SWIs, since the ‘X’ bit is bit 17.

OS_CallASWI does inherit the ‘X’ state of the SWI number that’s been provided in the register, but the 16 bit SWI field does raise the question of whether we should do things in a slightly different way. E.g. would there be any benefit for having a flag indicating whether 32bit or 64bit address space is in use, so that the kernel can work it out directly instead of having to look up information for the current process/thread? Do we want to retain the four “OS flag” bits?

One good thing is that the ESR_EL1 register (which the kernel will have to read to determine whether it was a SWI or some other kind of exception) includes the (lower 16 bits of the) SWI number, so except for ARM-mode AArch32 SWIs there’s no need to have the kernel read the SWI instruction in order to extract the number.

Stupid question: does someone have documentation of the different BBC Basic versions?

Documentation? Yes, I’m sure that exists somewhere. Precise specs? Don’t be silly ;-)

Documentation? Yes, I’m sure that exists somewhere. Precise specs? Don’t be silly ;-)

The official guides would be a nice start for me.

The BBC specifications would be fantastic :)
Here is a draft: http://www.bbcbasic.co.uk/bbcbasic/beebspec.html

Documentation? Yes, I’m sure that exists somewhere. Precise specs? Don’t be silly ;-)

Fortunately, we have both documentation and specs in the one and only form that is always complete, consistent and current: the source code :-)

Understandable and even for older versions of BBC Basic?

Understandable

Steffen (wisely) did not claim that. If you need to ask, you have probably never tried to read Sophie’s source!

Didn’t the source for the BASIC ROM on the BBC Micro only have two comments? I think one went like: “>32767 so can’t be”

documentation : source code

Shirley shome mishtake. ;-)

I enquired whether anybody had actually specified BBC BASIC

I think there are lots of corners and edges and ‘bugs’ that have been exploited in programs, so unlikely. Here is a little of what Wikipedia has to say:

Not all major programming languages have specifications, and languages can exist and be popular for decades without a specification. A language may have one or more implementations, whose behavior acts as a de facto standard, without this behavior being documented in a specification. Perl (through Perl 5) is a notable example of a language without a specification, while PHP was only specified in 2014, after being in use for 20 years. A language may be implemented and then specified, or specified and then implemented, or these may develop together, which is usual practice today.

Interestingly, contemporary to BBC B BASIC there was COMAL, which is quite similar. The manual for that has a full specification in diagram form. The terminology used there informed that used in my BASIC StrongHelp manual.

Shirley shome mishtake. ;-)

:)

I think there are lots of corners and edges and ‘bugs’ that have been exploited in programs, so unlikely. Here is a little of what Wikipedia has to say

Of course. But I wasn’t a RISC OS user before the RISC PC. So I probably do not have all the ‘obvious’ documentation about older versions of BBC Basic.

I have a POC of an opcode engine. I planned to make front-end for different flavors of Basic. And other langagues too as COMAL.

It’s probably easier to start with BBC Basic I, then to go on the II, etc. The BBC specifications seems to be a little different for graphics, and could be implemented too.

So let’s try with BBC Basic I.

I do not mean things like COLOUR, which are to accomodate new machines.

I like the blasé way in which you discount older BASIC compatibility problems while thinking that a 64 bit incarnation is somehow different.
Either BASIC understands the program, or it doesn’t. Whether GCOL r,g,b or variable%% is irrelevant. If BASIC doesn’t understand it, it’ll throw an error and the program won’t run.
Happened plenty when the RiscPC was released, and lots of graphics programs (think of Jan Vibe) used the new features that don’t work on the older machines.

There is precedent for just shrugging and mumbling “whatever”. :-)

A BASIC working only with 64-byte integers will have to be a separate entity following the BASIC VI model.

Or adopt the % (or whatever) syntax, so ’’ remains 32 bit and ‘%%’ is 64 bit. Otherwise the ability of BASIC itself to run programs from earlier dialects may be impacted due to unexpected edge cases. That said, some care will be needed for handling TRUE (-1)…

The 32bit emulation will handle mapping some of the 32bit RISC OS SWIs to their 64bit equivalents, so that BASIC programs containing commonly used SYS calls will still work.

This would make the most sense. Treat SYS as a 32 bit SWI call and thunk between 32 bit and 64 bit where appropriate. Obviously not everything is going to work, and the runtime should throw an error if there’s something in a register that is not in the range -1 to -16 that won’t reduce to a 32 bit value. But for the majority of things, it ought to work.
For calling 64 bit SWIs? Introduce a new call. Perhaps SVC (since that’s what ARM call it now). This can behave like SYS but directly call the OS in a 64 bit way.

Do we still support OSBYTE, OBWORD, etc? I notice some of JGH’s programs make use of it in order to run on the greatest number of systems.

Steffen (wisely) did not claim that.

Reading David’s message, I don’t think he was implying the source to BASIC was understandable. I think he was asking “A version that’s understandable and versions for older BASICs?”.

It’s missed on exactly nobody that the author of ARM BASIC is the same person who came up with the ARM instruction set (and wrote a prototype in…BASIC!). I can imagine there’s some deep magic lurking within.

I think there are lots of corners and edges and ‘bugs’ that have been exploited in programs

Was it you or JGH? Somebody has a nice collection of “freaky stuff BASIC actually runs”. These examples are usually used to tear down any pretence of writing a formal specification for BASIC (as Gavin hints at above). It’s not that a specification of BASIC can’t be written, it’s that a complete specification would be both uncompilable and damn near unreadable because of referencing all of the special cases.

There are two ways to approach this. Document the language as is described in the various user guides and accept that some edge case code will fail. Or document the language as it actually is and accept that your brain will melt and you’ll give up long before finishing.

There’s a third way too – the ABC way, which is sort of like “Can’t! Won’t! I need my nappy changed! Mummeeeeeee!”.

So let’s try with BBC Basic I.

The one that doesn’t have OSCLI. ;-)

Some details here: https://en.wikipedia.org/wiki/BBC_BASIC#Platforms_and_versions

Look also at the Docs folder of the BASIC source for 04versus05, BlackLog, and Changes. And, of course, the CVS/Git history.

Good luck, though, as that’s nowhere near enough to get started with a formal specification.

So let’s try with BBC Basic I.

In terms of publicly available information, you might also want to look at the user guides produced by Acorn. None of these rise to the level of a formal specification, although the Master Series Reference Manual and the BBC Basic Reference Manual do go into a fair amount of detail.

BASIC I – BBC Microcomputer User Guide (1982 edition)
BASIC II – Acorn Electron User Guide (1983)¹
BASIC III – BBC Microcomputer Model B+ User Guide (1984)
BASIC IV – BBC Master Series Reference Manual (1986)
BASIC V – Acorn Archimedes BBC BASIC Guide (1988)
BASIC VI – Acorn BBC BASIC Reference Manual (1992)

¹ Later editions of the BBC Microcomputer User Guide may also have covered BASIC II.

Thanks for the the books titles. I’ll be easier to find them on Internet :)