Filetype for BASIC64/VFP

Just wondering if there’s a filetype defined for programs written using the extra capabilities/performance of BASIC64/VFP?

As I understand it, BASIC64/VFP are now “joined at the hip” as it were, so I assume a single filetype would probably suffice. I note that !SciCalc gets round this by using *BASIC64 <Obey$Dir>.!RunImage to launch itself, but for people testing BASIC files by double clicking them, I’d have thought some kind of identifier would be needed to ensure the right BASIC module handled them?

I may, of course, be missing something obvious!

I think the idea is that these days a BASIC program with be called by an !Run file that will specify which sort of BASIC to use.
For standalone programs, perhaps you could alias the *BASIC command to start BASICVFP instead?

Thanks Rick, but that’s helpful, but really rather confirms the problem :(

By (farcical) extension, we wouldn’t really need (most) filetypes at all, because everything could be handled by obey files or resetting aliases (every filetype could be either “obey” or “data” more or less!). The usage paradigm of RISC OS is to be able to double-click files to sensibly execute them, and if we start having to alias the BASIC command, it probably suggests that it is time for a new type to be issued.

Where I’m coming from is that it would be nice for people to start being able to make significant use of BASICVFP and the hardware in modern CPUs. Quite a few people know how to program in BASIC but have never ventured further into C/assembler, so providing them with a nice smooth way into hardware accelerated maths would be really nice.

That being said, I’d be interested to hear Fred G’s thoughts as maintainer of StrongEd as to whether this makes sense, as an additional BASIC filetype might have ramifications for BASIC editors too. One wonders if somehow the existing filetype could be used and some identifier be present at the start of the file so that BASIC knows to use BASIC64/VFP. But maybe I’m over-complicating things. Ironically I recall Acorn’s early developer notes on filetypes which envisioned a small number of generic types with identifiers early in the file – for example a “savegame” filetype with the game’s name as the first few chars of the file.

*BASIC enters normal BASIC V.
*BASIC64 enters BASIV VI. If VFP is available, it will be used, else FPA.
*BASICFPA enters BASIC VI using FPA, even if VFP is available.
*BASICVFP enters BASIC VI using VFP … but command only exists on VFP machines.

If FPA or VFP is used, it is shown in the startup message.

See new BASIC manual for full details!

Thanks for that clarification of how 64/VFP interact – sounds like *BASIC64 is the way to go, as per !SciCalc.

But, that still doesn’t account for someone double clicking a BASIC (64/VFP) program on their hard drive, or a utility filer_running a BASIC program, as you’d need to alias the BASIC command as Rick said.

I appreciate this hasn’t really been necessary before because use of BASIC64 was pretty rare. However, I’d imagine that quite a few people would like to start utilising VFP as a “cool new toy” when playing around with BASIC, and having to make obey files for each one seems, erm, excessive!

One wonders if somehow the existing filetype could be used and some identifier be present at the start of the file so that BASIC knows to use BASIC64/VFP.

The *BASIC command (and friends) allow you to specify a memory address of an already-loaded program, don’t they? So in theory the first couple of lines of your BASIC program could be a check to see if the program is running under the preferred interpreter, and if not, invoke it, passing in the address of the already-loaded program. Or even just combine "BASICVFP " with the command tail from OS_GetEnv (which would have the benefit of preserving any command line arguments)

I’m thinking if we were to define a new file type, perhaps it should be “LegacyBASIC” which runs BASIC, with the new default behaviour to run BASICVFP (on capable machines)?

That’s a thought, Rick, but I don’t know the ramifications of running every BASIC program through BASIC64/VFP – just how compatible are they?

Hello,
Sorry that this isn’t very closely related to the subject of this thread, I’ve got a quick question I wanted to ask that this reminded me of.

I’ve heard that there are two commonly used C compilers for RISC OS, gcc and the DDE. I’m writing a game in C which does a lot of maths which I’ll want to bring to RISC OS in the future.

I remember hearing one of the C compilers for RISC OS doesn’t support VFP, and because of that in some cases BASIC programs that do lots of maths end up faster than C versions of the same program.

My question is, if I compile my game with GCC, will it be able to take advantage of VFP?

Sorry that this isn’t related to the thread.

I don’t know the ramifications of running every BASIC program through BASIC64/VFP – just how compatible are they?

It might not be a good idea. BASICVFP and BASIC64 have some differences (see Appendix A of the new BBC BASIC Reference Manual), and presumably they both differ from BASIC in the other areas where BASIC diverged from BASIC64 before (things like the | operator, the files written by PRINT#, and the information exposed by CALL).

To be honest, running BASICVFP code by calling *BASIC64 -quit seems like a sensible route: that way, there’s an explicit action carried out by the user which suggests that they’re aware of the potential issues.

My question is, if I compile my game with GCC, will it be able to take advantage of VFP?

Yes. GCC supports VFP; Norcroft doesn’t.

That’s a thought, Rick, but I don’t know the ramifications of running every BASIC program through BASIC64/VFP – just how compatible are they?

They’re not fully compatible, that’s the main reason why we have different commands in the first place!

Apart from the difference in numerical accuracy (which could throw off some software which relies on results being rounded to specific values), there’s also:

• Increased memory usage in BASIC64 (could throw off programs which have finely-tuned memory reservation)
• Different memory format for floating point numbers, will break anything that reads/writes the values directly (e.g. via | operator)
• Floating point numbers written to data files will also differ – could break any manual processing that programs do on their files
• If inline assembler wants to use floating point numbers, the interfaces used by that will be different as well (they differ between all three BASIC variants, since for each one the interfaces are optimised for the appropriate floating point implementation)

In reality I’d expect the first and last to be the most relevant, although if you’re using inline assembler then it’s reasonable to assume the middle two could cause problems as well.

My question is, if I compile my game with GCC, will it be able to take advantage of VFP?

Yes. You’ll need to use the right compiler flags (-mfpu=vfp2 might be the bare minimum?), and you’ll have to link against UnixLib if you aren’t already.

OK, so I think that rules out making BASIC64/VFP the default, which then leaves a filetype for BASIC64/VFP as a useful (but not essential) addition.

As others have said, there’s a workaround without, but being able to set the filetype to BASIC64 then just double click it (like any other RISC OS file) seems fairly desirable. Certainly for hobbyist type users, who may not be writing desktop apps with the usual application structure.

Certainly for hobbyist type users, who may not be writing desktop apps with the usual application structure.

Only if they’re stuck back in the days of the BBC Micro. Pretty much the only valid excuses for singletasking these days are:

• It’s a game
• It needs to work singletasking for specific speed (like directly polling a hardware device or needing millisecond accurate timing)
• The programmer is lazy

While writing a program to run under the Wimp is more “painful”, most of it is boilerplate stuff and there are libraries available to make this simpler. There are many benefits to writing a multitasking program. It can happily co-exist with everything else, and you can make use of an API based upon windows and icons, using a simple paradigm that every RISC OS user knows…

If you have the official SD image, there’s a book here: $.Documents.Books.Beginners Guide Wimp.Guide/pdf and there’s just such a “framework” to use here: $.Programming.DrWimp.

I have an alternative method to offer using StrongED, which will run the program being edited incore with the Toolbar ‘Run’ icon.

It does not run BASIC VI programs as standard (at least not in the version I use) but I have modified the icon definition to include this.

On the rare occasions this does not serve I make a mini-app with a !Run file and *BASIC64 etc.

Pretty much the only valid excuses for singletasking these days are:

another excuse is to single task a multi-tasking BASIC prog by double-clicking it. Then when it falls over, when it executes ‘END’ after an error you can exit it and then be able to examine all the BASIC variables to see what went wrong.

Precedent: Basic26 (Aemulor) has its own filetype, F7A.

For one’s own use, choosing one’s own number :-

Set File$Type_019 Basic64
Set Alias$@RunType_019  Basic64 -quit |"%%0|" %%*1
IconSprites <Obey$Dir>.file_019

A formal allocation seems reasonable.

One solution could be to add a Shebang/directive in first line of source code, that would define who should launch the code.

Basic / Basic64 / BasicFPA / BasicVFP. And why not even Brandy, to use the Brandy interpreter, and so ease the making of a crossplatform app. Could be something like ‘BasicVFP-BasicFPA-Basic64’: use BasicVFP if available, or BasicFPA if available or Basic64.

The best would be a new ‘Basic’ command, that would check for a Shebang, and if not present, launch the old Basic. So it will work even when the code is launched from a text editor.

We could imagine other uses for a preprocessor like this.

Just to comment as an aside: It would be nice from my POV if the FPEmodule could be updated to allow the existing ‘Norcroft’ (i.e. now ROOL) generated programs to use the VFP as FP hardware without any recompiling or need to change compiler.

One solution could be to add a Shebang/directive in first line of source code, that would define who should launch the code.

Why would we consider doing that, when the effect can be achieved cleanly and correctly with a new filetype? The discussion here isn’t how to do this, but whether it’s a good idea to do it.

A couple more observations. ;-)

Precedent: Basic26 (Aemulor) has its own filetype, F7A.

Basalt has its its own filetype, &9FB, for translated programs, which are still BASIC. They are required for use as libraries and they will display in BASIC mode in StrongED.¹ They will also run when double-clicked.

The *BASIC command (and friends) allow you to specify a memory address of an already-loaded program, don’t they? So in theory the first couple of lines of your BASIC program could be a check to see if the program is running under the preferred interpreter, and if not, invoke it, passing in the address of the already-loaded program.

I would support this way if it is really necessary. I know such a thing is feasible, because Basalt uses *BasaltInit at the start of a program to translate it and do a lot of other things before running it again.

¹ They are not editable, though. ;-)

