Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Define D_HardFloat version identifier #615

Merged
merged 1 commit into from

9 participants

@alexrp

No description provided.

@pszturmaj

Some architectures may support some float precisions while not supporting others. I think versions like D_Half, D_Float, D_Double and D_Quadruple would be more appropriate. They would mean that particular precision is hardware supported. Otherwise float types should be emulated by a library.

@alexrp

Point taken. However, is this the case for any of the archs listed on http://www.d-p-l.org/version.html?

@pszturmaj

They do not support half and quadruple precision natively but some newer CPU's include half <-> single conversion instructions. If this means hardware support - I don't know. I think quadruples will be supported in the future, because they are included in the new IEEE standard (already supported on some System/370 platforms).

@alexrp

I don't know whether there are plans to have such high-precision floating point types in the language. Walter?

@WalterBright

Are there really any x86 systems that don't support floating point instructions? The original impetus for -nofloat was to avoid linking in the fp formatting code. These days, the D generated executables are large enough that this seems irrelevant.

@alexrp

Honestly, I don't think so. Also, GDC ignores -nofloat. Maybe the option should be deprecated altogether?

I still think SoftFloat/HardFloat have uses, however.

@alexrp

Any input on this? Should I redo the patch to just add HardFloat/SoftFloat? (And add those to the docs)

@alexrp

Ping...?

@WalterBright

I am having a hard time seeing the point to this. Having the compiler support floating point is no longer the issue it was in the 1980's. Neither is there a need for a switch between emulated fp and native fp.

@alexrp

I agree that NoFloat is pointless. However, I do believe we need SoftFloat and HardFloat. Consider that, for example, a virtual machine needs to know whether it should emit actual FPU instructions or calls to a soft-float library of sorts.

@WalterBright

a virtual machine needs to know whether it should emit actual FPU instructions or calls to a soft-float library of sorts.

Why? This was true back in 1990, but that was a long time ago.

@alexrp

There are still ARM processors that have no FPU.

Yes, I know DMD doesn't do ARM code gen, but for portability purposes, I think DMD should define HardFloat, while other compilers that do support ARM can define HardFloat/SoftFloat as necessary.

@alexrp

I've changed the patch to just define HardFloat if -nofloat is not passed.

@WalterBright
Owner

I don't see the value in doing speculative features now. If and when such becomes necessary, we can revisit it.

@alexrp

I don't understand what you mean by speculative. Fact is, ARM CPUs without FPUs do exist, even in Android devices, today, and GDC can target those. So I think this is essential for portability.

@WalterBright
Owner

What I mean by speculative is nobody has asked for it, it has never been an issue. I've added such things before, and they often turn out to be the wrong decision because when faced with the actual problem, I find I solved the wrong problem.

@WalterBright
Owner

A classic is when Windows was developed for 16 bit computers. windows.h was full of macros and typedefs that were speculatively added to aid in the porting of 16 bit windows code to 32 bits. Unfortunately, since apparently nobody developing those macros had experience in 16<=>32 bit porting, the macros are mostly misguided and solved all the wrong issues.

So I'd like to wait until actually faced with an issue before speculating at what the right solution might be.

@TurkeyMan

I've already found myself needing to know whether I'm targeting soft/hard float when building for android on a couple of occasions (stumbled upon this while doing std.simd for ARM). I ignored the issue, and thus my code will crash on soft float devices. It would be nice to do something intelligent instead, these versions would give the information I need.

It's also perfectly likely that ARM devices without an FPU may choose to build without soft-float enabled, so I think NoFloat is valuable too, I see no reason not to define the standard name for it.

@alexrp

I don't think there's any issue to wait for. GDC has been able to target ARM for a long time, as has LDC. Nor do I think this is speculative. C has been on ARM for a long, long time, and soft/hard float detection has been essential for many applications (JIT compilers being one example). D is no exception. We need (emphasis: need) this information, and the compiler is the only facility that can provide it.

As I pointed out earlier, I can't do JIT compilation in D on ARM devices unless this information is present. I don't care how the information is there, it just has to be there. So if there's something about this patch that could be done better, or be done in a more future proof way, I'll gladly do the necessary changes to the patch.

