Saturday, 2021-01-02

sorearIMO very little x86-64 code actually uses f80, I suggest doing actual measurements to see if a software solution is fast enough00:03
sorearalso x87 f80 is weird in ways that go beyond the precision, I would be very skeptical that a f128-based implementation correctly handles e.g. unnormals00:03
sorear(*not* denormals - x87 long double has an entire extra non-IEEE value category)00:04
programmerjake[myeah, those would be handled by the 80 to 128-bit format conversion, but once you are doing arithmetic, all the unnormals are canonocalized, so emulation using f128 with round-to-f80 is correct00:06
programmerjake[mand f80 is used by tons of x86-32 code, which we would want to support00:08
sorearwhat part of "see if a software solution is fast enough" implies that you won't be able to run x86-32 code00:10
programmerjake[munnormals are rare, so can be handled by a deoptimization code path, similar to what happens in a javascript jit engine when the type wasn't the expected type00:10
programmerjake[mx86-32 (or at least older ABIs) use x87 for all FP code, so it would need to be fast00:11
programmerjake[msearch for deoptimization in
programmerjake[mbasically, it checks that the types/values match the common case and branches to the slower interpreter if it needs to handle the uncommon cases00:14
soreari am aware of what deopt is tyvm00:16
programmerjake[msorear: to answer your question, x86-32 can be emulated completely in software, it's just if we use hw ops that help out such as the f80 using f128 then we can run code faster00:17
sorearyes.  i'm encouraging you to be quantitative00:18
programmerjake[mand f80 is common enough in 32-bit code that we'd be foolish to rely on softfloat00:18
sorearif you try to implement 100% of everything in hardware, you will either never release or it will be unusably buggy00:18
soreara lot of 32 bit code doesn't use floats at all00:19
programmerjake[mnot really, x86 user-mode *can* be implemented without bugs in a decently small amount of time (few years)00:20
programmerjake[mtrue, a lot of code is integer-only, however there is also a lot of fp code that is important to support, and x86-32 happens to use x87 by default on older compilers00:22
programmerjake[mby without bugs, i meant without any showstopper bugs00:22
sorearyou need a clear vision of who's using your core, why, and what benchmarks to optimize for00:23
programmerjake[mthere are ways to mathematically prove that our fp implementation is 100% correct00:23
programmerjake[mgeneral x86 code, because they want to use x86 apps on a libre core, and optimize for SPECint/SPECfp since that's more representative00:25
programmerjake[malso, most the point of supporting x86 at all is for running those programs that you can't/won't recompile.00:28
programmerjake[mso, we need to support x87 well since legacy code uses x87 for basically all fp00:29
lkclprogrammerjake[m: all starting to sound scary and time-sinking :)01:54
lkclsorear: appreciated the advice about targetting.  one of the primary markets is to create a SoC for netbooks, chromebooks etc.02:02
lkclproblem is, getting e.g. android up and running on OpenPOWER?  yyeah.02:02
lkclif however we can be even remotely ARM/x86 compatible that buys us some time02:03

Generated by 2.17.1 by Marius Gedminas - find it at!