| sorear | IMO very little x86-64 code actually uses f80, I suggest doing actual measurements to see if a software solution is fast enough | 00:03 |
|---|---|---|
| sorear | also 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. unnormals | 00:03 |
| sorear | (*not* denormals - x87 long double has an entire extra non-IEEE value category) | 00:04 |
| programmerjake[m | yeah, 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 correct | 00:06 |
| programmerjake[m | and f80 is used by tons of x86-32 code, which we would want to support | 00:08 |
| sorear | what part of "see if a software solution is fast enough" implies that you won't be able to run x86-32 code | 00:10 |
| programmerjake[m | unnormals 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 type | 00:10 |
| programmerjake[m | x86-32 (or at least older ABIs) use x87 for all FP code, so it would need to be fast | 00:11 |
| programmerjake[m | search for deoptimization in https://ponyfoo.com/articles/an-introduction-to-speculative-optimization-in-v8 | 00:12 |
| programmerjake[m | basically, it checks that the types/values match the common case and branches to the slower interpreter if it needs to handle the uncommon cases | 00:14 |
| sorear | i am aware of what deopt is tyvm | 00:16 |
| programmerjake[m | sorear: 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 faster | 00:17 |
| sorear | yes. i'm encouraging you to be quantitative | 00:18 |
| programmerjake[m | and f80 is common enough in 32-bit code that we'd be foolish to rely on softfloat | 00:18 |
| sorear | if you try to implement 100% of everything in hardware, you will either never release or it will be unusably buggy | 00:18 |
| sorear | a lot of 32 bit code doesn't use floats at all | 00:19 |
| programmerjake[m | not really, x86 user-mode *can* be implemented without bugs in a decently small amount of time (few years) | 00:20 |
| programmerjake[m | true, 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 compilers | 00:22 |
| programmerjake[m | by without bugs, i meant without any showstopper bugs | 00:22 |
| sorear | you need a clear vision of who's using your core, why, and what benchmarks to optimize for | 00:23 |
| programmerjake[m | there are ways to mathematically prove that our fp implementation is 100% correct | 00:23 |
| programmerjake[m | general x86 code, because they want to use x86 apps on a libre core, and optimize for SPECint/SPECfp since that's more representative | 00:25 |
| programmerjake[m | also, most the point of supporting x86 at all is for running those programs that you can't/won't recompile. | 00:28 |
| programmerjake[m | so, we need to support x87 well since legacy code uses x87 for basically all fp | 00:29 |
| lkcl | programmerjake[m: all starting to sound scary and time-sinking :) | 01:54 |
| lkcl | sorear: appreciated the advice about targetting. one of the primary markets is to create a SoC for netbooks, chromebooks etc. | 02:02 |
| lkcl | problem is, getting e.g. android up and running on OpenPOWER? yyeah. | 02:02 |
| lkcl | if however we can be even remotely ARM/x86 compatible that buys us some time | 02:03 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!