@TurkeyMan also has a point. While systems without soft float of any kind are certainly very uncommon, they do exist (especially in embedded devices that don't need float at all).

@TurkeyMan

There are millions of cheaper android devices that don't have a hard float unit. Compiling with no float support is relatively common.
I'd still like to be able to identify all Hard, Soft and NoFloat distinctly. It looks like your patch only adds HardFloat, and Soft/NoFloat (indistinguishable) are implied by HardFloat not being present?

@alexrp

DMD only supports x86, where there is always hard float.

@TurkeyMan

Sure, but can you define NoFloat on the other side of the if though?
And GDC for ARM can fill in the missing SoftFloat its self.

@alexrp

The patch is outdated. I don't think the plan is to care about -nofloat in the long term, so if @WalterBright agrees with the strategy of adding HardFloat, SoftFloat, and NoFloat, DMD will just always define HardFloat.

@TurkeyMan

Oh okay.
Are you working with ARM personally? What toolchain? And does it have these versions available now?

@alexrp

@TurkeyMan Using GDC on ARM, and nope.

@WalterBright How about we make DMD define HardFloat and other targets can define SoftFloat, but the two are mutually exclusive? (So we just don't care about -nofloat.)

@andralex
Owner

Let's call it D_HardFloat, pull this in, and call it a day. Thanks!

@alexrp

Sure, but I'd still love to know what the plan is wrt -nofloat. Do we deprecate/remove it at some point?

@TurkeyMan

NoFloat is a valid configuration and will never go away. Do deprecate the concept in D would be to abandon many microcontrollers and smaller systems.

@alexrp

@TurkeyMan No, it merely places the requirement on implementations that they must at least provide a soft float implementation.

@TurkeyMan

@alexrp Well I think the point of no-float is to reject the float keyword, so users can't use float at all. This requires the user to implement fixed point solutions, which will perform better on the target hardware. Liberal use of floats in an emulated environment will lead to basically useless software. The compiler switch would be a catch to make sure you don't use floats by mistake (or perhaps a library you depend on).

@alexrp

If you want to make the float keyword practically illegal, that's an outright violation of language specification (same in C and C++). I don't see a reason that we should cater to something like that - even GCC and Clang don't have a -nofloat flag, but rather always expect soft float to be present at the very least.

And I think that's good enough. If you're worried about floating point in your code base, use your favorite grep-like tool to find it.

(It would, however, be interesting to investigate whether fixed point values are worth supporting in the language.)

@TurkeyMan

Yeah, I can buy that argument. Then -no-float is useless. What was it ever useful for exactly?
What's important then is to be able to depend on a standard version ALWAYS being present informing whether hardware float is available, and that seems to be agreed upon in this thread.

Fixed point values are already supported in every flavour imaginable ;) .. if you're talking about a type to perform automatic renormalisation after mul/div operations... it's probably a trivial job for a lib, perhaps a standard implementation could be offered.

@donc
Collaborator

IIRC, -no-float is to avoid linking in the floating-point printing code from the C standard library. I think it's a hang over from the 16 bit days. It saves ~2Kb from the executable.

@andralex
Owner

Great. So my understanding of the whole exchange is (a) nofloat is a goner, and (b) soft vs. hardware float is still possible. Then how about, again, defining D_HardFloat and leaving it there?

@TurkeyMan

Sounds fine, just so long as it is reliable. As a D user, I want to be able to depend on the float version to be telling the truth.

@jpf91
Fixed point values are already supported in every flavour imaginable ;)

Not really? There's fixed point hardware and iirc the gcc backend could support that, so it's not supported in every flavour. But I'm just nitpicking, this is probably not a problem for D.

Considering a version identifier for Soft/Hardfloat: I think that's a good idea. I guess hybrids like ARM's softfp would define D_HardFloat and probably a system dependent version (ARM_SoftFP), although I'm not sure if this information is ever useful.

@TurkeyMan

It's definitely useful information. The actual hardware support and the soft ABI distinction are both important details.

@alexrp

Actual hardware support is not easy to provide in the compiler. The compiler may be compiling for soft float even though the hardware actually has hard float. The compiler couldn't possibly know.

My idea of D_HardFloat and D_SoftFloat is that they should represent what the compiler is compiling for.

@jpf91

Hardware support of the executing system is always completely irrelevant. Think of cross compilers, etc. The target system is always the thing we're interested in. Target here means what the compiler was configured for, not what hardware is theoretically available.

