On Mon, Sep 23, 2013 at 8:00 AM, Roland Mainz <[email protected]> wrote: > On Thu, Sep 19, 2013 at 11:52 PM, Roland Mainz <[email protected]> > wrote: >> On Thu, Sep 19, 2013 at 6:41 AM, Roland Mainz <[email protected]> >> wrote: >>> On Thu, Sep 5, 2013 at 5:45 AM, Roland Mainz <[email protected]> >>> wrote: >>>> On Tue, Sep 3, 2013 at 2:46 PM, Glenn Fowler <[email protected]> wrote: >>>>> On Tue, 3 Sep 2013 02:50:31 +0200 Tina Harriott wrote: >>>>>> I'm currently looking into a complex mathematical simulation (fluid >>>>>> dynamics) and found references to NaN (Not A Number) with payloads. >>>>>> The Nan values are used to represent 'no data' in the datasets and the >>>>>> payloads are used for context information. The code has almost 2 >>>>>> million lines of code and removing the feature would be a major >>>>>> effort. > [snip] >>>> Attached (as "nan_payload_test1_20130904_001.c.txt") is some prototype >>>> code which shows now to handle NaN payloads... >>>> >>>> * Notes: >>>> - The code explicitly requires ISO C99 semantics >>>> - The code relies on |__int128_t| to handle |long double|. Originally >>>> I thought about handling the code using byte-by-byte masking... but it >>>> turned out that this creates a lot of mess and is endian-specific. The >>>> final code may have to resort to that to be portable but for now I >>>> use |__int128_t| to keep the code readable >>> >>> Uhm... any feedback/suggestions ? Adding Nan payload support seems to >>> be easy and doesn't come with a measureable performance penalty (since >>> we only do extra work *if* there is a payload, otherwise most code has >>> only "wrapper" overhead) ... if there are no objections I can try my >>> luck and add this to ksh93's arithmetic engine... >> >> Attached (as "astksh20130913_nanpayload_prototype001.diff.txt") is a >> _prototype_ for SuSE Linux 12.3/AMD64/32bit. 32bit will not work >> because it lacks the |__int128_t| type... see below... >> >> Example usage: >> -- snip -- >> $ ksh -c 'typeset -X x ; typeset -sX y ; float z ; (( >> x=ast_nan(0xbeef) )) ; ((y=x, z=y)); print -- $((z))' >> ast_nan(0xbeef) >> -- snip -- >> >> * Notes: >> - This is a prototype >> - The code was only tested on SuSE 12.3/AMD64/64bit with gcc4.7. >> - Surprisingly the performance overhead is barely measureable... >> basically we have a few extra |isnan()| calls or macros and that's it >> >> * ToDo: >> - Put the nan payload functions into their own source file >> - ABI issue: |nan("")| on some platforms only sets the highest hit in >> the payload instead of 0xFFFFFFFF (e.g. set all bits). How should we >> deal with it ? >> - Keep the nan payload function names (*binary@(32|64|80|128)* but add >> platform-specific macros to map them properly to SFDOUBLE, |long >> double|, |double| and |float|). The seperation is important to keep >> the #ifdef/#else/#endif hackery to a minimum and in one place >> - How should we deal with the usage of |__int128_t| ? It's only >> available on 64bit plaftorms with "clang" and newer "gcc" versions... >> but writing a "portable" version which does the operations on a >> byte/word/longword level makes the code depending on the endian-ness >> of the platform. Main issue here is testing... my SPARC machine is >> broken and I need some time to find money to fix it. > > Attached (as "astksh20130913_nanpayload_prototype005.diff.txt") is an > updated patch for ast-ksh.2013-09-13 and > "nan_payload_test1_20130922_001.c.txt" is standalone testcode for > debugging purposes... > > * Notes: > - This is a PROTOTYPE, the code is NOT ready yet. There is a lot of > "spaghetti" which is caused by the issue that the master sources for > the nan payload code live outside the AST tree for now... and there > are unresolved issues (see below) > > - The API is *layered* intentionally: First layer uses > |flt_binary@(32|64|80|128)|, 2nd layer uses ISO C names (|float|, > |double|, |long double|). This is done to seperate logical from > physical floating-point layouts... for example on some platforms |long > double| is the same type as |double| and some platforms only know > about |double| etc. etc. The other area of pain is x86/AMD64 with > 80bit |long double| vs. other platforms with 128bit |long double| > > - we need to write an iffe probe for the nan payload stuff, which > provides constants like number of bits, masks etc. and verifies that > the |float|, |double| and |long double| behave *EXACTLY* as defined in > IEEE754-2008. Some old implementations and software emulations take > shortcuts... or have "magic bits" which can cause trouble (i387's > IEEE754-1985-draft implementation with 80bit are such a special case). > We can only support payloads if we have a > fully-IEEE754-2008-conforming floating-point implementation (99% of > the modern platforms should fall into this category) > > - x86/AMD84 i387 80bit floats are fully functional and have extra code > to support it even if |__int128_t| is not supported > > - 128bit floats should be working now but require at least some testing > > - SPARC needs to be tested > > - We need per-floating-point datatype payload MIN/MAX constants > > - On some OSes like Solaris |nanf("")|/|nan("")|/|nanl("")| return a > payload of 0xFFFFFFFFFF... (=all payload bits set) while the |NAN| > contanst returns a nan value with all payload bits not set > > - AST |strtold()| on Solaris returns a value like > |nanf("")|/|nan("")|/|nanl("")|, which causes trouble. Replacing it > with |ast_nan()| causes sign reversal for (yet) unknown reasons (but > the same happens with |sin(inf)| ... which may be a hint that > something else is wrong in libast vs. nan sign handling) ... needs > more debugging... > > - Glenn and I need to agree on a naming scheme for NaN's with payloads > (gsf: We need to chat... issue is that not all naming schemes assume > that the payload is an unsigned int). Currently we use > "ast_nan(hexval)" in ksh93 and |strtof()|/|strtod()|/|strtold()|
Glenn: AFAIK I solved all technical issues (SPARC included) ... which leaves the naming scheme as the only open question. For now I would prefer to stick with |ast_nan(hexval)| and later provide an env variable to switch between naming schemes (but always accept |ast_nan(hexval)| as input). What do you think ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [email protected] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
