On Wed, 25 Nov 2020, Thomas Koenig wrote:
> > xbig = 26.543, xhuge = 6.71e+7, xmax = 2.53e+307;
>
> The Fortran intrinsis like HUGE, EPSILON, SELECTED_REAL_KIND etc
> would have to be handled correctly, both for simplification in
> the front end and in the library.
>
> Does the program
>
> print *,HUGE(1.0)
> print *,EPSILON(1.0)
> end
>
> print correct values?
Well, it does not link, for the somewhat unsurprising reason of a missing
libgfortran runtime. I have modified the program with whatever little
Fortran skills I gained a while ago to get something that can be parseable
for a human being in the assembly form:
real(8) :: h = HUGE(1.0)
real(8) :: e = EPSILON(1.0)
print *,h
print *,e
end
This yields the following data produced for the real literals referred:
.align 2
.type h.2, @object
.size h.2, 8
h.2:
.long -32769
.long 0
.align 2
.type e.1, @object
.size e.1, 8
e.1:
.long 13568
.long 0
which made me realise the NetBSD target defaults to the D-floating format
for some reason, which is significantly different in the range supported
from IEEE 754 double; specifically it has 1 sign bit, 8 exponent bits
(like IEEE 754 single) and 55 trailing significand bits.
So I am going to give up on giving this format any support, sorry (for
the VAX/Linux port I chose to use the G-floating format, which at least
gives some hope for interchangeability, even though I realise in some uses
the extra mantissa bits D-floating provides are useful).
In any case the output above does not appear exactly right to me as I
would expect:
h.2:
.long -32769
.long -1
(`e' seems right to me).
Maciej
