What would AArch64 BASIC look like?

That only works for one procedure call, Steve!

Of course! Slaps head. The tiny routines I have been writing lately have been for calling directly from BASIC and have required little use of the stack. For more extended code I adopted macros a while back, both in BASIC and Asm, so it would only be those that needed modifying.

@DavidS

I have not actually found much code that could be a problem changing the size of the integer to 64-bit. The one bit of code that I have found so far that is a possible problem, is using a really obscure and a bit scary of a trick bit in making a calculation using 14.18 fixed point format, and using the overflow to omit one operation.

Thanks a lot for looking into this issue. I guess the suggestion for retaining var% as integer variables that now would be 64-bit large was somewhat inspired by the way C has evolved over the years.

At one point, “int” was typically 16-bit, while “long” was 32-bit. These days, “int” is typically 32-bit, “long” being 64-bit.

Thus, other languages have successfully increased the size of their fundamental types, rather than inventing new types.

I also suspect that code that relies on var% being 32-bit is quite rare, and as BASIC goes, we do have the source and therefore at least there’s the possibility to rewrite such code in a way that doesn’t make such an assumption.

@Steve Drain

Using 64-bit integers would then be an additional feature, for which a syntax would have to be settled. ‘]’ seems reasonable

Nooo, it’l drive editors with automatic bracket matching crazy. ¹ :) Please, if there is to be a separate character to indicate 64-bit integers, let’s not use one of those that come in pairs.

Furthermore, “]” for me would suggest an array access with a missing starting bracket.

We don’t have a lot to choose from, at least for symbols that are widely available. Several has been suggested, such as “%%”, “&” and “#”. “#” means “number”, so it has some vague connotation to its use for 64-bit integer numbers.

¹ Or anyone doing this mentally.

Nooo, it’l drive editors with automatic bracket matching crazy.

Good point. It was suggested by someone else earlier in the topic because, I am told, BB4W uses that.

We don’t have a lot to choose from

Which I said earlier, too. Of those you suggest only # looks safe to me, unless you restrict how PRINT works. It is still awkward – think CLOSE#file#. ;-)

Which I said earlier, too. Of those you suggest only # looks safe to me, unless you restrict how PRINT works. It is still awkward – think CLOSE#file#. ;-)

That’s a good point. Well, if we instead find we can simply change var% to be 64-bit, then a token like “#” would only be needed when you actually want to access a 64-bit value through indirection.

If you store the file handle as a 64-bit value which you have to read indirectly, the code above would become:

CLOSE # #file // The space between the "#" is added for readability reasons

Perhaps somewhat less confusing, and then again, we may at least starting out retain the API, in which case file handles would remain 32-bit, and the code becomes simply:

CLOSE #!file%

The fact that file% is 64-bit shouldn’t matter here, it just means we may indirect over the entire 64-bit address space. :)

We don’t have a lot to choose from, at least for symbols that are widely available.

“§” would only be good for German keyboards I guess :-)

As far as I can see, you cannot use characters that are also tokens, because they would be converted to keywords by an editor on loading. I think it would be a significant change to BASIC to overcome this.

As I have said, PRINT is the big problem, principally because it allows spaces to act as formatters. If it were changed to insist on one of the other formatters to separate items then there would be a great deal more freedom of choice.

I looked quite hard at this when sorting out the syntax for Basalt. Apart from the pairs [ ] { } I could only find backslash \ completely free and only if it is forbidden as an assembler comment, with ; being available instead.

Some other characters, such as # . ' ~ can be used with restrictions and you can even slip in a : with great care. There are surely some I missed, but it is quite tricky. ;-)

So Richard, you’d be happy if RODL were consulting/talking with Sophie about enhancements?

I’d be pleasantly surprised if Sophie has any current interest in BASIC at all, TBH, but obviously it would be courteous to keep her informed of any proposed enhancements, at the very least.

My attitude to extending ARM BASIC to 64-bits, as is well-known, is that it would be in everybody’s interest to maximise compatibility with my BASICs (BBC BASIC for Windows, BBC BASIC for SDL 2.0 and the BBC BASIC Console Mode editions) which are all 64-bits compatible.

Features of my BASICs that have specific relevance to 64-bit operation are 64-bit signed integer variables (with a %% suffix, e.g. number%%), 64-bit indirection (using the ] symbol, which was literally the only remaining single-character operator available in my versions) and extensions to the PTR() pseudo-variable which provide a way of accessing pointers in a bit-width-agnostic fashion (e.g. address%% = PTR(string$)).

Additional factors to note are that 64-bit integer variables and indirection are available even in the 32-bit editions of my BASICs (they do not require a 64-bit CPU or OS) and that my 64-bit indirection operator is only monadic (]var) because otherwise it conflicts with the use of square brackets to delimit assembler statements.

