Porting ARM32 BBC BASIC to ARM64

#define TRUE and FALSE

I know about stdbool, but it is lowercase so…

Lowercase true and false are defined as macros in C99 mostly to allow the avoidance of clashes with existing (pre C99) use, but be warned that in C24 true and false are promoted to proper keywords – so no amount of preprocessor trickery will make them go away. Seems the standards body are aligning on C++ in the area of bool after 25 years in use.

They’ll be just as much part of the language as for and sizeof are.

“Lowercase true and false are defined as macros in C99 mostly to allow the avoidance of clashes with existing (pre C99) use, but be warned that in C24 true and false are promoted to proper keywords – so no amount of preprocessor trickery will make them go away. Seems the standards body are aligning on C++ in the area of bool after 25 years in use.”

Thank you – helpful to know (simulating bool made things messier / more potential for random errors that take hours to chase down!

This project (BBC BASIC + VDU drivers) does continue! I added MODE strings to BASIC, have added enough of the SWI support so that BASIC can select modes by calling the same SWIs as in ARM32 (this SWI support is the SWIs that are part of the VDU drivers, Kernel.S.vdu.*. 32 bit modes now work, also 16 bit modes. Because it is still virtual, the mode ‘checking’ currently consists of :” if x or y is less than 64, set it to 64”. :D Implementing OS_ReadUnsigned() was fun … but was needed because I want my code to be portable, and also faithful to how RISC OS 32 works (I intend to test parts of it as an actual RISC OS build on my Pi4 at some stage).

So … back to code consolidation / tidying. Then fix up initial memory allocation so that there is actually a Sprite area, so that I can add Sprite support to the VDU drivers (which are still a work in progress; they are surprisingly fast despite using the general line drawing code for filled objects, as I haven’t got around to HLine yet!

Not sure if this got covered earlier, I have to admit I didn’t read it all..

The global integer variables in 6502 BBC Basic are the mechanism you can use to pass state between programs that CHAIN one another. Its reasonable to assure that behavior is retained in the ARM version, this is why they are not initialised by the interpreter.

.bq sprow said “If you stick to _swix in C,”

I am looking forward to seeing somebody else’s implementation of this example from the swis.h header, on a 64 bit machine.

e = swix(WimpSetExtent, INBLOCK, w, minx, miny, max, маху):

I believe what this is saying is call the swi with r1 pointing into the stack at the first of the arbitrary number of following parameters.

ChatGPT said there are at least 5 different ways, varying by arch and word size of passing parameters to functions on the stack and that this code is never likely to work anywhere but a 32bit machine.

Luckily Stack overflow offers a half page macro that might turn that into a counted array of parameters, but its not tested yet.

All the current talk of 64 bit made me think of blowing the dust of something I started in 2007 on 32 bit FreeBSD but when I ran in to the above trying to compile on aarch64 linux I started having second thoughts.

The thing in question was an experiment in taking the RISC OS source to Brandy BASIC and trying to compile it on a foreign system wrapped in two forms of swi emulation, the first veneer directly to the host, the second was a socket protocol (its called socket swi) which passes the swi call to your parent process (which forked you with this extra pipe open along with stdin/out/err). This seemed to me like a way of dealing with a lot of the things that a process can do on RISC OS that unix is not going to let you do in a pink fit. If you extrapolate a long way down this road it could also single thread the desktop events for you even though the processes are not.

Then I had children and I did not look at it again, until now.
Alan

.bq sprow said “If you stick to _swix in C,”

You need to do bq dot rather than dot bq for quoted lines. (As per Formatting Help below the Reply panel. See also the link in the text “See also Textile reference here”)

ChatGPT said there are at least 5 different ways…

We really don’t need any quotes from a nonsense generator in technical discussions!

We really don’t need any quotes from a nonsense generator in technical discussions!

I’d be more concerned about this part:

Then I had children

;)

Its reasonable to assure that behavior is retained in the ARM version, this is why they are not initialised by the interpreter.

I don’t see why they can’t be initialised to zero when the BASIC environment is initialised_, especially given as this appears to have been the previous behaviour.
Note that CHAIN doesn’t leave the environment. Methods that do leave (WimpTask, StartDesktopTask, or just @FilerRun@) start up a new environment with a new block of memory pretending to be at &8000. Accordingly, values cannot be passed between programs in different environments (unless using system variables, a shared bit of RMA, or some other method).

that unix is not going to let you do in a pink fit.

…? I think I get what you’re saying by context, but that’s a peculiar expression.

I am looking forward to seeing somebody else’s implementation of this

I’m looking forward to seeing how anybody/everybody rationalises “mostly keeping” a 32 bit API in a 64 bit world. Little things like this are reminders that it there are ever so many traps to fall into.

Still, all that being said, while 64 bit is NEW! and SHINY!, there’s plenty still to do with existing hardware.

Might I suggest, for example, attempting some sort of rational way of using however many cores may be present on the host machine? Because I can’t help but feel that if it’s a mess/too hard/huh? on current RISC OS, then how is it supposed to work on 64 bit?

that unix is not going to let you do in a pink fit.

…? I think I get what you’re saying by context, but that’s a peculiar expression.

Possibly generational, my father used the expression, I don’t think I ever have.

Why are we worrying about compatibility with variable passing by CHAIN which hasn’t been used since the BBC Micro? Not breaking everything is good, not breaking anything is unnecessary.

Then I had children

That does tend to remove any spare time to do RISC OS stuff for many many years.

Why are we worrying about compatibility with variable passing by CHAIN which hasn’t been used since the BBC Micro?

Do you know that, or is this another “I can’t think” scenario to annoy nemo?
After all, it is documented in the most up to date BBC BASIC Reference Manual that this happens and that the resident integer variables can be used for that purpose, therefore, one might be inclined to assume that in the third of a century (ish) that BASIC and RISC OS have been around, somebody has probably done this.

That does tend to remove any spare time

I was thinking more about the I in that sentence…

Do you know that, or is this another “I can’t think” scenario to annoy nemo?

I can think¹, and what’s more I can count² – and in 5439 RISC OS BASIC application and utility programs in my archives, there are:-

• 112 uses of the CHAIN keyword, of which
• 61 are CHAIN “Edit:Throwback” to invoke the DDE throwback on error (most of which are in code I’ve written), of the others
• 34 are used in Acorn’s old A5000 and Risc PC rolling demos
• A grand total of ONE application actually relies on passing on A%-Z%

It’s an ancient copy of Minerva’s !MultiStore “v2.20 29-May-91 UNFINISHED”, which uses Z% to pass the task handle to another part of the program, it’s 26 bit only so hasn’t run in years, and wont be making the transition to 64 bit.

So I think we can say quite safely this is a BBC legacy feature which is no longer needed.

¹ Therefore I am

² Using Linux find piped through gerph’s bastotxt detokenizer and fed into grep

I don’t suppose I’m the only oddball (I think oddballs are probably a majority among RISCOS users) with a substantial number (~150) of old programs/apps written in BASIC that I wrote myself and use a fair bit, of which at most 11 are in your archive – the 11 that are available from my website. None of the others have ever been available online. (A few others have been shared with a few friends, but it would be very surprising if even one of those very few extras had made its way into your archive.)

The “about 150” does not include any of the 30 or so that no longer run on the Pi4 because they contain assembly language routines that have never been updated to 32-bit.

About the CHAIN thing and variable passing – it is probably possible to keep it with minimal effort. I will need to look more closely at the startup of the BASIC code, but there are a few different pathways into the basic code;

Looking (at gitlab from iPad and memory), CHAIN is in Stmt.S, and all it does is BL LOADER (Command.S), then B RUNNER, so just load and run. This bypasses the ‘initial setup’ phase of BASIC; I have a user|mode ARM emulator I made a few months ago that lists out all the subroutines as they are used, but I am pretty sure a fix could be added so that the static ints are cleared when BASIC ‘properly starts’, but it wouldn’t affect CHAIN etc. I will get round to the fix after testing some things; if it is added in the right place (early ‘bootup’ of BASIC, it will clear the vars to 0 and still allow passing ‘within’ instances of BASIC via chain etc. It is probably 2-4 instructions to fix!

CHAIN is from the BBC Micro days with 8K to 20K of memory, where you had to replace the currently running program with another one, and A% to Z% was used to maintain state. This hasn’t been any real use since Arthur when memory increased to at least 512KB. A far more common use case these days, is to run another program and then return to the first, and state can be passed using the command line arguments.

As this whole topic is about porting BASIC to ARM64, keeping compatibility with BBC Micro era stuff is going to be the least of your worries.