News for hackers. Stuff that matters.
Re:Three lessons I learnt from porting Diablo by elblanco on Friday December 04, 2009 @03:28AM (#976008)
I've seen it for parts of code that need to be particularly performant. In the old days, when clock cycles were at a premium and compiler optimizers stunk, great hackers could squeeze an extra 10-30% out of a piece of code by rebuilding certain expensive parts of code in asm instead of relying on the compiler's version. Usually it involved a particularly arcade knowledge of the chip's timing or pipelining rules so that there were no wasted clock cycles, cache misses, or minimizing branch prediction errors....that kind of thing.
Re:Three lessons I learnt from porting Diablo by lt on Friday December 04, 2009 @05:56AM (#976135)
That's writing a whole routine in asm, though. Embedding a couple lines of asm in a function can have the opposite effect - the optimizer can no longer make assumptions about some things disabling a large number of potential optimizations for that routine.
Re:Three lessons I learnt from porting Diablo by samlittlewood on Friday December 04, 2009 @08:10AM (#976271)
Fortunately, the Watcom compiler (tool of choice at the time) had a mechanism for describing register use and side effects of embedded code fragments - somewhat like gcc.

It was common for any 3d games to have 16.16 fixed point type all wrapped up in macros using asm fragments. The crucial thing was using a 64 bit intermediate for muldiv and mulacc expressions.