path: root/src/math/x86_64/exp2l.s
AgeCommit message (Collapse)AuthorLines
2015-04-23fix regression in x86_64 math asm with old binutilsRich Felker-3/+3
the implicit-operand form of fucomip is rejected by binutils 2.19 and perhaps other versions still in use. writing both operands explicitly fixes the issue. there is no change to the resulting output. commit a732e80d33b4fd6f510f7cec4f5573ef5d89bc4e was the source of this regression.
2014-11-05math: fix x86_64 and x32 asm not to use sahf instructionSzabolcs Nagy-10/+3
Some early x86_64 cpus (released before 2006) did not support sahf/lahf instructions so they should be avoided (intel manual says they are only supported if CPUID.80000001H:ECX.LAHF-SAHF[bit 0] = 1). The workaround simplifies exp2l and expm1l because fucomip can be used instead of the fucomp;fnstsw;sahf sequence copied from i386. In fmodl and remainderl sahf is replaced by a simple bit test.
2013-09-05math: fix expm1l on x86_64 (avoid underflow for large negative x)Szabolcs Nagy-1/+11
copy the fix from i386: return -1 instead of exp2l(x)-1 when x <= -65
2013-09-05math: fix exp2l asm on x86 (raise underflow correctly)Szabolcs Nagy-35/+40
there were two problems: * omitted underflow on subnormal results: exp2l(-16383.5) was calculated as sqrt(2)*2^-16384, the last bits of sqrt(2) are zero so the down scaling does not underflow eventhough the result is in subnormal range * spurious underflow for subnormal inputs: exp2l(0x1p-16400) was evaluated as f2xm1(x)+1 and f2xm1 raised underflow (because inexact subnormal result) the first issue is fixed by raising underflow manually if x is in (-32768,-16382] and not integer (x-0x1p63+0x1p63 != x) the second issue is fixed by treating x in (-0x1p64,0x1p64) specially for these fixes the special case handling was completely rewritten
2012-12-16math: move x86_64 exp2l implementation to exp2l.s from expl.sSzabolcs Nagy-1/+75
2012-03-20x86_64 math asm, long double functions onlyRich Felker-0/+1
this has not been tested heavily, but it's known to at least assemble and run in basic usage cases. it's nearly identical to the corresponding i386 code, and thus expected to be just as correct or just as incorrect.