GitLab

Detail:
  fp32atan2 would give wrong results for special cases. For all of these
  the sign of x was copied onto the result (rather than the sign of y as
  intended); where both were ±INF a register with unknown value was used
  to determine whether to add ±pi/2.

Version 0.18. Tagged as 'VFPSupport-0_18'

Detail:
  A stack imbalance resulted when NaN was encountered.

Version 0.17. Tagged as 'VFPSupport-0_17'

For those machine types that don't need the C support code (currently, Cortex-A8 and A53) the SupportCode.s source file is skipped. However, the elementary functions want the exception error blocks contained within.
Transplant those error blocks into the globally visible Errors.s source file.

Version 0.16. Tagged as 'VFPSupport-0_16'

The Test/Elementary test bed could allow some infinities to erroneously be matched on NaN.
Re-ran the tests, VFP variants still pass.

In order to reduce reliance on FPA, where we rely on the FPA transcendentals in various places which are subsequently caught and emulated via FPEmulator, expose VFP implementations of these for wider use. They are the base elementary functions corresponding to SIN/COS/TAN/ASN/ACS/ATN/POL/LOG/LGN/EXP/POW and as a bonus an FMA for pre-VFPv4 variants.

Function signatures follow their C standard definition and a generic APCS to allow their use from high level languages.

The FMA implementation comes from OpenLibm, translated by hand from C, and the accompanying test bed checks for bit identical results to ARM's instruction. For that to make sense clearly it needs to be run on something with VFPv4 otherwise it's comparing itself with itself!

When not available in hardware the elementary functions call across to these slower software implementations via a VFused macro.

Makefile: Add the new object files
VFPSupport: New SWI name, and reason flags
GetAll.s: Get the maths helpers
Macros.s: Some helper macros for bit manipulation of FP numbers
Module.s: New SWI
SupportCode.s: Error handler to recover R12 and optionally throw an error

Tested with a special version of BASICVFP which replaces the FPA transcendentals with a call to VFPSupport instead.

Version 0.15. Tagged as 'VFPSupport-0_15'

Remember to fill in the module title for %0.

Makefile: Add A53 to the list that don't need any support
GetAll.s: Trim some unneeded headers
Macros.s: Use instruction directly now ObjAsm supports it
Module.s: Fix stack imbalance in SupportHandlerTemplateSV, add Cortex-A72 table entry
Salvaged from a previous concept when FMACs would be fixed up by the abort handler.

Library release from 2015 is almost identical to 2b, except
* Lots and lots of comments improved, legalese wording changed
* Fix for 128 bit shift in softfloat-macros
* A few 32->32 and 64->64 casts which do nothing on ARM

Version 0.14. Tagged as 'VFPSupport-0_14'

Wrap changes in __riscos so it's easier to see where they are. Binary identical result.

Detail:
  hdr/VFPSupport - Define VFPSupport_Features reason code 3, for reading extra feature registers
  s/Macros - Use ELIF to shorten myVMRS & myVMSR macros. Add MVFR2 support to myVMRS.
  s/Module - Implement VFPSupport_Features 3, for reading MVFR2 (and three other values reserved for future proofing). Since there doesn't seem to be an easy way of detecting the presence of MVFR2, we fall back on a list of known-good FPSID values, like with MVFR0/MVFR1 on pre-VFPv3 systems. Also update VFPSupport_ChangeContext to do a dummy load from the new VFP context, to help trap bad contexts before we've updated our state to indicate that that context is active.
  Test/features,ffb - Add VFPSupport_Features 3 output
Admin:
  Tested on Raspberry Pi 1, 2, 3


Version 0.13. Tagged as 'VFPSupport-0_13'

Don't claim to support software emulation of short vectors if the FPSCR doesn't implement the LEN/STRIDE fields

Detail:
  In ARMv8, VFP short vectors are completely obsolete, to the point where implementations aren't even required to implement the FPSCR fields that control their operation.
  Our software short vector emulation relies on the hardware taking the undefined instruction vector when a VFP data processing op is executed with the LEN/STRIDE fields set to non-zero values; if those fields are hard-wired to zero then our emulation can never be run.
  File changes:
  - s/Module - Check whether FPSCR LEN+STRIDE fields are implemented before deciding whether to install the short vector support code
  - Test/test7,ffb - Refuse to run if short vectors aren't supported (whether hardware or software). Bail out early if we spot an FPSCR inconsistency.
Admin:
  Tested on Cortex-A53, Cortex-A7


Version 0.12. Tagged as 'VFPSupport-0_12'

Detail:
  Replace conditionally executed undefined instructions with branches over
  on opposite condition.
Admin:
  Tested on Raspberry Pi 3.

Version 0.11. Tagged as 'VFPSupport-0_11'

