Problems compiling ieee.c

[PeterCoghlan]

Both softfloat.h and softfloat_types.h attempt to #include <stdint.h> without checking HAVE_STDINT_H

See hstdint.h for a more portable solution.

Typedefs for (u)int_fast8/16/32/64_t are still missing after that but that is easier to work around.

Those who have no need for or interest in floating point maths used to be able to define NO_IEEE_SUPPORT and avoid all sorts of grief but this doesn't work any more and now results in a compile time error from featchk.h: ``

error Floating point extension facility requires binary floating point

``

[srorso]

Hi Peter:

Thanks for posting this issue and a solution. Give me a day or so to address...

I will take a look at featchk.h as well.

Best Regards, Steve Orso

[srorso]

I am going to open an issue in the SoftFloat-3a repository for the stdint.h matter; the CMake for SoftFloat-3a takes pains to ensure a stdint.h is available for the SoftFloat-3a build and for the Hercules build, to the point of creating one if it does not exist.

The featchk.h issue will be tracked here.

[srorso]

See SoftFloat-3a issue #5 for the public header issue.

[srorso]

Looking at SA22-7832-10, z/Arch PoO, the Floating Point Extension Facility may be included on hardware that has Decimal Floating Point installed. If the Facility is present, it has impacts on the BFP and DFP instruction sets. So the edit in featchk.h at line 627 (#if defined(FEATURE_FLOATING_POINT_EXTENSION_FACILITY)) needs some work. And prior tests in featchk.h at line 584 need work as well. All line references are from featchk.h as of commit 0073054.

In other words, NO_IEEE_SUPPORT means turning off DFP, BFP, and any Facilities that impact DFP and/or BFP. Some further research is needed.

[srorso]

After some research....

Changing the Hercules build to suppress decimal floating point and the Floating Point Extensions facility results in a failure to build s37x the S/370 extensions module, which attempts to build binary floating point opcodes in s/370 mode even when NO_IEEE_SUPPORT is defined, (s37x.c was included in Hercules on 12 August 2011.

Ok, so what happens when I suppress build of the 370 extensions using NO_370_EXTENSIONS? dyncrypt.c fails to build because it, for reasons I poorly understand, attempts to build in archmode 370 and depends on 370 extensions being present to build. This seems like an issue to me.

The macro NO_IEEE_SUPPORT was added in June of 2001 as a replacement for OPTION_NO_IEEE_SUPPORT, added a few months earlier. The option suppresses inclusion of IEEE binary floating point support when building under Windows/Cygwin because Cygwin did not port the fenv.h header. At the time, Cygwin was the only build tool for Windows, Hercules used whatever binary floating point was available in the c runtime, and fenv.h was needed to enable IEEE traps, required by correct emulation of binary floating point instructions. Decimal Floating Point nor the Floating Point Extensions Facility existed at the time.

Since then, Cygwin was abandoned, SoftFloat became the tool used to implement IEEE binary floating point on all targets, and NO_IEEE_SUPPORT was removed from the default Windows build. And Decimal Floating Point and the Floating Point Extensions Facility were added. It is not clear when Cygwin stopped being used to build Hercules for Windows, but I suspect late 2005-early 2006.

So rather than try to get NO_IEEE_SUPPORT to work, I will address the underlying issue in SoftFloat-3a For Hercules, namely that if it does not find types it requires, it builds a non-standard types file (common enough elsewhere) using a standard name (maybe, as you suggest, not the best practice).

[PeterCoghlan]

Hi Steve,

Many thanks for looking into this for me.

I agree that NO_IEEE_SUPPORT has probably had it's day. I think all traces of it should be removed rather than having remnants of it lying around which might give someone the impression that it could be coaxed into doing something.

I am not sure whether I can get my compiler to find a non-standard include file whose name is enclosed in angle brackets rather than double quotation marks but I will look into it. If there is no other option, I will have to find a way to make it work.

As far as I recall when I looked into it, this is the only instance in Hercules where this issue arises. In similar cases, Hercules provides an include file with a different name to the standard include file. I can see how that would be a problem here though if you want to make use of files from outside of Hercules without having to make changes to them.

[srorso]

Hi Peter,

With your agreement, I would like to close this issue as "Won't fix" and continue efforts to address your issue in the SoftFloat-3a For Hercules repository.

Best Regards, Steve Orso