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.
[ Parent
| on HN ]
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.