[racket-dev] long double for racket

Thanks!

I can work with this, though I'd like to start merging after the next
release branch on January 7.

Much of the cut-and-paste is difficult to abstract over, but I worry
about the amount of cut-and-paste in the JIT. The inlined arithmetic
functions, like scheme_generate_arith(), seem like too much to
duplicate. I'm willing to work on replacing cut-and-paste with
abstraction when I merge the changes, but anything you can do to reduce
the cut-and-paste would be appreciated.

I don't think we should use "l" in literal numbers to mean extfl,
because those literals are currently numbers. In other words, using "l"
for extfls would be a backward-incompatible change. I think we may need
to leave "l" as `double' and pick a different letter to indicate `long
double'.

At Sat, 22 Dec 2012 20:24:15 +0300, Michael Filonenko wrote:
> Hi all.
> 
> Modern FPUs can accelerate three types of floating-point arithmetic:
> single (32 bit), double (64 bit), long double (80 bit).
> 
> Currently Racket supports single and double precisions (flonum) and
> is able to JIT operations on them.
> 
> The task that is currently being done is adding long double type
> (hereinafter extflonum) arithmetic into racket, along with the
> corresponding vector type (hereinafter extflvector).
> 
> Here we go:
> 
> "Long double" requires modification of three racket parts:
>   - C core;
>   - JIT;
>   - Racket library.
> 
> Also, long double arithmetic requires setting "extended mode" flag on
> FPU, which forces the FPU to use 80-bit registers. The side effect on
> that flag is that the FPU gives slightly different (more accurate, but
> not IEEE-compliant) results for 64-bit operations. That is usually
> not a problem on machines who have SSE2 (introduced in Pentium 4 in
> 2001). In presense of SSE2, Racket performs 64-bit operations solely
> on 64-bit SSE2 registers (see MZ_USE_JIT_SSE and --mfpmath=sse), so the
> results are IEEE-compliant. 80-bit operations are done on FPU anyway
> as SSE2 can not do them. Therefore, by setting the "extended mode" on
> FPU, we introduce a subtle difference in ordinary flonums, but only on
> old machines that do not have SSE2. Also, on PowerPC machines
> the whole thing with extflonums will be canceled because they
> do not have 80-bit registers.
> 
> As for the C core: extended floating-point arithmetic is supported by
> gcc compiler on Linux, so build scripts for Linux does not require any
> change. Windows is another story. MSVC, commonly used to build Racket
> for Windows, does not support anything besides double precision. So we
> are forced to use gcc for Windows build, too. Cygwin's gcc is not a
> good option for us, because it denies the opportunity to use standard
> Windows GUI libraries etc. The other options are mingw (32-bit only)
> and mingw-w64 (both 32 and 64 bit). Many thanks to Matthew Flatt for
> his effort to port Racket to mingw.
> (Yet another option is Intel compiler, but I have not looked into it yet.)
> 
> Extflonums are tested on Linux x86_64, and Windows 7 x86 (VirtualBox).
> 
> I try to keep my modifications separate from other code. That requires
> much copy-paste, but hopefully makes my code easier to understand.
> 
> === Miscellaneous notes:
> 
> * Extflonum has text representation with "l" suffix
> (similar to "f" suffix for single flonums).
> 
> * Extflonum is not integrated into existing racket arithmetic (so, (+
> 123.0l0 513.0l0) is not possible). Extflonums have their own set of
> functions: extfl+, extfl-, extfl*, unsafe-extfl+, unsafe-extfl-, etc
> (similarly to flonums). The only Racket functions that were modified
> are reader, printer, and "equal?" (see below).
> 
> * The macro that guards the extflonum code is MZ_LONG_DOUBLE.
> The config definition is MZ_USE_LONG_DOUBLE, which enables MZ_LONG_DOUBLE.
> The configuration scripts were not modified.
> 
> * The macros MZ_LONG_DOUBLE_DISABLED and USE_EXTFLONUM_UNBOXING should be
> undefined, these are for unbox optimization, which will be in future.
> 
> Changes:
> 
> * C core was extended with following types and constants:
>   C structs:
>     Scheme_Long_Double (extflonum)
>     Scheme_Long_Double_Vector (extflvector)
>   constants:
>     scheme_long_double_type
>     scheme_extflvector_type
> 
> * Racket reader and printer were modified for reading extflonums (with
> suffix "l0"). Racket printer was modified for printing extflvectors
> (with "#extfl" prefix). Racket "equal?" function was modified to
> support extflonums (the purpose of doing that is that I needed
> rackunit to work with extflonums).
> 
> * xform compiler was extended for handling long double functions,
> such as cosl, sinl, floorl, etc.
> 
> * GNU lightning was extended with explicit jit fpu operations: fp-extfpu.h
> 
> * Racket collections was extended with racket/extflonum.rkt module,
> which exports both safe and unsafe functions for extflonums and
> extflvectors.
> 
> === Notes on JIT changes
> 
> JIT contains two optimization for flonums.
>   First is compiling racket code with inlined flonum functions.
>   Second is unboxing flonums to temporary storage when it
>   is possible, avoiding overhead with Scheme_Double object.
> 
> I have added only the first optimization for extflonum, by
> copy-pasting and modifying the original flonum
> code. Unboxing extflonums is not implemented yet.
> 
> long double is aligned on 12 bytes on x86 and on 16 bytes on x86_64.
> That is important for vector accessors generated by JIT for extflvectors.
> It is implemented by the following code
> 
>   #ifdef MZ_LONG_DOUBLE
>   # ifdef MZ_USE_JIT_X86_64
>   #  define JIT_LOG_LONG_DOUBLE_SIZE 4
>   #  define JIT_LONG_DOUBLE_SIZE (1 << JIT_LOG_LONG_DOUBLE_SIZE)
>   # else
>   #  define JIT_LOG_LONG_DOUBLE_SIZE not_implemented
>   #  define JIT_LONG_DOUBLE_SIZE 12
>   #endif
> 
> So that the jit code generation is:
> 
>   #ifdef MZ_USE_JIT_X86_64
>       jit_lshi_ul(JIT_V1, JIT_V1, JIT_LOG_LONG_DOUBLE_SIZE);
>   #else
>       jit_muli_ui(JIT_V1, JIT_V1, JIT_LONG_DOUBLE_SIZE);
>   #endif
> 
> JIT sometimes retains flonum into special buffer.
> I use it in the following not nice way:
> 
>   #ifdef MZ_LONG_DOUBLE
>   long double *scheme_mz_retain_long_double(mz_jit_state *jitter, long
> double ld)
>   {
>     /* TODO dirty hack to save long double into two cells of double */
>     void *p;
>     if (jitter->retain_start)
>       memcpy(&jitter->retain_double_start[jitter->retained_double], &ld,
>     sizeof(long double));
>     p = jitter->retain_double_start + jitter->retained_double;
>     jitter->retained_double++;
>     jitter->retained_double++;
>     return p;
>   }
>   #endif
> 
> I have modified the place where flonum is unboxed from Scheme_Double
> structure. I used jitter->unbox_extflonum flag for this.
> 
>   #ifdef MZ_LONG_DOUBLE
>     if (jitter->unbox_extflonum) {
>       fpr0 = JIT_FPU_FPR_0(jitter->unbox_depth);
>       jit_fpu_ldxi_ld_fppush(fpr0, target,
> &((Scheme_Long_Double*)0x0)->long_double_val);
>       jitter->unbox_depth++;
>     } else
>   #endif
>     {
>       fpr0 = JIT_FPR_0(jitter->unbox_depth);
>       jit_ldxi_d_fppush(fpr0, target, &((Scheme_Double *)0x0)->double_val);
>       jitter->unbox_depth++;
>     }
> 
> === Tests
> 
> There are tests for extflonums and extflvectors, done by
> copy-pasting the tests for flonums and flvectors:
> 
>   collects/racket/extflonum.rkt
>   collects/tests/racket/extfl-unsafe.rktl
> 
> The patch is attached, I think it can be applied to the development
> branch of Racket.
> 
> === Documentation
> 
> There is documentation in file
> collects/scribblings/reference/extflonums.scrbl,
> which contains mostly copypaste from flonum.scrbl with small
> adaptation for extflonum.