There are other features of my BASICs (principally structures) which help eliminate direct memory accesses altogether and hence simplify writing programs that will work equally well in 32-bit and 64-bit environments.

Please, if there is to be a separate character to indicate 64-bit integers, let’s not use one of those that come in pairs.

In an ideal world I would agree with you, but it was literally the only remaining single-character operator available for 64-bit indirection in my BASICs. There was a lengthy discussion at the Discussion Group about this subject some years ago.

From a practical perspective I don’t think the fact that square brackets “come in pairs” is terribly relevant, because they typically don’t come in pairs in a single program line (because of their use in BBC BASIC to delimit assembler code). So any parser must expect to see isolated square brackets within a single line of code, and when I have had to modify parsers to cope with their use for 64-bit (monadic) indirection it has not been onerous.

It could cause an early termination of assembly.

No, in practice it doesn’t. BBC BASIC assemblers only terminate when they see a right-square-bracket in a ‘left’ context, i.e. where they expect an instruction mnemonic or pseudo-op. Using ] for 64-bit indirection does not conflict with this, any more than the use of [] to indicate an indirect memory reference (in x86 assembly language) does.

Of course from my perspective compatibility with my BASICs ought to be an overriding consideration anyway, but I know that not everybody here is going to agree with that!

I could only find backslash \ completely free

Is it not planned to use it for line-continuation purposes, as my BASICs do? I could not imagine programming in BBC BASIC with a 251-character logical-line limit! It was one of the earliest of my extensions.

only if it is forbidden as an assembler comment, with ; being available instead.

Indeed, I have not accepted \ as a synonym for ; since I stole it for line-continuation.

Some other characters, such as # . ’ ~ can be used with restrictions

Believe me, this was done to death when it was discussed in the BB4W/BBCSDL context. Even if the syntactical ambiguity of # normally being used to indicate a file (as it has been since the earliest days of BASIC) could be eliminated, the potential for confusion would be unacceptable, in my opinion.

it is quite tricky. ;-)

Exactly. Any hesitation I had when ] was first proposed for 64-bit indirection (and I was initially uneasy) was eliminated when Jonathan pointed out that in MODE 7 it’s a right-pointing arrow → which is actually quite nice as an indirection indicator!

I also suspect that code that relies on var% being 32-bit is quite rare

If anybody is seriously considering changing ‘normal’ integer variables (with a single % suffix) to become 64-bits that would be a huge mistake, in my judgement.

One only needs to look at C for guidance on this. In all modern implementations, int is 32-bits on both 32-bit and 64-bit platforms, and this has directly influenced the design of the instruction sets of 64-bit CPUs. For example in the x86-64 architecture, although all integer registers are potentially 64-bits, the default register size is still 32-bits. To access a 64-bit register one or more prefix bytes is required.

From a software compatibility viewpoint keeping standard integer variables 32-bits is a no-brainer. Two particular instances come to mind. One is arrays, when code that assumes that array%(i%) and array%(i%+1) are 4 bytes apart in memory is common; the second is structures, when again code which assumes that structure members are a fixed offset from the beginning of the structure is common.

This is particularly important when interworking with the OS (e.g. via the SYS statement). Typically an API function may be defined to receive an array or a structure as a passed-by-reference parameter, and because Operating Systems are invariably written in C any int members in such an array or structure will be assumed to be 32-bits. If BBC BASIC had no 32-bit integer type, interworking with the OS would be impractical.

Whatever view you may have of my BASICs, they do provide a great deal of practical experience of working in a mixed 32-bit and 64-bit environment (in Windows, Linux, MacOS, Android and iOS) which it would be wise not to ignore. It’s perhaps also worth mentioning that Michael McConnell’s Matrix Brandy (which can run on RISC OS) has already implemented some 64-bit features, including that 64-bit variables have a %% suffix.

My opinion is that for any extensions we should copy Richard’s BASIC as much as possible. He’s already been through all the pain of working out how to fit them in, so why go through that again!

In fact, could we just use Richard’s BASIC (with permission of course)? Keep the existing ARM BASIC for backwards compatibility, and define a new filetype for extended BASIC.

My opinion is that for any extensions we should copy Richard’s BASIC as much as possible.

+lots!

I have had some experience of moving code between RO <> BB4W <> BBCSDL, and the closer they are the better. Richard has put a great deal of effort and deliberation over many years into extending the original BBC BASIC. It would be a great shame not to follow his lead wherever possible.

In fact, could we just use Richard’s BASIC (with permission of course)?

You wouldn’t need permission: it’s Open Source with a very permissive licence. But you might not be happy with the performance (or size) of an interpreter compiled from C! The iOS edition (which is AArch64) would provide a good testbed.

@Richard: Does the iOS-Version run on the new iOS M1 based hardware ? Would be interesting to see some benchmarking compared to BBC Basic on a native Risc OS Raspberry Pi4 compared to that as you say the performance migth be an issue.

