Recent

Author Topic: DateUtils.Inc* with double instead on Int64  (Read 4114 times)

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: DateUtils.Inc* with double instead on Int64
« Reply #30 on: June 08, 2022, 11:51:40 am »
Maybe. 64-bit,64-bit pairs or so.

That would fit the TDateTime format. Although it would make calculations that simply add or substract hours or seconds slower.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: DateUtils.Inc* with double instead on Int64
« Reply #31 on: June 08, 2022, 01:03:55 pm »
btw, I send records with tdatetime in it over TCP between FPC and Delphi apps......

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: DateUtils.Inc* with double instead on Int64
« Reply #32 on: June 08, 2022, 02:24:24 pm »
Double is the highest shared floating point number. But maybe if you implement soft float for 128-bt float, that can be used. (extended is not portable enough to really be a solution)

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

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...

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: DateUtils.Inc* with double instead on Int64
« Reply #33 on: June 08, 2022, 02:40:36 pm »
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...

I'm currently twiddling factors and primitive roots: my brain hurts enough already :-)

I don't know who they are, but there's some useful stuff at https://www.geeksforgeeks.org/

If https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Hardware_support is to be believed, there's very little that actually has hardware support for 128-bit IEEE maths. Which could be interpreted either as indicating that nobody's really bothered about that level of precision (notwithstanding my original question), or that software support is urgently needed.

In the latter case, surely it's a "Summer of Code" job for some bright undergrads?

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: DateUtils.Inc* with double instead on Int64
« Reply #34 on: June 09, 2022, 01:42:13 pm »
Double is the highest shared floating point number. But maybe if you implement soft float for 128-bt float, that can be used. (extended is not portable enough to really be a solution)

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

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...

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 :)

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: DateUtils.Inc* with double instead on Int64
« Reply #35 on: June 10, 2022, 09:19:44 am »
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 :)

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

  • Hero Member
  • *****
  • Posts: 6676
Re: DateUtils.Inc* with double instead on Int64
« Reply #36 on: June 10, 2022, 09:30:08 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.

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
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11382
  • FPC developer.
Re: DateUtils.Inc* with double instead on Int64
« Reply #37 on: June 10, 2022, 10:10:33 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?

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

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: DateUtils.Inc* with double instead on Int64
« Reply #38 on: June 10, 2022, 01:16:34 pm »
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.

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?

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

  • Sr. Member
  • ****
  • Posts: 325
Re: DateUtils.Inc* with double instead on Int64
« Reply #39 on: June 11, 2022, 12:16:34 pm »
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)

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

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...

"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

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: DateUtils.Inc* with double instead on Int64
« Reply #40 on: June 13, 2022, 03:36:01 pm »
"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?
* ...

We already have the core routines in rtl/inc/softfpu.pp (which is based on IEEE754; usable using the units sfpu128 and ufloat128) as such any implementation of the additional functions must work together with those. External libraries are a no-go, the license must be compatible to the RTL's (LGPL with static linking exception) and due to this being especially necessary for cross compilation a full Pascal implementation that works correctly in (16/)32/64-bit in both big and little endian is a necessity. As a first step exactness is more important than speed.

MathMan

  • Sr. Member
  • ****
  • Posts: 325
Re: DateUtils.Inc* with double instead on Int64
« Reply #41 on: June 14, 2022, 10:51:36 am »
"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?
* ...

We already have the core routines in rtl/inc/softfpu.pp (which is based on IEEE754; usable using the units sfpu128 and ufloat128) as such any implementation of the additional functions must work together with those. External libraries are a no-go, the license must be compatible to the RTL's (LGPL with static linking exception) and due to this being especially necessary for cross compilation a full Pascal implementation that works correctly in (16/)32/64-bit in both big and little endian is a necessity. As a first step exactness is more important than speed.

Thanks for the clarification PascalDragon. I'll take a look at rtl/inc/softfpu.pp, sfpu128 & ufloat128 to understand exactly what "core routines" are available and what will be required for implementation of elementary functons.

 

TinyPortal © 2005-2018