Bug 145 - reference FP emulation using algebraic numbers
Summary: reference FP emulation using algebraic numbers
Status: RESOLVED FIXED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Formal Verification (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- enhancement
Assignee: Jacob Lifshay
URL: https://salsa.debian.org/Kazan-team/s...
Depends on: 146
Blocks: 122
  Show dependency treegraph
 
Reported: 2019-10-15 01:56 BST by Jacob Lifshay
Modified: 2020-03-15 18:02 GMT (History)
3 users (show)

See Also:
NLnet milestone: NLnet.2019.02
total budget (EUR) for completion of task and all subtasks: 750
budget (EUR) for this task, excluding subtasks' budget: 750
parent task for budget allocation: 122
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jacob Lifshay 2019-10-15 01:56:15 BST

    
Comment 1 Jacob Lifshay 2019-10-15 02:04:35 BST
Using https://crates.io/crates/algebraics as the algebraic numbers implementation
Comment 2 Jacob Lifshay 2019-11-03 06:18:08 GMT
Implemented all of add, sub, mul, div, and mul_add.
All tests pass!
Comment 3 Luke Kenneth Casson Leighton 2019-11-03 06:49:48 GMT
(In reply to Jacob Lifshay from comment #2)
> Implemented all of add, sub, mul, div, and mul_add.
> All tests pass!

Good grief :) is it looking like sfpy,
worth quickly seeing if it runs as a
replacement, or are you comparing it
*to* sfpy in the unit tests?
Comment 4 Jacob Lifshay 2019-11-03 07:10:40 GMT
(In reply to Luke Kenneth Casson Leighton from comment #3)
> (In reply to Jacob Lifshay from comment #2)
> > Implemented all of add, sub, mul, div, and mul_add.
> > All tests pass!
> 
> Good grief :) is it looking like sfpy,
> worth quickly seeing if it runs as a
> replacement, or are you comparing it
> *to* sfpy in the unit tests?

I haven't started building the python bindings yet, so it won't currently work with python.
I'm testing it against softfloat.
I put all the tests in the source code by using bash scripts to generate the tests, since I want it to be testable without needing to build and properly configure softfloat.
I am probably going to change the tests out for something else (maybe array literals or data files) since they're currently 120kloc of function calls, which takes quite a while to compile (5-10min).
Comment 5 Jacob Lifshay 2019-11-04 06:34:27 GMT
(In reply to Jacob Lifshay from comment #4)
> I'm testing it against softfloat.
> I put all the tests in the source code by using bash scripts to generate the
> tests, since I want it to be testable without needing to build and properly
> configure softfloat.
> I am probably going to change the tests out for something else (maybe array
> literals or data files) since they're currently 120kloc of function calls,
> which takes quite a while to compile (5-10min).

I changed the tests to use external data files instead of giant source files, it improves the compile time quite a bit (2.5s to recompile instead of 5min).
Comment 6 Jacob Lifshay 2019-11-07 11:16:59 GMT
(In reply to Jacob Lifshay from comment #2)
> Implemented all of add, sub, mul, div, and mul_add.
> All tests pass!

Implemented all of ieee754_remainder, next_up, next_down, round_to_integral[_exact], scale_b, log_b, and sqrt.
All tests pass!

I'm mostly going down the list of IEEE 754 operations in order, so will probably next be implementing conversions from/to integers, sign manipulation, and comparison.

Once those are implemented, simple-soft-float will support all the required IEEE 754 operations except for string conversions and stuff that doesn't actually process floats (such as status flag manipulation, since that can just be done by the user by modifying status_flags directly).
Comment 7 Jacob Lifshay 2019-11-08 10:11:12 GMT
(In reply to Jacob Lifshay from comment #6)
> I'm mostly going down the list of IEEE 754 operations in order, so will
> probably next be implementing conversions from/to integers, sign
> manipulation, and comparison.

All the above are now implemented, as well as float to float conversions which I forgot to list.

All tests pass!

> Once those are implemented, simple-soft-float will support all the required
> IEEE 754 operations except for string conversions and stuff that doesn't
> actually process floats (such as status flag manipulation, since that can
> just be done by the user by modifying status_flags directly).

I've now implemented all core IEEE 754 operations except for above exceptions (assuming I didn't forget something).

I still need to finish implementing properly calculating NaN payloads -- since that's not needed on RISC-V since it always produces canonical NaNs instead of propagating payloads, the implementation should produce bit-accurate results for all input cases for RISC-V.

For other architectures, it calculates bit-accurate results for all cases that don't produce NaNs, when it produces a NaN, it produces the correct kind (signaling/quiet) of NaN but the NaN payload is not always correct yet.

Working on rsqrt next, then on the python bindings.
Comment 8 Jacob Lifshay 2019-11-08 11:18:59 GMT
(In reply to Jacob Lifshay from comment #7)
> Working on rsqrt next, then on the python bindings.

implemented rsqrt.

Will implement the python bindings another day -- need sleep.
Comment 9 Jacob Lifshay 2019-12-13 03:34:15 GMT
I finished implementing and documenting simple-soft-float, will publish to crates.io once PyO3 releases the next version, since I am depending on features from git master.
Comment 10 Jacob Lifshay 2019-12-13 03:42:22 GMT
(In reply to Jacob Lifshay from comment #9)
> I finished implementing and documenting simple-soft-float, will publish to
> crates.io once PyO3 releases the next version, since I am depending on
> features from git master.

See https://github.com/PyO3/pyo3/issues/689
Comment 11 Jacob Lifshay 2019-12-16 02:36:33 GMT
(In reply to Jacob Lifshay from comment #10)
> (In reply to Jacob Lifshay from comment #9)
> > I finished implementing and documenting simple-soft-float, will publish to
> > crates.io once PyO3 releases the next version, since I am depending on
> > features from git master.
> 
> See https://github.com/PyO3/pyo3/issues/689

Published to crates.io:
https://crates.io/crates/simple-soft-float

Docs:
https://docs.rs/simple-soft-float/0.1.0/