Porting ARM32 BBC BASIC to ARM64

you can assume it exists and is zero if it hasn’t already been set to some other value in the current program or any earlier one.

From RISC OS 5.24 onwards, BASIC programs started by double-click will have (semi-)random values in the resident variables (A% to Z%). To avoid disappointment, do not assume that the initial value is zero, or that values will be passed from one program to another.

Resident variables in BASIC programs started from the command line (e.g. in a TaskWindow) will be passed from one program to the next, but it is no longer safe to assume that an unused resident variable would have a value of zero (and in fact it was never good programming practice to do so).

I now regard the resident integer variables as something to be studiously avoided.

Amusingly, the user guide says:

Do not get into the habit of using BREAK. The ESCAPE key provides a much less violent way of escaping, from a program! (See page 142 for more details on BREAK).

This is after, and followed by, various examples that say “Press BREAK then…” or “Press BREAK after you have finished…”.

🤷🏻‍♀️

I now regard the resident integer variables as something to be studiously avoided.

Probably sound advice. I’ve never used them, just remember reading about them! (Apart from @%, of course, which one has to set to whatever value one needs to format PRINT output.)

I now regard the resident integer variables as something to be studiously avoided.

I routinely use I% as a loop counter, and if necessary also use J% and K%. From this you might be able to identify the first programming language I encountered. Always remembering to declare them as LOCAL, as there’s a high risk of corrupting the counter of the calling procedure within the called procedure.

Is there a reason for the semi-random inbuilt integer variables thing? I ask because zeroing them upon basic startup would take almost no time and almost no extra code – just a loop to erase 26-ish words in a row that form the inbuilt integer vars; this could be done as part of BASIC atartup very easily, just a few extra instructions!

@tymaja – I think anyone who uses the resident integer variables assuming anything at all about their contents before they set them themselves deserves whatever problems they get. I don’t think you need to worry about them at all. (As long as you don’t let them be a security hole!)

To avoid disappointment, do not assume that the initial value is zero, or that values will be passed from one program to another.

No, the values won’t be zero because it is broken.

They will be passed from one program to another, but only in the same instance. If you open two TaskWindows and start BASIC twice, you’ll see that PAGE and HIMEM etc are identical. You are effectively running two completely separate instances of BASIC. You can set A% (etc) and then CHAIN a program within the same instance and it’ll work as it is supposed to, but you cannot StartTask/WimpTask/Filer_Run etc as that will start up a new instance with its own set of resident variables. You’ll need to use system variables or something to pass values.

(and in fact it was never good programming practice to do so).

It’s never good to assume things like that, but then it’s arguably worse for long-established behaviour to change.

I now regard the resident integer variables as something to be studiously avoided.

I believe that using them can make a program’s reference to those variables a fair bit faster. Whether or not this matters in a world with gigahertz processors is a different question. ;)

I routinely use I% as a loop counter, and if necessary also use J% and K%.

Fortran? Which means i and j probably have some meaning in mathematics. ;)

Is there a reason for the semi-random inbuilt integer variables thing?

Yes – it’s because somebody broke it.

They initialise to zero on the BBC B (tested with BeebIt) and on RISC OS 3.10 (tested with ArcEm). I don’t have a RiscPC emulator on this machine for trying 3.7.

Unfortunately it was never actually documented anywhere, that I can see, that the resident integer variables default to zero. However, given that on the 18th of September 2017 there was a commit renumbering the “Bad MODE” error for Beeb compatibility, it surely shouldn’t be too much to ask that the variables get properly to zero for compatibility as the BASIC environment is initialised?

I believe that using them can make a program’s reference to those variables a fair bit faster.

This certainly used to be true – and I did use them for that reason back in the day. But I always gave any of them that I used initial values explicitly, never assumed they’d be zero or any other particular value.

Interesting… I’ve just been pulling apart BASIC 1.05 (RO3) and comparing it with the source of 1.16 (from the 3.71 dump), and the current version of BASIC.
I’m not familiar with the code, but looking through the startup, it seems as if it’s only setting @%. I can’t find anything that sets A% to Z%.
Is it somewhere else? Maybe a “just clear the workspace to zero then…”? I didn’t find it, if it is this.

Curioser and curioser!

never assumed they’d be zero or any other particular value.

This is something that crops up a lot in C; and often a difference in behaviour between a release build misbehaving and one running correctly in the debugger can be traced down to logic that uses certain variables, such as if ( var ) (as in, it isn’t false or zero) coupled with variables that are never given an explicit value and, due to caffeine deprivation, are never given a value at all.

The difference? A debugger gives a sanitised environment. Workspace will be set to zero, for instance, so the uninitalised variables will look like “NULL”. In a release version, this doesn’t happen so the uninitialised variables will be set to “whatever”, which is not null and is therefore a value. Not great if it’s supposed to be a pointer and it’s pointing at <shrug>. Even better when <shrug> changes every run, so errors happen but they are not necessarily reproducible as the actual behaviour may depend upon what <shrug> is.

