Filetype for BASIC64/VFP

@Fred

I have had the ‘Run’ icon do BASIC VI for ages, but I realise that I run the file, not incore.

My attempts to implement something along the lines Jeffrey suggested, in BASIC, also came a cropper over similar problems, although I think it should be possible in assembler. It is quite simple to restart the program in BASIC VI by reloading it in the same Wimpslot, along these lines:

REM> use BASIC VI
SYS"OS_GetEnv" TO env$:IF LEFT$(env$,7)="BASIC64" ELSE OSCLI("BASIC64 "+MID$(env$,6))
[rest of program]
END
  

I note that if I do BASIC64 or BASIC at the star prompt and then
>HELP [
the instruction SWP still appears in the listing, even though
this is on a Rpi3, for which this is not a legitimate assembly
instruction. So I take it that the note
BASIC will select the most appropriate version of BASIC VI for the machine
on https://www.riscosopen.org/wiki/documentation/show/*BASIC64 ,
implies that there is not yet a version entirely appropriate for the Rpi3.

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

A bit more info, the OS5.23 was 12-Jan-18.

Revert to a preBASICVFP OS5.23, 13-Jul-17, and the above works.

I note the value of PAGE is different for BASICVFP.

The file can be run with :-

Select   SetTmp SaveRun("TaskWindow \"basic64 <StrongED$Tmp_FileName>\" -quit")

Is it possible to have an easy-to-memorise mnemonic for the filetype? Is &BA5 available?

At any rate, for !Zap…

Open ZapBASIC.Types. It’ll look like this:

Textual Basic   &1FD1                   BASTXT
BASIC           &1FFB                   BASIC
Task BASIC      &1AA5                   BASIC

Simply insert the applicable filetype using BASIC as a template. Here is an example using &BA5 as the type:

Textual Basic   &1FD1                   BASTXT
BASIC           &1FFB                   BASIC
BASIC64         &1BA5                   BASIC
Task BASIC      &1AA5                   BASIC

Then quit Zap if it is running, and reload it. Job done. Dragging such a file will open it as tokenised BASIC.

You cannot (yet) add the filetype to the SaveAs quick list of types, as it appears that the helper programs (MakeConf/MakeMenus) are 26 bit, I’ll need to fix that! :-)

However, if you add the filetype (like Set File$Type_BA5 BASIC64), it will appear in the longer list of available types.

Is it possible to have an easy-to-memorise mnemonic for the filetype? Is &BA5 available?

Or &B64?

how to do this, but whether it’s a good idea to do it

If it’s not, here’s a possible alternative.

*BasaltInit at the start of a program to translate it and do a lot of other things before running it again.

So the idea to extend the method.

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

Even if the directive is a REM?
On the other hand, libraries are called from another Basic file, right? So with the same interpreter?

REM> use BASIC VI
SYS"OS_GetEnv" TO env$:IF LEFT$(env$,7)=“BASIC64” ELSE OSCLI)
[rest of program]
END

Thanks Steve. A very clever tip. So it’s possible for me to implement my idea inside a Basic lib :)

Just to comment as an aside: It would be nice from my POV if the FPEmodule could be updated to allow […] to use VFP.

I agree.

SYS"OS_GetEnv" TO env$:IF LEFT$(env$,7)="BASIC64" ELSE OSCLI("BASIC64 "+MID$(env$,6))

Just because I can, might I offer this more compact (nemo-style) version:

IF1E-40=0SYS16TO$END:OSCLI"BASIC64"+$(END+5)

This uses Sophie Wilson’s own test for BASIC V, which could avoid problems with the case of a *baSIc64 command.

It would be nice from my POV if the FPEmodule could be updated to allow […] to use VFP

This has been discussed a lot. Even if Jeffrey could work his magic on the context problem, the VFP instructions only provide a smallish subset of the abilities of an FPA, or the FPE. That is not to be sneezed at, but it is not a straightforward exchange.

The discussion here isn’t how to do this, but whether it’s a good idea to do it.

I think I now come down on the side of not having a new filetype.

Thanks Steve – your code snippets etc are really helpful.

