jsstringh.inc -> use generic inc/sstrings.inc
* added a bunch of extra {$ifdef FPC_HAS_XXX} protections around
routines in inc/sstrings.inc and implemented those routines for
the JVM target in java/jsstrings.inc
* use the majority of the generic routine in sstrings.inc now also
for the JVM target! Only a few changes were needed:
o in a few places, calls to move() for copying shortstring->shortstring
or shortstring->chararray were replaced with calls to a new inline
helper that calls move() in the version in inc/sstrings.inc, and
JLSystem.arraycopt() in in the version in java/jsstrings.inc
o changed the currency argument to str() for the JVM target to constref
so its address can be taken (has to be typecasted to int64 without
changing the value), and similarly changed the temporary result
inside that routine to an array of 1 elements so the address can be
taken
o don't typecast the real value to a record type in str_real for the
JVM target, but work via an int64 instead to extract sign/mantissa/exp
o everything else compiled and worked as is!!
-> val, str, hexstr/octstr/binstr, delete, pos, insert, setstring and
comparetext now all work for shortstrings on the JVM target
git-svn-id: branches/jvmbackend@18836 -
properties/behaviour of the equivalent of Extended in C (i.e., to
"long double" on i386 and x86_64 platforms that support a 10 byte
long double, and to "double" elsewhere)
git-svn-id: trunk@14912 -
we support writing more digits than are defined (due to Delphi-
compatibility) and
a) correcting the precision of undefined digits makes no sense
b) as a result, this precision correction made some numbers that can be
represented exactly in single precision inexact
-- fixes mantis #14230
* no longer perform precision correction while determining the whole part
of numbers (usually did nothing anyway, and the rest is caught by the
final rounding)
git-svn-id: trunk@13574 -
delta for which 1.0 and 1.0+delta is different, rather than
some power-of-10 ballpark equivalent (fixes mantis #11308)
* print the same number of digits for doubles on systems
which support extended as on those which don't (i.e.,
one digit less on the former). This solves regressions after
the previous change and is Delphi-compatible.
* adapted tests for the previous change
git-svn-id: trunk@11025 -
all before the floating point on a cpu/fpu supporting maximally double
precision
* fixed test in tw1792a for double precision fpu's (they can print one
digit less for double precision numbers than 80 bit fpu's)
git-svn-id: trunk@1446 -
empty FPU registers for sysstem routines
* fixed bug in str_real when using ❌0
* str_real now doesn't call exp() anymore at runtime, so it should
require less free FPU registers now (and be slightly faster)