I see unfortunately due to some iOS restrictions the inline assembler and CALL commands can’t be used on iOS…really no tweak to get that to work ? If it would work, does your assembler already support AArch64 on other platforms ?

Does the iOS-Version run on the new iOS M1 based hardware ?

I don’t currently have a native build for M1-based MacOS, but I don’t see why iOS should be an issue.

inline assembler and CALL commands can’t be used on iOS…really no tweak to get that to work ?

Apple forbid ‘arbitrary code execution’ which means it’s impossible to run code loaded into user-accessible RAM. I very much doubt that there’s any workaround.

does your assembler already support AArch64 on other platforms ?

Sadly not. There’s an outstanding issue at Github which somebody has offered to work on, but there have been no updates for some while so I’m not optimistic: https://github.com/rtrussell/BBCSDL/issues/4

My opinion is that for any extensions we should copy Richard’s BASIC as much as possible.

Absolutely this. Richard has already been there and done it, and if there was one he’d have the T-shirt too. I personally think it would be crazy to try to reinvent the wheel in an incompatible fashion.

It’s also for that reason when I picked up the Brandy code and made the Matrix Brandy fork, wherever possible I followed Richard’s syntax for any extensions, including %% for 64-bit int types, and & for 8-bit unsigned integers. (I haven’t yet implemented ] as a 64-bit indirection. The assembler hiccup doesn’t exist for Matrix Brandy as Brandy has never implemented an assembler.)

bq. (Edit: How in the heck do you quote on this thing? The hint at the bottom says to use “bq.” but that didn’t work for me…)

gives

(Edit: How in the heck do you quote on this thing? The hint at the bottom says to use “bq.” but that didn’t work for me…)

I usually edit the post until I get it right… There is also the test-subforum where you can try things out to your heart’s content.

@Andreas Thank you – I had (finally) figured that one out just before you posted that. I had omitted the space after the . which is why it didn’t work for me initially.

it’s Open Source with a very permissive licence.

https://github.com/rtrussell/BBCSDL

It’s SDL2, so it should compile for RISC OS (but don’t expect too much from 3D support).
BBC BASIC Console Mode seems interesting too, but it isn’t open source for now.

BBC BASIC Console Mode seems interesting too, but it isn’t open source for now.

I’m perfectly happy that it should be. If you’re particularly keen, I can expedite that.

The console mode would probably be the best one for RISC OS, with the VDU interpreter stripped out of it so the codes are just passed to the OS, such a bypass is what I do for the RISC OS build of Matrix Brandy. For a GUI in a window, while it isn’t perfect !GraphTask works pretty well.

The console mode would probably be the best one for RISC OS

The Console Mode editions have now been added to the Github project.

The issue with using ] is that it could cause a premature termination of an assembly block.

I addressed that in an earlier reply.

You write as if using ] as the 64-bit indirection operator is somehow theoretical, but the truth is that it’s been implemented in my BASICs for a couple of years or so, and if there were any snags they would certainly have come to light by now. Although I try not to use assembly language code – it kills cross-platform compatibility of course – sometimes it’s unavoidable. For example the BBCSDL debugger relies on it (and currently contains code for x86-32, x86-64 and ARM-32 CPUs).

the version used in the OS shall not be written in an HLL

I agree, so long as somebody has the time and perseverance to write it! I never have attempted a 64-bit BBC BASIC interpreter in assembly language though, I switched to C for that.

DavidS wrote: “And please do not tell me that anyone is even close to serious about using BBCSDL or similar.”

Why not? Presumably you would say the same of Python or RiscLua? Surely it depends on the requirements of the intended application/program? For instance, you wouldn’t (or couldn’t) write a 3D graphics rendering engine in BASIC V either because it would be far too slow; or a high-performance audio processing package, or pretty much any large ‘serious’ performance-oriented application that might declare hundreds of variables (local or global), arrays (local or global) and subroutines, when there are far more suitable languages (primarily C as far as RISC OS is concerned).

Having used Richard’s BASIC for years (primarily BB4W), and more sporadically ARM BBC BASIC V, the former is easier (and more pleasurable!) to write larger, more maintainable programs. It’s usually been fast enough for my purposes, and when it isn’t, a bit of assembler code (or occasionally some imported compiled C) has bridged the performance gap.

If Russell-branch BBC BASIC gets compiled for RISC OS then I would almost always prefer to use that over the more primitive (albeit faster) BASIC V. It’s mostly a matter of personal preference as to whether you choose to use it or not. By all means stick with the BASIC V + assembly language combination that you love so much.

For me (and I suspect others, too), I look forward to Richard’s BASIC getting ported to RISC OS, or at the very least — and this really is a dim prospect — BASIC V getting updated to match its capabilities.