Bug 258 - Finish implementing support for Power in simple-soft-float
Summary: Finish implementing support for Power in simple-soft-float
Status: IN_PROGRESS
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: All All
: --- enhancement
Assignee: Jacob Lifshay
URL:
Depends on:
Blocks: 241
  Show dependency treegraph
 
Reported: 2020-03-15 18:02 GMT by Jacob Lifshay
Modified: 2020-03-23 10:00 GMT (History)
2 users (show)

See Also:
NLnet milestone: ---
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation:
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 2020-03-15 18:02:13 GMT
https://salsa.debian.org/Kazan-team/simple-soft-float

need to finish implementing NaN payload propagation
need to implement additional non-standard FPU exceptions
Comment 1 Jacob Lifshay 2020-03-18 04:37:51 GMT
Just finished some refactoring in preparation for supporting Power's weird FP status flags.
Comment 2 Jacob Lifshay 2020-03-23 01:24:30 GMT
Finished updating for latest version of PyO3 and algebraics
Comment 3 Jacob Lifshay 2020-03-23 09:22:47 GMT
So you know, simple-soft-float's StatusFlags is getting lots of new flags and some of the existing flags will become aliases for groups of flags, where writing will write to all flags in the group and reading will get the logical OR of all flags in the group.

Some of the new flags won't be persistent -- they will be overwritten by every operation -- unlike the standard flags which all stay at 1 (unless explicitly cleared).
Comment 4 Luke Kenneth Casson Leighton 2020-03-23 10:00:19 GMT
(In reply to Jacob Lifshay from comment #3)
> So you know, simple-soft-float's StatusFlags is getting lots of new flags
> and some of the existing flags will become aliases for groups of flags,
> where writing will write to all flags in the group and reading will get the
> logical OR of all flags in the group.
> 
> Some of the new flags won't be persistent -- they will be overwritten by
> every operation -- unlike the standard flags which all stay at 1 (unless
> explicitly cleared).

ok appreciated.  the next step will be writing as close a drop-in replacement
for sfpy as we can get.  once sfpy is replaced as a dependency we can add new flags etc.  if those are in one place (a test helper routine / class) that minimises disruption and makes it easy to add features to ssf.