Native ARM Co Pro: won't run FPA code e.g. BASIC64 AKA FBAS135

[BigEd]

Running FBAS135 results in the Pi hitting a native exception, because the Pi supports VFP for floating point but code for earlier ARMs uses FPA. See here.

SWI 0002006e not implemented ************
Undefined Instruction at 0000F3BC

The offending instruction is "WFS r0" which is a write to the floating point status register.

This has been mentioned on stardot, see here.

[Thanks to Dave for explaining this]

The only option here would be to look for some code to emulate FPA, and add it in to the Undefined Instruction exception.

[fordp2002]

Would be good to trap the FPA instructions a bit better and give a more meaningful error. I favour a new BBC basic with VFP support as you all know by now.

[hoglet67]

The ARM Eval system includes the original floating point emulation code (fpe) on disk 3:
http://mdfs.net/Mirror/Archive/Acorn/ARMEval/Disk3.zip

This does "install" on the Native ARM, but BAS135F still fails.

I think the source code for FPE is BSD licensed, and is here:
https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/HWSupport/FPASC/coresrc/s/

This merits further exploration/experimentation.

Dave

[fordp2002]

Sorry Dave can you point me to the source code for BAS135 / FBAS135. I wonder if I can hack some VFP support in using a mixture of C for the hard stuff and assembler for the simple stuff. (My maths is not up to much so I will not be coding sine and cosine in assembler any time soon).

[hoglet67]

@fordp2002 -- it's still in the old PiTubeClient git repo:
https://github.com/hoglet67/PiTubeClient/tree/master/bbc_basic_1_35

[fordp2002]

Thanks. Looks like "[ FP=0" is the main text to search for!

[sjnewbury]

Why not have two ARM co-pros; one 24/32-bit with with trap handlers for any missing instructions (including FPE for FPA) for compatibility with early ARMs including the ARM Evaluation System software and another pure native (even perhaps a 64-bit with a suitable pi)?

[hoglet67]

Steven, I'm probably not understanding what you are suggesting...

There already are two ARM Co Pros:

• Co Pro 12 is an emulation of a 26-bit ARM2 (borrowing some code from MAME), and should run anything that the original ARM Eval system does
• Co Pro 15 is the native ARM Co Pro, based loosely on the set of RISC-OS like APIs that the Sprow Arm 7TDMI Co Pro exposes.

[sjnewbury]

@hoglet67, clearly I'm not keeping up with developments. My point was "Co Pro 15" doesn't need to emulate FPA since no 32-bit** code will ever use it (except for possible rebuilds of bas135!), but it is useful for Co Pro 12. But I guess that's redundant especially if the MAME sourced emulation includes FPA plus it doesn't need instruction traps anyway since it's all emulation!

** AFAIK only one 32-bit addressing capable ARM(v3) ever had an FPA, the ARM7500FE

[chromi]

Looking through the BAS135 code linked, the FPA doesn't actually seem to be used for anything. The only actual FPA instruction I can find is that initial WFS. For example, searching for "ADF" (add float) only hits in the assembler token table. So you could probably get FBAS135 to work on a modern ARM by just commenting (or patching) out that WFS instruction.

[hoglet67]

There is now a version of BBC Basic called BASICVFP that uses VFP:
https://www.riscosopen.org/forum/forums/3/topics/9081

Here's a disc image that includes it:
BBC BASIC VI (VFP) 1.67 (03 Jun 2017)

basicvfp.zip

(BASICVF is the compressed module and XBASICV is the uncompressed module)

I tried running this, but it crashed, because it also uses FPA instructions:

Undefined Instruction at 00010478
Registers:
  r[00]=00070000
  r[01]=000086D4
  r[02]=000086DC
  r[03]=00010190
  r[04]=0E47B2B8
  r[05]=0E47B2B8
  r[06]=00000003
  r[07]=00000010
  r[08]=00008700
  r[09]=0E48D034
  r[10]=400F0110
  r[11]=0E48D060
  r[12]=0E502F84
  r[14]=0001047C
Memory:
  00010468=E2812008
  0001046C=E3A00001
  00010470=EF02006E
  00010474=E3A00807
  00010478=EE200110 <<<<<<
  0001047C=E3A0004F
  00010480=E24F1FC7
  00010484=EF00000D
  00010488=E1A03000
Flags:
  NZCV--------------------IFTMMMMM
  00100000000011110000000100010000 (User Mode)
Halted waiting for reset

Looking at the source:
https://www.riscosopen.org/viewer/view/apache/RiscOS/Sources/Programmer/BASIC/s/Basic?rev=1.28;content-type=text%2Fplain

This is here at the WFS instruction here:

MAIN    MOV     ARGP,#VARS
        ;Create the SWI 0              ;MOV PC, R14 in the SWICODE data area
        ;and    then do a SYNCHRONISECODEAREAS, ranged.
        MOV     R0, #&EF000000         ;SWI 0
        LDR     R2, OSESCRT            ;A handy MOV PC,LR
        ADD     R1, ARGP, #SWICODE
        STMIA   R1,{R0,R2}
        ADD     R2, R1, #8             ;Size of SWICODE area
        MOV     R0, #1
        SWI     XOS_SynchroniseCodeAreas
 [ FPOINT=1 :LOR: FPOINT=2             ;only necessary for FPOINT=2 since we still rely on FPA for some ops
        MOV     R0,#&70000
        WFS     R0 
 ]

WFS is an FPA instruction to write the floating point status registers.

(It's the same failure that started this thread!)

So to run this on a Pi, we would still need an FPA emulator.

Shame....

[chromi]

On 8 Apr, 2021, at 5:50 pm, David Banks ***@***.***> wrote: WFS is an FPA instruction to write the floating point status registers. (It's the same failure that started this thread!) So to run this on a Pi, we would still need an FPA emulator.

From the blog post: "The initial version of BASICVFP is expected to rely on FPA/FPEmulator for implementing the trig/power operations that are not supported by VFP. Future versions may provide more optimal routines, e.g. based on the routines used by Steve Drain’s “Float” module." I assume that once these routines are implemented via the VFP, the remaining links to FPA-based infrastructure will go away. In RiscOS, the FPA instructions just trigger traps to the emulator. - Jonathan Morton