The problem is that a ARM compiler could be configured for soft, softfp and hardfp. soft is emulated floating point, softfp is fpu assisted floating point with soft compatible ABI and hardfp is fpu floating point. Both softfp and hardfp would probably define D_HardFloat. Usually you don't care whether softfp or hardfp is used, but if you want to do low level stuff, knowing the actual ABI might be useful.

So what Manu was probably referring to when talking about "hardware support" was whether the target uses a fpu or emulation(D_HardFloat/D_SoftFloat). And the ABI distinction refers to softfp vs hardfp, which again, are both fpu floating point, but with different ABIs.

@alexrp

OK, I see. Would it be reasonable for targets like ARM softfp to define both D_HardFloat and D_SoftFloat or do we need more?

@jpf91

I think we could just define D_HardFloat to mean some kind of fpu involved, and D_SoftFloat as no fpu involved and make them exclusive. (In theory D_SoftFloat then isn't necessary).
So

  • soft -> D_SoftFloat
  • softfp -> D_HardFloat
  • hardfp -> D_HardFloat

As the softfp/hardfp thing is ARM specific I'd say we just define ARM_SoftFP and probably ARM_HardFP, but this can wait till we have a supported ARM compiler. This would allow us to do:

version(D_HardFloat)
{
    //FPU support / hardfp or softfp
    version(ARM_SoftFP)
    {
        //softfp
    }
    else version(ARM_HardFP))
    {
        //hardfp
    }
}
else
{
    //Emulated FP / soft
}
@TurkeyMan

Precisely what @jpf91 said.

In my brief tests, LDC2 for ARM seems to work. Also GDC for arm works, and I wrote std.simd code against it.

@alexrp

I just don't really like the idea of having such target-specific version identifiers if we can avoid it. The pattern of "hardware has FPU, but use soft float ABI" seems 'universal' enough to me in the sense that other architectures could easily do the same (and some likely do). So treating D_HardFloat/D_SoftFloat this way is kind of like how D compilers targeting x86-64 define both X86_64 and X86, while only defining X86 when targeting x86.

@jpf91

I'm not too sure about this. A quick look on the GCC floating point options tells us this:

MIPS has 5 different ABIs + a 32 and a 64 bit variant of the EABI. For some ABI gcc has a flag making "floating-point registers are 64 rather than 32 bits wide".
http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/MIPS-Options.html#MIPS-Options.

PPC has optional "decimal floating-point" support and some more FP flags:
http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/RS_002f6000-and-PowerPC-Options.html

SH floating point depends on which SH version is targeted (SH2-4). SH2a can use

  • no floating point
  • single precision only fp
  • double and precision fp, single precision default
  • double and precision fp, double precision default

Similar options exist for SH4. So I think there's not really much in common between those architectures (Although ARM seems to be the sanest of those)

@alexrp

Well, that's a horrible mess. I hate software sometimes.

I suppose we can just go with the original idea of D_HardFloat meaning that any sort of FPU is present.

The worst part of this is that all of these floating point modes are compiler-specific, so I'm not even sure how much we can really standardize them.

@ibuclaw
Collaborator

Sometimes the best answer is just to go with the flow.

@TurkeyMan

@alexrp Yes, I would think D_HardFloat means some form of hardware support exists, ie, one does not need to emulate at great cost of performance. ARM_SoftFP is a handy arm-specific detail, which is definitely very useful to know. I don't know of any other architectures that have done that before, so ARM_ seems appropriate.

@alexrp

Updated.

@braddr
Owner

Don't forget to also update the website docs when this is pulled.

@braddr braddr referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@alexrp

The website docs have already been updated, so let's get this merged?

@andralex andralex merged commit 68ab986 into D-Programming-Language:master

1 check was pending

Details default Pass: 8, Pending: 1
@andralex
Owner

merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Oct 21, 2012
  1. @alexrp

    Define D_HardFloat version identifier.

    alexrp authored alexrp committed
This page is out of date. Refresh to see the latest.
Showing with 2 additions and 0 deletions.
  1. +2 −0  src/mars.c
View
2  src/mars.c
@@ -1013,6 +1013,8 @@ int tryMain(int argc, char *argv[])
VersionCondition::addPredefinedGlobalIdent("D_NoBoundsChecks");
#endif
+ VersionCondition::addPredefinedGlobalIdent("D_HardFloat");
+
// Initialization
Type::init();
Id::initialize();
Something went wrong with that request. Please try again.