Detail:
  Makefile - Simplify decision about whether to include support code. More hardware needs it than not, so have a list of machine types which don't need it rather than a list of machine types which do.
  hdr/VFPSupport - Add definitions for new VFPSupport_Features reason code
  hdr/shared - Add some comments for extra clarity
  s/Instructions - Add support for emulating VFPv3 'VMOV immediate' instruction
  s/Module - Update hardware detection & support handlers to deal with Cortex-A7, Cortex-A9 and Cortex-A15, all of which report different subarchitectures and differ in method of reporting exceptions despite the fact they basically all have the same requirements as far as support code is concerned (support code only required if we want short vector emulation). Implement the new VFPSupport_Features reason code, which returns information about whether short vectors are supported.
  s/SupportCode - Extend support code to cope with Cortex-A7, A9, A15 & VMOV imm emulation.
  Test/features,ffb - Simple test of VFPSupport_Features SWI
  Test/test7,ffb - Test for VFPv3 'VMOV immediate' handling in scalar & vector mode (HW scalar implementation tested against SW vector implementation)
Admin:
  Tested on ARM1176JZF-S, Cortex-A7, Cortex-A8, Cortex-A9
  Cortex-A15 supported tested 'in theory' by forcing appropriate support code to be installed on Cortex-A9


Version 0.10. Tagged as 'VFPSupport-0_10'

Detail:
  Makefile - Update makefile to correctly detect the new RPi machine type as needing support code
Admin:
  Tested on Raspberry Pi model B


Version 0.09. Tagged as 'VFPSupport-0_09'

Detail:
  softfloat/softfloat-macros, softfloat/c/softfloat - The latest version of norcroft fixes the compiler bugs that have workarounds for here. So, insert a version check so that the workarounds are only used on old compiler versions.
Admin:
  Tested on Raspberry Pi
  VFP build of testfloat passes all tests at -level 2


Version 0.08. Tagged as 'VFPSupport-0_08'

Update for BuildSys-6_60. No need to force things in ModuleLibs to blank now.

Version 0.07. Tagged as 'VFPSupport-0_07'

