Forum > FPC development

DateUtils.Inc* with double instead on Int64

<< < (8/9) > >>

PascalDragon:

--- Quote from: SymbolicFrank on June 09, 2022, 01:42:13 pm ---There still isn't native support for BigInt either, so a general library for arbitrary precision fixed and floating-point would be awesome. I started both a few times and translated one halfway from Delphi, but it was too much work for what I needed it for. The last time I wrote a working floating-point library was before floating-pont hardware was common. So, long ago :)

--- End quote ---

Neither a BigInt library nor support for arbitrary precision fixed and floating point arithmetic is important for cross compilation. Support for 128-bit floating point however is.

MarkMLl:

--- Quote from: PascalDragon on June 10, 2022, 09:19:44 am ---Neither a BigInt library nor support for arbitrary precision fixed and floating point arithmetic is important for cross compilation. Support for 128-bit floating point however is.

--- End quote ---

I'd not presume to argue with that bit as a reality check: am I correct in believing that only the POWER architecture support this in hardware (possibly with RISCV in the future)? And however much I've favoured alternative architectures in the past, is that one really likely to remain viable?

MarkMLl

marcov:

--- Quote from: MarkMLl on June 10, 2022, 09:30:08 am ---I'd not presume to argue with that bit as a reality check: am I correct in believing that only the POWER architecture support this in hardware (possibly with RISCV in the future)? And however much I've favoured alternative architectures in the past, is that one really likely to remain viable?

--- End quote ---

The compiler now uses extended that is not crossplatform to do calculate to create double constants.

A generic 128-bit soft fpu would fix that crossplatform issue, regardless of hardware support.

PascalDragon:

--- Quote from: MarkMLl on June 10, 2022, 09:30:08 am ---
--- Quote from: PascalDragon on June 10, 2022, 09:19:44 am ---Neither a BigInt library nor support for arbitrary precision fixed and floating point arithmetic is important for cross compilation. Support for 128-bit floating point however is.

--- End quote ---

I'd not presume to argue with that bit as a reality check: am I correct in believing that only the POWER architecture support this in hardware (possibly with RISCV in the future)? And however much I've favoured alternative architectures in the past, is that one really likely to remain viable?
--- End quote ---

It's not about hardware support! It's about compiling from a system that does not support 80-bit floating point to a system that does. And instead of using 80-bit it's a logical step to simply use the next bigger size, namely 128-bit.

MathMan:

--- Quote from: PascalDragon on June 08, 2022, 02:24:24 pm ---
--- Quote from: MarkMLl on June 08, 2022, 10:34:41 am ---
--- Quote from: marcov on June 08, 2022, 10:27:46 am ---Double is the highest shared floating point number. But maybe if you implement soft float for 128-bit float, that can be used. (extended is not portable enough to really be a solution)

--- End quote ---

My previous point stands: nobody in their right mind gets involved with bit-twiddling floating points :-)
--- End quote ---

Well, we could definitely use such people, because for FPC we need software 128-bit FP support so that we can fully support cross compilation from platforms that don't support Extended (including x86_64-win64) to those that do. And while basic routines are already available functions like exp and ln as well as the trigonometry ones are missing...

--- End quote ---

"software 128-bit FP support" is a very generic term. Are the exact requirements noted down somewhere? Depending on these the task can vary from several man days to man years ...

* full implementation in FPC, or wrapper for an existing FP128 library?
* 32/64 bit and little-/big-endian architecture support?
* based on IEEE754?
* exposure of an internal, more efficient format too?
* designed to allow replacement of some kernel functions by asm routines?
* how much trade is allowed between exactness and speed?
* ...

Don't get me wrong - I'm not committing to anything here (yet)! I'm just a hobby programmer who's solely developing things for his own amusement. But I recently started explorations into FP128 based on IEEE754-2008 and this may coincide with my own ambitions.

Beside that, mmartin has recently announced an FP128 library, following the IEEE754 - however also his version is only covering basic functionality and does not include the desired elementary functions like ln, exp, etc.

Cheers,
MathMan

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version