Proposal to extend @platform% (again)

[Hated Moron]

There are a few platforms which can use either x86 or ARM processors, notably Android, Linux and MacOS, and there is currently no straightforward and reliable way for a BBC BASIC program to discover which variety it is. Although this won't often matter, it will if you want to incorporate assembly language code or make SYS calls which use different ABIs depending on the CPU type.

I am therefore considering extending the @platform% variable to provide this information, perhaps by setting bit 7 if it's an x86 CPU but not if it's an ARM CPU. However such a change comes with compatibility implications, because existing programs may assume this bit is always cleared. For example the sortlib library currently assumes the LS 8 bits of @platform% will be &40 in the case of 64-bit Windows.

So the question is: does the value of providing this information outweigh the potential incompatibility with existing programs? Does anybody have any programs which would be adversely affected by such a change? Is there a better way that the information could be provided?

[Edja]

Does anybody have any programs which would be adversely affected by such a change?

I'm not sure. In some of my BB4W programs, written over the years, I use SORTLIB.
For a next program (if not relying on COMLIB), I would use BBC BASIC for SDL. Will I be able to use SORTLIB as before or, if not, what will change?
If you do adapt @platform%, wouldn't it be a solution to also modify SORTLIB internally in such a way that its use remains as before?
Regards,
Edja

[Hated Moron]

Will I be able to use SORTLIB as before or, if not, what will change?

If you always use INSTALL there won't be an issue, because the code in the library will be compatible with the code in the run-time engine it came with; the two will be updated together and remain 'in phase'. Whenever an 'application bundle' is created the library matching the run-time engine will be embedded.

Where a problem certainly could arise is if - against my recommendation - you have copied-and-pasted code from a library into your own programs (or have even used File... Insert to copy the entire library). Then you could end up with an incompatibility between the now out-of-date library code and the newer run-time engine.

I don't know why people ever copy libraries into their own programs, it may be distrust in the INSTALL statement, or a lack of understanding of how the file-embedding works when you create an application bundle, or something else. But I know they sometimes do, and that might result in failures if I change something.

[Flatlander]

Would it be safer to add something like @architecture%, if compatibility is a top priority?

Or, for example, @systemflags/settings%% as a future catch-all?

[Hated Moron]

Would it be safer to add something like @architecture%, if compatibility is a top priority?

The same suggestion (actually @cpu%) was made at The Distillery forum but, as I pointed out there, adding another system variable is much more difficult - and risky - than you could possibly imagine!

The system variables (just like the ordinary variables created at run-time) are stored as a linked list - they are accessed using exactly the same routines - and since the system variables are pre-defined there has to be a way of creating that linked-list at 'compile time'.

It's possible that somebody skilled in the art of pre-processor macros could devise a way of doing that in C, but because I don't have the necessary skills I chose to define the system variables in an assembly language module. Assembler code is quite well suited to that task.

But the consequence of that decision is that there are five different source modules in which the system variables are defined: bbdata_x86_32.nas, bbdata_x86_64.nas, bbdata_arm_32.s, bbdata_arm_64.s and bbdata_wasm32.c. They would all have to be modified, and it's not easy!

So I've decided not to make any changes after all; too difficult and too risky. The various libraries and other programs will have to continue to use ad-hoc means to identify the CPU type, as they always have.

[svein]

Would it not be relatively safe and easy to simply add an 'internal routine' which can be called from both assembler (call "name") and basic (usr(adr)).

Or simply extend the functionality of FN_cpuid(level%,cpuid{}) in ASMLIB.

Svein

[Hated Moron]

Would it not be relatively safe and easy to simply add an 'internal routine' which can be called from both assembler (call "name") and basic (usr(adr)).

When you say an 'internal' routine I presume you mean one that is built into the code of the interpreter, so that it bypasses the restriction that iOS and Emscripten don't support machine code in RAM?

Yes, you could do that, but the address of the routine would need to be 'discoverable', most straightforwardly as an additional entry in the @fn%() table. This again means changes to the bbdata modules, admittedly nothing like as difficult or risky as adding a new 'system variable'.

So there would be a need to modify six source files, the one containing the 'callable' code itself and the five bbdata modules. Perfectly practical, but on balance I feel that the effort outweighs the benefit. It's rare to need to know the CPU type separately from the platform, and it's likely to be relevant only in a library rather than 'user' code.

Or simply extend the functionality of FN_cpuid(level%,cpuid{}) in ASMLIB.

ASMLIB is specific to x86_32 platforms (it's not even supplied with the others).