However, I’d like to argue your very last point (not having filetype) for a moment, more as “devil’s advocate”. I’m imagining a relatively new RISC OS user who is exploring BASIC (or a seasoned one, who doesn’t visit forums). They’d need to read this very thread to find that code example, because most of the rest of us wouldn’t figure it out ourselves.

I kinda envision a situation where people can code in StrongEd or Zap, and save out to disc from a menu giving a choice of BASIC or BASIC64 and then just double-click the file. I suppose the editors could add that line “auto-magically” but then it’d probably need to be explained why it is there (granted, a REM statement could achieve this).

Both solutions work, I guess. We’re back to asking Fred (and Zap maintainers) what they’re most comfy with, I suppose!
(Plus, I like the idea of being able to alter which version of BASIC is used just by setting the type in the filer window, rather than having to faff around in an editor etc!).

While the filetype idea would seem to make sense, would it be a file type for BASIC64 or BASICVFP? What about the other one? Would we need three types for what is essentially the same thing?

They’d need to read this very thread to find that code example, because most of the rest of us wouldn’t figure it out ourselves.

Isn’t that what the user guide is for?

While the filetype idea would seem to make sense, would it be a file type for BASIC64 or BASICVFP? What about the other one?

Wouldn’t the filetype call BASIC64, and let the OS work out whether that was BASICVFP or BASICFPA? Users shouldn’t be forcing one or the other, should they, as that makes things very dependent on the eventual target hardware.

Is it okay to let the system run the most applicable? FPA and VFP are not compatible (byte order inverted for starters) so could have side effects…?

Is it okay to let the system run the most applicable? FPA and VFP are not compatible (byte order inverted for starters) so could have side effects…?

That’s what *BASIC64 already does, so if there are compatibility issues then any existing software is already broken…

At least the file type is a new thing, so deveopers know in advance that if they’re doing things which haven’t been made compatible, then they need to explicitly choose which version they want.

@Andrew

I am not certain about this and your argument is persuasive. However, there are a couple of things that you might consider.

The first is not to proliferate filetypes without very strong reason – there is a limited number. This has probably not been followed too well in the past.

The second is that a BASIC file and a BASIC64 file might be identical, and this could be the case in most circumstances. It is the method of execution, not the content, that varies. It is not an exact parallel, but a Draw file can be ‘executed’ by any number of applications but there is only one filetype. The are other files in the Draw format that can only be ‘executed’ by a particular app, which justifies a separate filetype.

Where a BASIC file falls I am not sure, but I would favour a method of execution rather than a filetype. I am not all that happy with the (unsupported?) TaskBASIC filetype for the same reason.

Edit: Just how important is it to be able to run a BASIC64 file with a double click? If you are exploiting double floats, surely you have gained quite a lot of experience and could hande an extra Obey file?

I am not all that happy with the (unsupported?) TaskBASIC filetype for the same reason.

There are already official filetypes for TaskObey and TaskExec – set by the TaskManager when it initialises. They are different types of execution for how you want to run the same file.

A BASIC64 filetype to enable such files to be easily identified and run I think would be a good thing.

BASICVFP (and BASICFPA) would be going too far, as that difference should be transparent to the vast majority of users – and some effort has already been expended on it to make the choice automatic. If a user is really interested in the difference then obey files can be created to use the appropriate commands (or even set up their own aliases).

A TaskBASIC filetype would be useful to me on occasions … but unfortunately it will not work, as it is over the 8 character maximum! The necessary abbreviation would put me off.

This uses Sophie Wilson’s own test for BASIC V, which could avoid problems with the case of a *baSIc64 command.

Thanks!

This has been discussed a lot. Even if Jeffrey could work his magic on the context problem, the VFP instructions only provide a smallish subset of the abilities of an FPA, or the FPE. That is not to be sneezed at, but it is not a straightforward exchange.

Yes, if you try to replace the FPA module with a VFP one. But one could also provides a software FPEmulator with some VFP inside. Just to speed up things a bit.

The first is not to proliferate filetypes without very strong reason – there is a limited number. This has probably not been followed too well in the past.

In the past I had the experience of applying for official filetypes for a variety of programming languages: Gofer, Bob, AWk, Lua. Originally I applied for two types; one for running a program straight, the other for running it in a taskwindow. After a while I realised that the latter was a waste of filetype-real-estate. Instead I began to use a small sticky application, !TaskW . Dragging a file’s icon to !TaskW’s iconbar-icon runs it in a taskwindow. This is a much more economic method of implementing the facility of running things in taskwindows. Just a flick of the wrist, no use of the keyboard required, no need to lock the program into one mode of use by giving it a separate filetype.

