What would AArch64 BASIC look like?

If you end an Assembly block by having the ] immediately after a variable name, and there is a floating point variable with the same name as a 64bit integer, the only difference being the ] […]

Because we’re not talking about a 64-bit integer variable suffix; we’re talking about a 64-bit integer indirection operator. And Richard addressed the reason why it’s OK in an earlier post, as he keeps pointing out.

The question of 64-bit integer variables is another one entirely, if one decides to implement both 32-bit and 64-bit. BB4W has varname% for 32-bit integer, and varname%% for 64-bit integer.

So you might do something like

value%% = ]address%%

in our hypothetical¹ 64-bit BASIC.

¹ Hypothetical on RISC OS; it already exists elsewhere.

how does the interpreter know [not] to terminate the block ending in varname] where varname is the float version of the variable?

It doesn’t, but varname]offset is the dyadic usage of the indirection operator and I specifically said that I support only the monadic usage (]varname) for that very reason. The floating-point indirection operator | is also monadic-only, even in Sophie’s BASICs, so there is precedent for this.

For me, it’s maximising the compatibility that’s important. I do agree that porting my interpreter to RISC OS isn’t an attractive solution, not least because some of the ways in which my BASICs have diverged from Sophie’s over the years would have to be reversed.

For example it would certainly have to be modified to load and save ‘Acorn format’ tokenised programs, including big-endian line numbers (ugh!) and two-byte tokens. It would also need to load and save Acorn-format data files, with their reversed strings etc. Not necessarily difficult changes, but somebody would have to implement them.

Then there are some of the more subtle ways in which my BASICs differ from Sophie’s, for example I’ve merged ON ERROR LOCAL and LOCAL ERROR into one operation (LOCAL ERROR is accepted but does nothing). More significantly there’s the different behaviour on integer overflow (Sophie’s BASICs sometimes ‘wrap’ but mine always report ‘Number too big’).

Plus there’s the issue of my ‘suffixless’ variables being numeric variants rather than floats, something which I think is a major advantage but some RISC OS users might find hard to swallow. There are plenty more minor differences when one looks closely, some of which could be deal-breakers.

So in an ideal world I would be hoping for an AArch64 interpreter written in assembly language for speed and compactness, generally working in accordance with what RISC OS users have come to expect, but with the greatest possible degree of compatibility with my interpreters given those constraints.

But if nobody steps up to the plate, porting my BASIC (with modifications) does at least provide a fallback which would – I hope everybody agrees – be better than nothing.

For example it would certainly have to be modified to load and save ‘Acorn format’ tokenised programs, including big-endian line numbers (ugh!) and two-byte tokens.

As a dabbler in programming and full time (paid) support person working on networks I feel that it should be pointed out that (lifting the text directly from a document¹)
“Big-endian is the most common format in data networking (e.g. IPv4, IPv6, TCP and UDP are transmitted in big-endian order), and little-endian is popular for microprocessors (Intel x86 and successors are little-endian, but Motorola 68,000 store numbers in big-endian; PowerPC and ARM support both)”

So, essentially x86 is the one that is out of step and the item missing from the text above is that ARM deployment outnumbers x86 deployment so x86 instances are definitely a minority.

¹ Serialization in Object-OrientedProgramming Languages – Konrad Grochowski, MichałBreiter and Robert Nowak

So, essentially x86 is the one that is out of step and the item missing from the text above is that ARM deployment outnumbers x86 deployment so x86 instances are definitely a minority.

ARM can be big-endian but AFAIK all mainstream ARM platforms (e.g. iOS, Android, even RISC OS) are little-endian, and ARM C compilers by default assume little-endian operation (for example it’s necessary to use the -mbig-endian switch to force gcc to generate code for an ARM running in big-endian mode).

But more to the point, the 6502 is little-endian so why did Sophie originally choose to use big-endian line numbers on that platform? I’ve asked before, but never received a satisfactory explanation.

My part time dabbling is where I make an income, when I make an income, as it does not exceed 50 hours per week.

Fifty hours a week is part time dabbling?

I usually¹ work 35 hours a week. That’s considered full time.

the 6502 is little-endian so why did Sophie originally choose to use big-endian line numbers on that platform?

The 6502 might be little-endian, however line numbers are 16 bit values and registers eight bits, so I don’t think it matters which way around the bytes are read.
Perhaps doing it that way around saved an instruction or something?

¹ A bit less right now “because Covid”

But more to the point, the 6502 is little-endian so why did Sophie originally choose to use big-endian line numbers on that platform? I’ve asked before, but never received a satisfactory explanation.

Probably the network use and mainstream Unix (AIX, HP-UX, Solaris) would be the likely answer. The design of the ARM as either is probably for flexibility in leaving any switchover in usage to be a soft change – theoretically RO and apps could be switched…

I don’t think it matters which way around the bytes are read.

Maybe not on the 6502, but the Z80 could read all 16 bits in one instruction, which Sophie must have been aware of. Given a free choice, little-endian to match the native byte-order of both the 6502 and Z80 would have been more logical IMO. It was sufficiently an issue that I chose to use a different program format for the Z80 version, and have stuck with it ever since.

Probably the network use and mainstream Unix (AIX, HP-UX, Solaris) would be the likely answer.

That time machine must have come in handy: BBC BASIC 1981, HP-UX 1984, AIX 1986, Solaris 1992.

I don’t think network use is relevant, but in any case I’m pretty sure Econet was little-endian.

Of those I would be surprised if Big Endian implementations were ever all that common for either AIX or Solaris.

At least AIX on POWER as well as Solaris on SPARC is Big Endian and always has been.

At least AIX on POWER as well as Solaris on SPARC is Big Endian and always has been.

PowerPC: 1992, SPARC: 1987.

