Compile-time evaluation will always be a performance hit for the compiler unfortunately, even for the simplest of algorithms, which is why I feel that only those functions that the programmer says are pure should be evaluated. If anyone has ideas for performance enhancements though, feel free to contribute to the last section in the Wiki topic. Due to cross compilation though, assembly language can only be used in internal functions available to the programmer (e.g. the Frac function). The compiler itself must be pure Pascal.
I primarily work with win64, as that's my development platform, and the plan is to have the emulator hopefully use hardware floating point where available, but you are right in that cross-compilation will be quite the monster to debug! float128 does sound like a good solution overall. I'm not sure where to begin with that though, or even what to call it for Pascal, since "float128" is distinctly C- like! It could be something to put on my list of possible research projects! Gareth aka. Kit On Wed 11/07/18 12:12 , Max Nazhalov via fpc-devel fpc-devel@lists.freepascal.org sent: > > > Tue, 10 Jul 2018 03:36:01 +1000 Thorsten Engler wrote: > > > > >> -----Original Message----- > > >> From: fpc-devel On Behalf Of > >> Max Nazhalov via fpc-devel > > >> Sent: Tuesday, 10 July 2018 02:25 > > >> > > >> Just one question: doesn't all this new > stuff introduce another kind > >> of mess during cross-compiling? > > >> > > >> E.g. some complex nested const.expr. > "sin(cos(0.12345))" evaluated by > >> the compiler on x64 (double precision) is > not the same as if it would > >> be evaluated by the compiled program itself > running on some x32 > >> (float80), or some future float128 alikes.. > > > > > How would that be any different from floating > point consts > > currently that are defined with an expression > involving calculations? > > > Intermediate results may fall out of the compiler range capabilities, > > or introduce lost of precision in generated constant (e.g. Win64->Win32 > > cross-compiler is able to do only double-precision calculations, however > > the resulting program is fully float80- capable). > > (Hopefully compiling will just fail with over/underflow, but I cannot > > check this right now). > > > > In any case, I see no other but softfloat solution, as Florian already > > mention, and this would be a big performance impact, I suspect.. :( > > > > -- > > Best regards, > > Max stein_no > s...@mail.ru > > > __________________________________________ _____ > > fpc-devel maillist - fpc- de...@lists.freepascal.org > http://lists.freepascal.org/cgi- bin/mailman/listinfo/fpc-devel > > > > _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