@AndrewR

…, I’d be interested to hear Fred G’s thoughts as maintainer of StrongEd as to whether this makes sense, as an additional BASIC filetype might have ramifications for BASIC editors too.

The new filetype would need to be added to the list of filetypes that StrongED uses to decide if the file needs to be detokenised.

No problem for new versions but old versions would not be able to edit the new filetype correctly. However StrongED 4.69f9 recognises 4 filetypes so it would be possible to create a patch to replace one of those filetypes.

@JeffreyL

So in theory the first couple of lines of your BASIC program could be a check to see if the program is running under the preferred interpreter, and if not, invoke it,

That not work as the program may have insufficient space in front of it for the BASIC workspace. See my reply to SteveD below.

@SteveD

It does not run BASIC VI programs as standard (at least not in the version I use) but I have modified the icon definition to include this.

This is only possible with test releases of StrongED 4.70 as earlier version always reserved 4kB in front of a BASIC program but BASIC64 needs 6kB.

@DavidF

One solution could be to add a Shebang/directive in first line of source code, that would define who should launch the code.

This may cause problems with BASIC libraries where the first line is expected to contain the library name which is used in error messages.

Quick thought on an icon for such a filetype – the BASIC icon with an enlarged “.” (decimal point" in the corner. I know this may not be ideal for european users (I think you guys use commas for decimal separator?) but given that the main differences in BASIC64/VFP are to do with floating point, an icon reflecting the “point” seems logical. Better than “64” or “VFP” specifically, as the underlying BASIC interpreter will vary.

An alternative might be to do (.) to indicate arrays and floating point.

I have an alternative method to offer using StrongED, which will run the program being edited incore with the Toolbar ‘Run’ icon
It does not run BASIC VI programs as standard (at least not in the version I use) but I have modified the icon definition to include this.

That sounds like a simpler proposition than an extra filetype and its associated editing implications.

Using StrongED 4.70a12, as a simple test this line is added to the BASIC ModeFile to give a menu entry from the bottom toolbar.

Menu      Run BASIC64
Select    SetTmp() RunBasic(Nosave, Quit, Taskwindow, BASIC64)

This works perfectly on OS4.39 but gives a Bad Program error on OS5.23. Changing the last argument to BASIC works as expected in OS5.23

This is only possible with test releases of StrongED 4.70 as earlier version always reserved 4kB in front of a BASIC program but BASIC64 needs 6kB.

I’d say it’s a rare application that manages to cater for a new feature despite being an old version.
Provided the new releases cope with the old as well as the new (or would that be current?) then all is well.

Quick thought on an icon for such a filetype – the BASIC icon with an enlarged “.” (decimal point" in the corner.

Top right or top left? Would have to be top otherwise it wouldn’t be “floating”