Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Define D_HardFloat version identifier #615

Merged
merged 1 commit into from over 1 year ago

9 participants

Alex Rønne Petersen Piotr Szturmaj Walter Bright Manu Evans Andrei Alexandrescu Don Clugston Johannes Pfau Iain Buclaw Brad Roberts
Alex Rønne Petersen

No description provided.

Piotr Szturmaj

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.

Alex Rønne Petersen

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

Piotr Szturmaj

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

Alex Rønne Petersen

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

Walter Bright
Owner

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.

Alex Rønne Petersen

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.

Alex Rønne Petersen

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

Alex Rønne Petersen

Ping...?

Walter Bright
Owner

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.

Alex Rønne Petersen

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.

Walter Bright
Owner

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.

Alex Rønne Petersen

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.

Alex Rønne Petersen
alexrp commented May 04, 2012

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

Walter Bright
Owner

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

Alex Rønne Petersen
alexrp commented May 04, 2012

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.

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

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

Manu Evans

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.

Alex Rønne Petersen
alexrp commented June 10, 2012

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

Manu Evans

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?

Alex Rønne Petersen
alexrp commented June 13, 2012

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

Manu Evans

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.

Alex Rønne Petersen
alexrp commented June 13, 2012

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.

Manu Evans

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

Alex Rønne Petersen

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

Andrei Alexandrescu
Owner

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

Alex Rønne Petersen

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

Manu Evans

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.

Alex Rønne Petersen

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

Manu Evans

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

Alex Rønne Petersen

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

Manu Evans

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.

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

Andrei Alexandrescu
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?

Manu Evans

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.

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

Manu Evans

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

Alex Rønne Petersen

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.

Johannes Pfau

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.

Alex Rønne Petersen

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?

Johannes Pfau

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
}
Manu Evans

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.

Alex Rønne Petersen

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.

Johannes Pfau

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)

Alex Rønne Petersen

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.

Iain Buclaw
Collaborator

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

Manu Evans

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

Alex Rønne Petersen

Updated.

Brad Roberts
Owner

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

Brad Roberts braddr referenced this pull request from a commit October 21, 2012
Commit has since been removed from the repository and is no longer available.
Alex Rønne Petersen

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

Andrei Alexandrescu andralex merged commit 68ab986 into from October 23, 2012
Andrei Alexandrescu andralex closed this October 23, 2012
Andrei Alexandrescu
Owner

merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Showing 1 unique commit by 2 authors.

Oct 20, 2012
Define D_HardFloat version identifier. 2e6664a
This page is out of date. Refresh to see the latest.

Showing 1 changed file with 2 additions and 0 deletions. Show diff stats Hide diff stats

  1. 2  src/mars.c
2  src/mars.c
@@ -1013,6 +1013,8 @@ int tryMain(int argc, char *argv[])
1013 1013
         VersionCondition::addPredefinedGlobalIdent("D_NoBoundsChecks");
1014 1014
 #endif
1015 1015
 
  1016
+    VersionCondition::addPredefinedGlobalIdent("D_HardFloat");
  1017
+
1016 1018
     // Initialization
1017 1019
     Type::init();
1018 1020
     Id::initialize();
Commit_comment_tip

Tip: You can add notes to lines in a file. Hover to the left of a line to make a note

Something went wrong with that request. Please try again.