On 20 June 2012 15:30, deadalnix <deadal...@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. > Such a better understanding of asm is easier implemented via intrinsics, that's the basis of my suggestion; extend the high level language such that it is capable of that understanding within conventional expressions. Intrinsics are already mechanically present in the language, adding more as they are needed is no problem. The only missing component I can identify, is the ability to directly address specific registers in high level code.