So even though cppcheck whinges, I always give variables an explicit value of 0 or "" (unless it defaults to something specific) even if three lines later the variable is set to something else.

Saves headaches.

and I did use them for that reason back in the day

I only ever used L% as a loop counter, X%/Y% for CALL/USR, and P%/O%/L% for assembly.
I’m not a fan of code using single letter variables, makes it that much harder to read and while P%=R%*Y%+S%+D%<<C% might make perfect sense while you’re writing the program, come back to it in six months and you’ll be “P percent equals a what now? Ugh, why did I write it like this!”.

Setting @% is fairly important. As the rest should default to zero, Ctrl-Break should indeed leave them at zero – and otherwise they’re supposed to contain whatever they already contained. Which on a Model B would be whatever a previous BASIC program left in them, but might random on a RISCOS machine?

I’m not a fan of code using single letter variables

Nor me neither, but I used to use a few back in BBC Model B days, simply to keep programs short and/or for speed. Or in those famous competitions where getting eleven statements on each line, separated by colons, and NO spaces to be seen, might win a few quid… 8~)

Comments, if any, would be on scraps of paper, not in the computer at all.

”You are effectively running two completely separate instances of BASIC. You can set A% (etc) and then CHAIN a program within the same instance and it’ll work as it is supposed to“

Agreed – although PAGE etc are equal, they are two seperate instances of BASIC – in different blocks of memory (just mapped into the same space, while they are running, via the MMU)

“ Is it somewhere else? Maybe a “just clear the workspace to zero then…”? I didn’t find it, if it is this.”

Interesting! Could it be somehow related to something deeper within RISC OS? BASIC is given a load of 4K pages when it starts up, so … if the OS manually zeroes out each 4K page before handing it over to BASIC, the integer variables would be zero on startup, whereas if the pages are handed over ‘uninitialised’, then this could result in the random integer variables on startup;

It would make sense, given the huge amounts of RAM we now have – clearing hundreds of MB when allocating memory could slow things down a lot!

This would also be a reason to update BASIC to zero out &8000-&8700+VCACHE when first starting up an instance – as that would be quick, and could prevent intermittent errors in older code that relied on these vars being zero on startup.

if the pages are handed over ‘uninitialised’

That’s a security hole, if that happens!

A security hole in RISC OS, we are all doomed!

It’s a good job you can’t arbitrarily read any active applications memory with Wimp_TransferBlock isn’t it?

8~)

“So even though cppcheck whinges, I always give variables an explicit value of 0 or "" (unless it defaults to something specific) even if three lines later the variable is set to something else.”

Same! always uint64_t variable=0; or NULL or anything except just a ;!

Edit : I also tend to do stuff like:

if (0 == testvariable) {do stuff;} … because it is too easy to type = rather than == and get unexpected results!

“A security hole in RISC OS, we are all doomed!”

😂 – that is one of the great things about RISC OS – being so close to bare metal; it is brilliant if you are interested in how computer OSes work etc!

Worrying now that we have WiFi (although security by obscurity probably makes RISC OS the most secure OS … for now!) I still remember the days of ‘Extend’ (module) getting into the school I went to. We had ‘SJ Research Nexus’, and they closed all the computer rooms, went into read/write mode on Nexus with only a single A3020 powered up (all other computers powered down) ….. but they missed a single RMLoad Extend inside a !Boot somewhere 😂 – that oversight added hours more work to their day 😬

Don’t kid yourself, there are plenty of things more obscure than RISC OS, but very few that are so deliberately easy to compromise in every conceivable way.

“Don’t kid yourself, there are plenty of things more obscure than RISC OS, but very few that are so deliberately easy to compromise in every conceivable way.”

