https://salsa.debian.org/Kazan-team/simple-soft-float need to finish implementing NaN payload propagation need to implement additional non-standard FPU exceptions
Just finished some refactoring in preparation for supporting Power's weird FP status flags.
Finished updating for latest version of PyO3 and algebraics
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).
(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.
(In reply to Luke Kenneth Casson Leighton from comment #4) > (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. imho copying sfpy's api shouldn't be a goal, because it has a lot of issues having to do with requiring status flags and rounding modes and formats be global state. changing the test code to switch to ssf's api should be pretty easy and not too huge an amount of work afaict. I can also try to change ssf's python packaging to be based on setuptools rather than maturin -- iirc maturin has been a problem before. https://github.com/PyO3/setuptools-rust we will want to also add trig/exp/log functions to ssf.
i already made it clear that having rust as a critical dependency for unit tests was an experiment that has proven to be a very costly mistake. further investment of time and effort in ssf i simply won't approve the RFPs.
(In reply to Luke Kenneth Casson Leighton from comment #6) > i already made it clear that having rust as a critical dependency for unit > tests was an experiment that has proven to be a very costly mistake. The issue isn't rust itself, but maturin and using rust nightly features (used only in power-instruction-analyzer, not ssf or algebraics) -- because those weren't/aren't stable. I'm not aware of any issues caused by stable rust and I expect there won't be any. > further > investment of time and effort in ssf i simply won't approve the RFPs. You do realize it will take months of work to redo all of ssf in python --- I think discarding all of the work already done is a bad decision, it would be better to take a few-days/week and switch ssf to only using stable software.