Login
You're viewing the y.diskcat.com public feed.
  • gloriouscowgloriouscow@oldbytes.space
    Nov 11, 2026, 11:27 PM

    I'm seeking a collaborator with extensive knowledge of IEEE-754 floating point math to help me devise an Intel FPU test suite for emulator authors.

    My previous test suites for x86 CPUs including the 8088, 8086, V20, 286 and 386 have been used by dozens of emulator authors to date. You would be participating in producing an invaluable technical resource that will help preserve the accuracy of emulation for decades to come.

    It would be nice if you used Discord for ease of collaboration, but you're averse to that we can work around it.

    Give me a private mention if interested.

    Boosts for visibility appreciated.

    #retrocomputing #vintagecomputing #reverseengineering #emulation

    💬 8🔄 2⭐ 0

Replies

  • 💬 1🔄 0⭐ 0
  • gloriouscowgloriouscow@oldbytes.space
    Nov 11, 2026, 11:33 PM

    @cr1901 @steve

    I realize that softFPU emulation is fairly mature, but what I'd like to do is produce tests against silicon across three generations (8087, 287 and 387) so we capture any hardware differences and edge cases. Also operational quirks in addition to arithmetic results.

    These tests would also capture all bus cycles, so people can study how the FPU handshaking worked across generations.

    I should probably track down that test suite and see if i can translate it directly to SSTs

    💬 1🔄 0⭐ 1
  • mirthmirth@mastodon.sdf.org
    Nov 12, 2026, 1:37 AM

    @gloriouscow @cr1901 @steve I realize it's out of scope for this project but if someone did structurally the same thing but for 68881 and descendants I would also be excited to see that exist (I do not have the expertise myself).

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Kavikavi@social.rachelnotes.uk
    Nov 12, 2026, 5:33 AM

    @gloriouscow Any x87 suite runs into the same trap first: the FPU computes in 80-bit extended precision and rounds again on every store, so tests checked against a 64-bit reference computed elsewhere will throw false failures on double-rounding cases. Worth deciding early which silicon is the oracle too — the 287 and 387 don't return identical ulps on the same transcendental inputs, and emulator authors will diverge depending on which one they treat as canonical.

    💬 0🔄 0⭐ 0
  • 💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • Aurorarawrafox@ruby.social
    Nov 12, 2026, 3:07 PM

    @gloriouscow Are we talking like the analysis of IEEE 754 from a mathematical perspective or? I have done quite a bit of that ages ago, but I am not sure exactly what you are asking for?

    It also feels like you might be trying to validate things like bus cycles for the coprocessors and stuff?

    💬 0🔄 0⭐ 0
  • Alastair Reidadreid@mastodon.social
    Nov 12, 2026, 9:06 PM

    @gloriouscow how feasible would it be to formally verify different fp implementations against each other? And then resolve differences by testing against hardware? (May not be feasible for 64 bit divide…)

    💬 0🔄 0⭐ 0
  • eddybeddyb@mastodon.social
    Nov 12, 2026, 9:23 PM

    @gloriouscow I ported github.com/rust-lang/rustc_apf from C++ and learned a lot in the process, but I never found a good test suite I was happy with - for certain things I ended up with fuzzing and even exhaustive search (not feasible for f32 and bigger), and did find some bugs - sadly I couldn't spend as much time on it as I wished

    on the upside, it does have an impl of the x87 80-bit format so feel free to test that and report issues to upstream LLVM because they likely have the same bugs lolsob

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0