on the
[6600 scoreboard](https://libre-riscv.org/3d_gpu/architecture/6600scoreboard/)
page.
+* [Public-Inbox](http://bugs.libre-riscv.org/show_bug.cgi?id=181) was
+ installed successfully on the server, which is in the process of
+ moving to a [new domain name](http://bugs.libre-riscv.org/show_bug.cgi?id=182)
+ [Libre-SOC](http://libre-soc.org)
+* Build Servers have been set up with
+ [automated testing](http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-March/005364.html)
+ being established
Well dang, as you can see, suddenly it just went ballistic. There's
almost certainly things left off the list. For such a small team there's
# simple-soft-float Library and POWER FP emulation
-The [simple-soft-float](https://salsa.debian.org/Kazan-team/simple-soft-float) library is a floating-point library Jacob wrote with the intention
-of being a reference implementation of IEEE 754 for hardware testing purposes. It's
-specifically designed to be written to be easier to understand instead of having the
-code obscured in pursuit of speed:
+The
+[simple-soft-float](https://salsa.debian.org/Kazan-team/simple-soft-float)
+library is a floating-point library Jacob wrote with the intention
+of being a reference implementation of IEEE 754 for hardware testing
+purposes. It's specifically designed to be written to be easier to
+understand instead of having the code obscured in pursuit of speed:
* Being easier to understand helps prevent bugs where the code does not
match the IEEE spec.
-* It uses the [algebraics](https://salsa.debian.org/Kazan-team/algebraics) library that Jacob wrote since that allows using numbers
- that behave like exact real numbers, making reasoning about the code
- simpler.
+* It uses the [algebraics](https://salsa.debian.org/Kazan-team/algebraics)
+ library that Jacob wrote since that allows using numbers that behave
+ like exact real numbers, making reasoning about the code simpler.
* It is written in Rust rather than highly-macro-ified C, since that helps with
readability since operations aren't obscured, as well as safety, since Rust
proves at compile time that the code won't seg-fault unless you specifically
opt-out of those guarantees by using `unsafe`.
-It currently supports 16, 32, 64, 128-bit FP for RISC-V, along with having a
-`DynamicFloat` type which allows dynamically specifying all aspects of how a
-particular floating-point type behaves -- if one wanted, they could configure it as a
-2048-bit floating-point type.
-
-It also has Python bindings, thanks to the awesome [PyO3](https://pyo3.rs/) library for writing Python
-bindings in Rust.
-
-We decided to write simple-soft-float instead of extending the industry-standard
-[Berkeley softfloat](http://www.jhauser.us/arithmetic/SoftFloat.html) library because of a range of issues, including not supporting
-Power FP, requiring recompilation to switch which ISA is being emulated, not
-supporting all the required operations, architectural issues such as depending on
-global variables, etc. We are still testing simple-soft-float against Berkeley softfloat
-where we can, however, since Berkeley softfloat is widely used and highly likely to
-be correct.
-
-simple-soft-float is [gaining support for Power FP](http://bugs.libre-riscv.org/show_bug.cgi?id=258), which requires rewriting a lot of
-the status-flag handling code since Power supports a much larger set of
-floating-point status flags and exceptions than most other ISAs.
-
-Thanks to RaptorCS for giving us remote access to a Power9 system, since that
-makes it much easier verifying that the test cases are correct.
-
-API Docs for stable releases of both [simple-soft-float](https://docs.rs/simple-soft-float) and [algebraics](https://docs.rs/algebraics) are available
-on docs.rs.
+It currently supports 16, 32, 64, 128-bit FP for RISC-V, along with
+having a `DynamicFloat` type which allows dynamically specifying all
+aspects of how a particular floating-point type behaves -- if one wanted,
+they could configure it as a 2048-bit floating-point type.
+
+It also has Python bindings, thanks to the awesome
+[PyO3](https://pyo3.rs/) library for writing Python bindings in Rust.
+
+We decided to write simple-soft-float instead
+of extending the industry-standard [Berkeley
+softfloat](http://www.jhauser.us/arithmetic/SoftFloat.html) library
+because of a range of issues, including not supporting Power FP, requiring
+recompilation to switch which ISA is being emulated, not supporting
+all the required operations, architectural issues such as depending on
+global variables, etc. We are still testing simple-soft-float against
+Berkeley softfloat where we can, however, since Berkeley softfloat is
+widely used and highly likely to be correct.
+
+simple-soft-float is [gaining support for Power
+FP](http://bugs.libre-riscv.org/show_bug.cgi?id=258), which requires
+rewriting a lot of the status-flag handling code since Power supports a
+much larger set of floating-point status flags and exceptions than most
+other ISAs.
+
+Thanks to RaptorCS for giving us remote access to a Power9 system,
+since that makes it much easier verifying that the test cases are correct.
+
+API Docs for stable releases of both
+[simple-soft-float](https://docs.rs/simple-soft-float) and
+[algebraics](https://docs.rs/algebraics) are available on docs.rs.
+
+One of the really important things about these libraries: they're not
+specifically coded exclusively for Libre-SOC: like softfloat-3 itself
+(and also like the [IEEE754 FPU](https://git.libre-riscv.org/?p=ieee754fpu.git))
+they're intended for *general-purpose* use by other projects. These are
+exactly the kinds of side-benefits for the wider Libre community that
+sponsorship, from individuals, Foundations (such as NLNet) and Companies
+(such as Purism and Raptor Engineering) brings.
# OpenPOWER Conference calls
# Sponsorship by RaptorCS with a TALOS II Workstation
-TODO
+TODO http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-March/005291.html
# Epic Megagrants
TODO
+# Public-Inbox and Domain Migration
+
+TODO
+
+# Build Servers
+
+TODO
+
# Conclusion
TODO
+