[sean]

[Don Clugston]

[larsivi]

[Don Clugston]

[sean]

[sean]

Okay, std.math.core, std.math.ieee, and std.math.special are done. I'll probably get a new Ares release out today with them included. I ran into some name collisions in std.math.core as it imports both std.c.math and std.math.ieee, both of which define fabs, frexp, and ldexp. The calls are now explicitly mapped to the std.math.ieee implementation, but it's worth noting that importing std.c.math and std.math.ieee into the same module will cause collisions. It may be worthwhile to eventually rename the functions in one of these two modules or to namespace everything inside structs, but that's a discussion unto itself.

[edit]

Intrinsics! It appears that the intrinsics are replaced based on their decorated name, so none of them work if declarted outside std/math.d. Worse yet, DMC doesn't contain a C implementation of these either because it assumes it can inline the code. So there are some very annoying gaps in functionality under DMD at the moment (sqrt, cos, etc). I'm not entirely sure how to address this, though simply writing the darn code may be the most expedient. I'm of half a mind to simply ask Walter to move all intrinsics into std.intrinsic, but what he's currently doing seems entirely reasonable so I haven't been able to convince myself to do so quite yet.

[lgoss007]

[sean]

Just a quick update on intrinsics. I tried faking out the code generator by pre-mangling function names:

[Don Clugston]

[Don Clugston]

They're utterly trivial. Should really be compiler intrinsics.
--------------------------------
/**
* Rounds x to the nearest int or long.
*
* This is generally the fastest method to convert a floating-point number
* to an integer. Note that the results from this function
* depend on the rounding mode, if the fractional part of x is exactly 0.5.
* If using the default rounding mode (ties round to even integers)
* rndint(4.5) == 4, rndint(5.5)==6.
*/
int rndint(real x)
{
version(D_InlineAsm_X86) {
int n;
asm {
fld x;
fistp n;
}
return n;
} else {
return std.c.math.lrintl(x);
}
}

/** ditto */
long rndlong(real x)
{
version (D_InlineAsm_X86) {
long n;
asm {
fld x;
fistp n;
}
return n;
} else {
return std.c.math.llrintl(x);
}
}
-----------------------------

[sean]

I'm not sure any special syntax should be supported for intrinsics, as they're really just a case where the compiler implementor said "you know, I can do better than the library writer here." ie. it seems a quality of implementation issue for the most part. std.intrinsic seems to be a slightly different case however as it contains functions that are intended to correspond to one machine instruction, and programmers may rely on them being extremely fast. But as a standard library is required to be arranged a certain way, that a compiler might be looking for a particular signature seems reasonable. It's only a problem here because we're trying to replace Phobos with something different.

I'll admit I don't entirely understand the point of built-in intrinsics for more general functions like sqrt, as I would think that a short function containing assember would be inlined to produce approximately the same result. Perhaps it's simply that the compiler doesn't inline assembler functions because the code may rely on the function's call stack, and expecting a library writer to write a naked assembler function is simply unreasonable?

As for the remaining missing functions, I may decompile short programs that call them (using Phobos) and extract the code into asm blocks as well. Hopefully this will produce a DMD compatible implementation for each without much hassle.

[Don Clugston]

[sean]

[sean]

Done and done. The intrinsics now have inline asm implementations and I've altered the rounding functions as described above.

[kris]