I don't really see any problem here. Fortran has 128-bit floats and they
appear to be widely supported, although apparently GCC did a bad job with
them in the past. As far as I know, no x86 or ARM platform does 128-bit
operations in hardware, so there are "good" software solutions already
(e.g. libquadmath). I say "good" because float128 in software is ~50x
slower than float64 in hardware, although I suspect that a much better
software implementation could reduce that a bit, particularly if it were
allowed to ignore FP exception handling.
Boost::Multiprecision provides a non-GPL implementation of arbitrary
precision floating-point, although it may be slower than the GPL back-end
(GMP/MPFR). Thus, there's no need to worry about real256 - I've already
written code that uses real1024 and higher (pointlessly - the algorithm in
question is known to be pathologically divergent, but I wanted to see it
firsthand).
As for 128-bit integers, those are much easier to implement efficiently in
software (e.g. https://en.wikipedia.org/wiki/Intel_ADX).
Jeff
On Mon, Nov 20, 2017 at 12:08 AM, Damian McGuckin <[email protected]>
wrote:
>
> Stick these in the too-hard-for-now basket if you like.
>
> On Sun, 19 Nov 2017, Michael Ferguson wrote:
>
> ... because there are integer types for every real type bit width (at
>> least at the moment).
>>
>
> On that note, if there becomes a need to support,
>
> real(16)
>
> bases are covered because there are integral types of size 16 bits.
> With 512 bit vector units becoming more common, 32 of those suckers
> crunching at a time is very attractive if somewhat needy of accuracy
> analysis.
>
> But what of
>
> real(128)
>
> SPARC does this in software, albiet at the assembler level. Even allowing
> for Fujitsu's move to ARM, the SPARC architecture will persist. The old
> PA-RISC had hardware support, and so does the new IBM POWER9. But should
> there be support for real(128), does that also mean support for integral
> types of that same size? Just curious if there is some policy on this.
>
> That then also raises the question ...
>
> What is the type of a floating literal?
>
> In theory, it should be the size of the largest supported native type
> because otherwise you end up in a mess. But will that break any programs
> and end up with a different sort of mess. That said, even with 128bit
> reals, you could always kill them off with a compiler flag.
>
> And by the time we need to support
>
> real(256)
>
> we, or some younger generation probably, will be looking at Chapel's
> replacement!
>
> Regards - Damian
>
> Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW
> 2037
> <https://maps.google.com/?q=al,+277-279+Broadway,+Glebe+NSW+2037&entry=gmail&source=g>
> Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted
> here
> Views & opinions here are mine and not those of any past or present
> employer
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Chapel-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chapel-developers
>
--
Jeff Hammond
[email protected]
http://jeffhammond.github.io/
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