For me, it’s maximising the compatibility that’s important.

I agree in principle, but as Richard points out, there are probably insurmountable differences and that inter-operation is not very likely. A shame. However, the closer the easier it is to convert one to the other.

So in an ideal world I would be hoping for an AArch64 interpreter written in assembly language for speed and compactness, generally working in accordance with what RISC OS users have come to expect, but with the greatest possible degree of compatibility with my interpreters given those constraints.

That seems to be an excellent aim.

But if nobody steps up to the plate,

There’s the rub. There are so many things I might add to BASIC, before even thinking of AArch64, but like many before have found, there is a problem with the source. If I were to undertake it I would want to re-factor and fully comment the source. This would break the chain of development and would almost certainly not be accepted.

A couple of years back, with Martin Avison’s encouragement, I attempted to do a partial job that would retain a byte compatibility with the assembled code. It was not very satisfying work and I stopped because of the tedium. Alongside I did some re-factoring to my own taste and I would still enjoy that.

porting my BASIC (with modifications) does at least provide a fallback which would – I hope everybody agrees – be better than nothing.

Indeed.

For example only the ARM has conditional every instruction, as well as free shift/rotate. Actually I can not think of another production CPU with those features, only ARM.

Indeed, both key features of ARM32, and both abandoned in AArch64 (bringing this back on-topic).

Is it not planned to use it [char ‘\’] 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.

RISC OS BASIC has only one byte for the line length and that seems to be tightly coded into the source. I suppose longer lines might be split with some clever logic, though.

You might recollect that I chose ‘~’ to split lines in Basalt, but they were still limited in length. I kept ‘\’ as the breakout character to allow entry into the program, principally for structures.

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

I don’t find it yet. Just the BBCSDL project. I’ll check later.
But thanks!

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.

Oh yes. And even if it’s sometimes different.
We already have three versions of BBC Basic. We can have four :)

RISC OS BASIC has only one byte for the line length and that seems to be tightly coded into the source.

That’s the point. The physical line length is limited because of this, but by using the \ character logical lines can be any length in my BASICs (except for single-line IF … THEN … ELSE statements in which the ELSE must be on the first physical line).

DIM array$(3)
array$() = "Twas the night before Christmas, when all through the house", \
\ "Not a creature was stirring, not even a mouse.", \
\ "The stockings were hung by the chimney with care,", \
\ "In hopes that St Nicholas soon would be there."

I don’t find it yet. Just the BBCSDL project.

I’ve added the Console Mode editions to the BBCSDL project (because they share source files).

logical lines can be any length

Got it!

I’ve added the Console Mode editions to the BBCSDL project (because they share source files).

It does build OK for RISC OS but always gives the error ’Couldn’t allocate memory’ when run. Maybe the UnixLIb mmap emulation is not up to it.

It does build OK for RISC OS but always gives the error ’Couldn’t allocate memory’ when run.

It may well be that none of the #ifdefs are being satisfied, so it’s falling through without doing any memory allocation at all! Try changing the #ifdef __APPLE__ to include a test for RISC OS.

Line numbers being MSB first: reason could have been the program termination combination &D,&FF. A linenumber with LSB first, would be cumbersome for determining if the end of the program was reached (two byte checks needed), while MSB-first makes it possible to use all linenumbers until &FEFF with one check.

this do the difference in the BASIC V floating point and the FPE.

One can say much the same for C programs built using the DDE, so it’s more a really good argument against our continued dependence on a ~35 year old emulated floating point system.

the only limit being that some of the internal functions use SIB of the string which puts a 255 char limit for that usage.

Strings, as natively handled by BASIC, are limited in size. Some might say too limited.
It’s worth pointing out, however, that C-like strings (as long as you like until a null terminator is reached) are rather suboptimal in that everything that needs the know the length of the string (strcat, strlen, etc) work by reading through the entire string byte by byte until the terminator is reached. Every single time.

(and that’s asides from the general shonkiness that functions like strncpy may, if the size limit is reached, return invalid unterminated strings)

The thing is, strings are harder than they look…

The thing is, strings are harder than they look…

Amen to that. There is an unavoidable principle in computer science. How you represent something (i.e. what datatype should you use) depends on what you want to do with it. In arguing about programming languages most people, I am sorry to say, do not ask themselves such questions, being blinded by what they assume already and mistake for being universal solutions. By string what do you mean? Each programming language uses that word to mean something different. There are a number of things you can do with strings: print them, compare them in a number of ways, concatenate them, match them to patterns, extract data from them, …. . Tell me what your priorities are among these uses and only then can I tell you the most efficient datatype to use.

But perhaps the use which you are actually prioritizing is it should be reminding me of the thrill I had all those years ago when I first programmed in .. ; that is to say nostalgia ? Be honest. Why this obsession with the past? Things have been learned since then. Look around. We should not be repeating choices made under constraints that no longer constrict us.

Strings, as natively handled by BASIC, are limited in size.

Strings, in my BASICs, have a 32-bit length. It’s limited (on a 64-bit system) but not in a meaningful way!

‘Unlimited’ length strings which can contain arbitrary data (i.e. there’s no reserved ‘terminator’ character such as NUL or CR) are incredibly useful. I routinely search multi-megabyte binary files using INSTR, or copy them like this:

src% = OPENIN(srcfile$)
dst% = OPENOUT(dstfile$)
BPUT#dst%, GET$#src% BY EXT#src%;
CLOSE#dst%
CLOSE#src%

Line numbers being MSB first: reason could have been the program termination combination &D,&FF.

In my BASICs I put the line-length byte first (before the little-endian line number) so the end of the program is marked just as conveniently as &0D,&00. This also allows line numbers to go up to &FFFF rather than &FEFF because it’s the line length, not the line number, which marks the end of the program.