On 20 June 2012 15:30, deadalnix <deadalnix@gmail.com> wrote:

Le 20/06/2012 13:04, Manu a écrit :

Case 1 has no alternative to inline asm. I've thrown out some crazy
ideas to think about (but nobody seems to like them). I still think it
could be addressed though.

Case 2; I'm not convinced. These such long functions are the type I'm
generally interested in aswell, and have the most experience with. But
in my experience, they're almost always best written with intrinsics.
If they're small enough to be inlined, then you can't afford not to use
intrinsics. If they are truly big functions, then you begin to sacrifice
readability and maintain-ability, and certainly limit the number of
programmers that can maintain the code.
I rarely fail to produce identical code with intrinsics to that which I
would write with hand written asm. The flags are always the biggest
challenge, as discussed prior in this thread. I think that could be
addressed with better intrinsics.

I'm sorry, but what you say is rather ignorant.

Not that it is wrong, but it only cover YOUR usage of inline asm. You are talking about performances, but many other usages of assembly code are very useful, valid, and cannot be replaced by intrinsics. druntime is full of that, Walter and I presented you piece of code specifically. None of that could have been done without 100% asm functions.

I wasn't talking about performance strictly, I'm talking about pure functionality but with an intent not to inhibit optimisation. The high level language can't interact with registers directly, there's no mechanism to do so.

I offered trivial solutions. You never suggested any reason why they couldn't work. In your code, you only need push/pop intrinsics, and a register alias to produce identical code.

In Walters example, I offered a number of options (neat handling of JC being the key issue). I'm not saying what it SHOULD be, just some possibilities to think about/explore.

It is clear, however, that the compiler should get a better understanding of asm.