I agree. Back around ~1998 to early 2000s, I used to go to (#acorn?) on IRC on my Risc PC. The WiFi extension to RISC OS is a good thing, but my RISC OS Pi4 doesn’t ever go online! I connect it via ethernet to a MacBook Pro 17” mid 2011 (which still has working ATI graphics), and that MacBook also doesn’t go online! 😬

RISC OS being in ROM was a good way to to prevent the absolute worst disasters from happening. As technology progresses, things get scarier.

Not sure how to make RISC OS secure, but my ‘dream’ RISC OS would be:

EL3 initialised, and ‘left empty’ (for later expansion)
EL2 running a very compact hypervisor. This could provide a lot of HAL-like stuff, interfacing to the host machine etc, interfacing to graphics etc
several instances of EL1:
– RISC OS (sandboxed from intermet)
– RISC OS (that goes online)

That wouldn’t stop malware type attacks, but expanding further, we could run a hardened Linux firewall to provide internet services to the other EL1s;

On a RPi5, EL0 could even run user code in 32-bit mode (if we had RISC OS functions running at EL1 which can only be 64-bit)

Not sure how to make RISC OS secure

A Faraday cage around the system*, battery power only. No connection to the outside world whatsoever.

Might work, if you’re lucky.

* That is, a thick aluminium box – not one of those “cages” that’s only good for blocking things with long wavelengths…

because it is too easy to type = rather than == and get unexpected results!

A decent compiler should warn…

"c.wrapper", line 88: Warning: use of '=' in condition context

I still remember the days of ‘Extend’ (module)

Ah, yes. Back when miscreats wrote viruses for the machines.

I used to have a collection of them on a floppy. Some were… bugged. I had about a dozen copies of the so-called Vigay Virus, each edited by somebody who knew even less about programming than the person prior. The final three? Tried them on emulation, they didn’t make it through startup. &#x1F923;

but my RISC OS Pi4 doesn’t ever go online!

My Pi is online right now, that’s what I’m using to write this. The router acts as a barrier, except the other Pi (currently off, thunderstorms nearby) runs WebServe (without PHP) and a small test BBS on telnet.
Both get frequent hack attempts. None of which work for two reasons. First reason is that RISC OS isn’t like regular stuff so all the attacks (like poking around phpMyAdmin) don’t do anything except return 404s, and the second reason is that the attack surface is small. I’m not under any illusion that it is “secure”, but all WebServe does is answer basic HTTP requests and return information or “not found”. There’s no script interpreter or database or whatever, so you’d need to know some deep down stuff about WebServe and RISC OS in order to trigger a buffer overrun; ditto the BBS server as it’s my own code.

But, then, what’s the point? If you wanted to hijack a RISC OS machine, there are a lot of easier ways to do it than trying to hack any that might be exposed to the internet. Simply create a potentially useful program and hide something inside. If that something stays silent until the planned time of deployment, it would likely go undetected. But, then, RISC OS is known to be not secure, so exactly how many people around here use it for home banking and/or paying bills? The information isn’t the gold mine these days – you’ll notice the bad guys that scramble data tend, these days, to go for government departments, public utilities, and hospitals ¹ instead of people. What’s likely to be found on a minority platform that’s worth the effort for a fraction of a piece of bitcoin?

¹ Because they are the lowest of the low.

So even though cppcheck whinges, I always give variables an explicit value of 0 or "" (unless it defaults to something specific) even if three lines later the variable is set to something else.

I disagree with this style of coding. It means sanitisers can’t spot genuine bugs (static analysis, clang’s address/memory santisiers, or Dr Smith’s Toolkit).

Edit : I also tend to do stuff like:
if (0 == testvariable) {do stuff;} … because it is too easy to type = rather than == and get unexpected results!

It’s ugly. All compilers in the last 30+ years, including Norcroft, spot and warn against =/==.

It means sanitisers can’t spot genuine bugs

Surely it’s not beyond the wit of a sanitiser to recognise such things?

It isn’t as if it’s an alien style of coding. OPTION EXPLICIT in VB5/6 requires that variables are defined, and given a value, at the start of the function (rather like in C) so variable = variable + 1 as described here would throw an error unless variable had previously been defined.

The only thing I can think that it might interfere with is the logic of “variable is accessed before being set”, which may be an issue with normal variables, but are liable to be more of a problem with pointers. It’s up to the analysis tool to decide whether or not a pointer passing through with a NULL value is to be considered “set”. Let’s just say, with all of the tests enabled (how I usually do it), cppcheck appears to cope.

or Dr Smith’s Toolkit

That’s still around?

and hospitals 1 – Because they are the lowest of the low

Yeah, Putin’s minions have been knocking for a while, even trying via a VPN provider in Finland. General scumbag traffic is low relative to those.
The Geo-location filter has been filtering the Ruski origin stuff since they invaded Ukraine (and Ukraine too as the filter isn’t distinguishing between occupied and non-occupied wrt the allocation of IPs

Simply create a potentially useful program and hide something inside.

Sorta like the software tech equivalent of the pager/walkie-talkie stuff in the Middle East ?

Is there any info on the Pager walkie talkie thing that we are allowed to hear?

Was the damage done by a exploding battery?

Could the same thing done with a SmartPhone?

https://www.theguardian.com/world/2024/sep/20/hezbollah-pager-explosion-gold-apollo-hsu-chingkuang-taiwan

I think, at the moment, they’re trying to piece together how it happened. Triggering a massive number of pagers at once, then following it up with walkie talkies is… like something out of a bad Hollywood spy caper. Of course the big question now is how the hell did they manage to actually pull it off.

Yes, I think it was most likely modified battery packs.

As for a smartphone, less likely as these are generally sealed units that have the battery buried in glue and such. It would require infiltrating the actual manufacturing, with no guarantee of where the devices will end up. With pagers and walkie talkies, they typically take fairly standard batteries which are accessible, so one needs to just get into the supply chain and swap the batteries for alternatives. At least, I think that’s the current theory.
And, of course, Hezbollah went low tech because they were worried that their smartphones could be hacked…

This really ought to be in Aldershot, eh?

As for RISC OS, be careful if you’re running it from a USB power brick. You don’t know what’s actually inside those things. Spiders, man, spiders. 🕷️