Detail:
  This update adds the support code necessary to allow the VFPv2 coprocessor in the Raspberry Pi to be used in its full IEEE-compliant mode, and to add support for the generation of errors on VFP match exceptions (division by zero, etc.)
  SoftFloat Release 2b (http://www.jhauser.us/arithmetic/SoftFloat.html) is used to perform the floating point calculations in software, ensuring their accuracy.
  As with FPEmulator, the support code will only be included on machines which require it; at the moment this decision is handled by the makefile, based around the target machine type.
  Note that the current version of the support code does not implement default NaN or flush-to-zero mode, so it is not a fully accurate emulation of the hardware.
  Also added a new SWI, VFPSupport_ExceptionDump, for creating and reading a VFP context exception dump, and a new reason code to VFPSupport_Features to query which exception enable bits are supported
  File changes:
  - Makefile - Rewritten to use the CModule fragment, and to add the necessary rules for (optionally) building the support code.
  - Licences - File summarising the different licences used by different portions of the code
  - Test/test2c,ffb, Test/test3,ffb, Test/test4,ffb, Test/test5,ffb, Test/test6src,ffb - Several test programs for validating behaviour of the support code, mainly focused around unusual causes of exceptions and validating instruction decoding and short vector support
  - actions/ARMv7_VFP, arctions/common, c/head, cache/classify - decgen files for building the instruction decoder. This decoder is only used for synchronous exceptions, to determine whether the instruction is or isn't a valid VFP instruction. Asynchronous exceptions utilise a simpler, hand-crafted decoder in the assembler sources.
  - h/classify - Header for the decgen decoder
  - hdr/shared - Header with some definitions shared between the C and assembler sources (will be Hdr2H'd to generate the C header)
  - hdr/VFPSupport - Updated with new error numbers, SWI definitions
  - s/CSupport - Math support functions from the C library sources, required by SoftFloat
  - s/Errors - Added new error definitions
  - s/GetAll - Include support code if necessary. Add debug switch, plus optimisation switch for machines with 16 D registers
  - s/Instructions - Core data processing instruction emulation code. This file is included twice, once for single precision and once for double precision. The code calls through to the SoftFloat routines to perform the calculations.
  - s/Module - Adjust handling of undefined instruction vector to allow the support code to be installed instead of OldHandler if necessary. Initialise the support code as necessary. Add new SWIs & reason codes.
  - s/SupportCode - Undefined instruction handler which controls the rest of the support code. Also raises RISC OS errors as necessary (division by zero, etc.)
  - softfloat/* - The SoftFloat library sources. It's been tweaked in a few places for integration with the assembler support code, but otherwise no changes to the core logic were necessary.
  - Resources/UK/Messages - Updated with new error text
Admin:
  Tested on Raspberry Pi & BB-xM
  Support code tested using the supplied test routines and the TestFloat tool (http://www.jhauser.us/arithmetic/TestFloat.html)


Version 0.06. Tagged as 'VFPSupport-0_06'

Detail:
  This is a copy of VFPSupport-0_05 from bsd/RiscOS/Sources/HWSupport
  It's being moved to the 'mixed' folder as the next version will contain sources using several different licences
Admin:
  Untested


Version 0.05. Retagged as 'VFPSupport-0_05'

Detail:
  s/Module - Fixed context save & restore code to ensure FPEXC EX & FP2V bits are clear when accessing FPSCR and the main VFP registers. Without doing this, attempting to save or restore a context which has a pending exception will trigger an exception itself.
  Test/test2,ffb - Simple test to make sure save/restore of contexts with pending exceptions works properly
  Test/test1,ffb - Added brief description, changed file from plain text to tokenised BASIC to prevent it accidentally happening later on
Admin:
  Tested on Raspberry Pi
  Programs which need support code to run or trigger math exceptions no longer trigger an undefined instruction abort from within VFPSupport


Version 0.05. Tagged as 'VFPSupport-0_05'

Detail:
  s/Module:
  - CheckHardware can now correctly determine that the ARM1176JZF-S is ARMv6, not ARMv7
  - Added initial support for VFPv1/v2; currently only supports implementations that use FSTMX/FLDMX standard format 1, and for which we know we can read the MVFR0/MVFR1 registers. I.e. only VFP11 supported at present.
  - Fixed null pointer dereference in ExamineContext when examining the active context
Admin:
  Tested on Raspberry Pi with high processor vectors
  Note there is no support code present, so using the coprocessor outside of RunFast mode will result in aborts.


Version 0.04. Tagged as 'VFPSupport-0_04'

Detail:
  Resources/UK/Messages, s/Errors, hdr/VFPSupport - Errors now declared in public header. New/updated error messages and symbols.
  s/GetAll - Changed GET order to work with errors in header file
  s/Module - Disallow instantiation. Manually issue Service_ModulePostFinal during finalisation, to give clients slightly more warning than the kernel does.
Admin:
  Tested in OMAP3 ROM


Version 0.03. Tagged as 'VFPSupport-0_03'

Detail:
  s/Module, hdr/VFPSupport - VFPSupport_Create_LazyActivate & VFPSupport_Create_Activate now renamed to ..._CreateContext_... like they were meant to have been in my last checkin
Admin:
  Tested on rev A2 BB-xM


Version 0.02. Not tagged

Detail:
  s/Module, hdr/VFPSupport - New/changed features:
  - Contexts can now be flagged as being in application space if they're created with the VFPSupport_Context_AppSpace flag
  - VFPSupport_ChangeContext accepts a VFPSupport_ChangeContext_AppSpace flag, which will force the context change to occur in a nonlazy manner if the currently active context is in application space
  - VFPSupport_CreateContext accepts a VFPSupport_CreateContext_LazyActivate flag, to indicate that after creation the context should be activated lazily (unlike VFSupport_CreateContext_Activate)
  - VFPSupport_Context_Activate renamed to VFPSupport_CreateContext_Activate for clarity
  - VFPSupport_CheckContext now ignores the Activate/LazyActivate flags, so the same flag word can be passed to Check & Create
  - "Context ID" simplified to just "Context pointer", as an indiciation of the fact that I now have no plans to make VFPSupport keep a master list of extant contexts
    - This makes it legal for programs to move/copy/delete contexts as long as they've made sure that the ExamineContext doesn't indicate that any part of the context is active
  - VFPSupport_ExamineContext now returns the context size in R4 instead of the context ID
  Test/test1,ffb - Updated to work with new API
Admin:
  Tested on rev A2 BB-xM.
  VFPSupport_ExamineContext change is backwards-incompatible!


Version 0.02. Tagged as 'VFPSupport-0_02'

Detail:
  Initial VFP/NEON support code for RISC OS. Features:
  * Basic detection code for determining VFP version. Should work OK on all architecture versions.
  * Provides code to perform VFP/NEON context switches
  * Context switches can be lazy or immediate
  * Context register dumps can be stored in user-allocated memory or memory allocated by VFPSupport
  * Basic APIs for examining contexts and reporting available hardware features
  * "FastAPI" that privileged code can use for context switching in order to avoid SWI call overheads
  Missing/unfinished features:
  * No VFP exception handler is present, so the module will refuse to run on anything but a VFPv3 system
  * Lazy context switching is simplistic, opting to activate the new context upon the first undefined instruction abort instead of checking to see if it was a VFP instruction that triggered the abort
  * No interface to allow debuggers to easily get their hands on a register dump following a crash
  * No code to automatically clean up contexts left behind by dying programs
  * Can't be used by FIQ handlers, or from code called by an FIQ handler
  * Currently uses an error base of 0!
  Other notes:
  * Doc/vfpversions contains some random notes about the different VFP/NEON versions
  * Test/test1,ffb is a BASIC program that tests most of the module's functionality
Admin:
  Tested on Iyonix & Beagleboard. Iyonix version exits correctly, while Beagleboard version passes all tests in the test1 script.
  Need to sort out proper error numbers, and translate the error messages.


Version 0.01. Not tagged