On 20/06/12 00:55, Manu wrote:
On 20 June 2012 01:07, Walter Bright <newshou...@digitalmars.com <mailto:newshou...@digitalmars.com>> wrote:On 6/19/2012 1:58 PM, Manu wrote: I find a thorough suite of architecture intrinsics are usually the fastest and cleanest way to the best possible code, although 'naked' may be handy in this circumstance too... Do a grep for "naked" across the druntime library sources. For example, its use in druntime/src/rt/alloca.d, where it is very much needed, as alloca() is one of those "magic" functions. I never argued against naked... I agree it's mandatory. Do a grep for "asm" across the druntime library sources. Can you justify all of that with some other scheme? I think almost all the blocks I just browsed through could be easily written with nothing more than the register alias feature I suggested, and perhaps a couple of opcode intrinsics. And as a bonus, they would also be readable. I can imagine cases where the optimiser would have more freedom too. Thinking more about the implications of removing the inline asm, what would REALLY roxors, would be a keyword to insist a variable is represented by a register, and by extension, to associate it with a specific register: This was a failure in C. Really? This is the missing link between mandatory asm blocks, and being able to do it in high level code with intrinsics. The 'register' keyword was similarly fail as 'inline'.. __forceinline was not fail, it is actually mandatory. I'd argue that __forceregister would be similarly useful in C aswell, but the real power would come from being able to specify the particular register to alias. This would almost entirely eliminate the usefulness of an inline assembler. Better yet, this could use the 'new' attribute syntax, which most agree will support arguments: @register(rsp) int x; Some C compilers did have such pseudo-register abilities. It was a failure in practice. Really? I've never seen that. What about it was fail? I really don't understand preferring all these rather convoluted enhancements to avoid something simple and straightforward like the inline assembler. The use of IA in the D runtime library, for example, has been quite successful. I agree, IA is useful and has been successful, but it has drawbacks too. * IA ruins optimisation around the IA block * IA doesn't inline well. intrinsics allow much greater opportunity for efficient integration into the calling context * most IA functions are small, and prime candidates for inlining (see points 1 and 2)
You and I seem to be from different planets. I have almost never written as asm function which was suitable for inlining.
Take a look at std.internal.math.biguintX86.d I do not know how to write that code without inline asm.