This has been discussed a lot. Even if Jeffrey could work his magic on the context problem, the VFP instructions only provide a smallish subset of the abilities of an FPA, or the FPE. That is not to be sneezed at, but it is not a straightforward exchange.

Yes, if you try to replace the FPA module with a VFP one. But one could also provides a software FPEmulator with some VFP inside. Just to speed up things a bit.

Are you and Jim determined to ignore people saying “it’s not going to be straightforward to do”?

:-)

A TaskBASIC filetype would be useful to me on occasions … but unfortunately it will not work, as it is over the 8 character maximum! The necessary abbreviation would put me off.

TskBasic is &AA5, set up by nemo’s !InAWindow applet.

Are you and Jim determined to ignore people saying “it’s not going to be straightforward to do”?

Straightforward: no.
But perhaps simpler than the full&big&perfect plan.

‘Little plan’ could be:
- Choose one operation (* for example).
- Set context with VFPSupport
- Use VFP opcode
- Drop context
- See if it’s faster than the software only solution.

Of course, that would be very suboptimal. But, hey, if it’s faster? My idea is not a VFP version of FPEmulator, but a ‘VFP accelerated’ version of the current FPEmulator. A temporary and short term solution.

But perhaps it won’t be faster :)

Instead I began to use a small sticky application, !TaskW .

It had occured to me that a similar !Basic64 app would do the execution job I would rather see.

Edit: Here is !Basic64

It uses Basalt, so no guarantees it will work on latest machines.

Of course, that would be very suboptimal. But, hey, if it’s faster?

Problems:

• It’s a bad idea, if you are going to be performing a series of calculations you’ll need how many context switches for the VFP supported instructions?
• It’s a bad idea, the order of the words in a little-endian double is different for FPA and VFP. While it’s fairly easy to bodge using VFPs advanced load/save, you’ll be constantly bodging values to and from VFP native in order that the FPE code can use the values. Not to mention literals embedded in a program will be wrong, etc etc.
• It’s a bad idea, because of the above two points, no testing (artificial or otherwise) will give you an idea of the speed difference between FPE and VFP. For what it is worth, we’ve already done this natively. 388 centiseconds for FPE versus seven centiseconds for VFP to multiply something four million times (link)
• It’s a bad idea, rather than rewriting FPE to use VFP (which is actually somewhat different), it would be better to leave FPE alone for legacy software, add native VFP support to the compiler suite, and then a small VFP helper (perhaps part of VFPSupport?) that does whatever is necessary for the FP operations not handled in hardware.
• We’d also need some sort of flag in CLib to tell it what format the floating point values are – they aren’t the same. But maybe some magic could be done with function pointers to alias from one to the other?

And, as usual, there’s also that little issue of a lack of developer time…

In most cases, the results of a BASIC app don’t depend on the FP precision. Those already out there that require BASIC64 already have a setup that automatically invokes BASIC64, usually the !Run file of an app.

The same thing applies going forward. Most don’t matter; those for which it does are probably apps with a !Run file. Any others could perfectly well be run from an Obey file.

So it seems to me that the case for a new filetype for BASIC64 files is somewhere between marginal and non-existent.

It had occured to me that a similar !Basic64 app would do the execution job I would rather see.

I should explain what I mean by a sticky . I have a small BASIC program called stick in !Boot.Library . It expects the pathname of an application (the sticky) as its first commandline argument. It creates a wimp task that is named by that application and uses the application’s !Sprite file to put an icon on the iconbar (and its Template file to provide an ProgInfo dialogue box from the iconbar-icon’s menu). The wimp task’s only job is to report clicks on and drags to its iconbar-icon. The application should be furnished with optional Obey files called !Select, !Adjust, !Drag to respond to these user-actions. It is just a way of writing a particularly simple sort of wimp program without actually writing a wimp program (because stick handles all that for you). Stickies do not need !RunImage files.

So, omitting minor details, !TaskW has for its !Run file just

stick <obey$dir>

Run %0