Yes, it's not that unusual for DOS programmers to "fall back" to assembly; inline assembly was much cleaner and far more effective than the disparate OS-hooks built into the various compilers. You could do asm { pushf, pop ax } to save the flags register, and do whatever you want with the machine (e.g. masking interrupts) but to do the same in pure C you would have had to use MS, Borland or Watcom extensions (yes, inline assembly was more portable and stable than the various levels of C standardization supported by the compilers.)

Other fun ones were variable length structs, and bitfields. http://www.ddj.com/cpp/184403480

Yeah, I recall people doing similar with 'fistp' to get quicker float->int conversions. (There are quicker tricks using direct manipulation of the fp representation, but those have always had the decency to be hidden in macros).

Also, I recall assembler code (65816) where the programmers had directly encoded instructions (DB $aa,$bb) since an earlier (probably 6502) assembler had not supported them.

In those days, gamers programmers had more in common with scientists in their attitude to programming - they made games, programming was simply a means to that end. Also, games had pretty much zero maintenance after release.

On one heavily optimized 3D CAD software that I've worked on, I've seen a hundreds of x86/PPC assembly snippets in #ifdefs, embedded in the C code. It was basically for the software to be very fast on Windows and on Mac OS X PowerPCs. Some of those were legacy optimizations, because modern C++ compilers (VS 2003 and up) are smart enough to match that speed gain with better binary generation. But some other assembly parts were truly meant to recreate a customized and fast GPU-like pipeline on the CPU, using registers for really fast per-pixel/voxel operations.

I've heard that Photoshop is also riddled with assembly code, that's why it took so long for Adobe to port it full-performance for the new Intel-based Macs in 2006. (Lots of PPC -> x86 mini-ports)

I'm sorry - I should have been more clear - I _get_ that you inline assembly when you need to do something your Compiler won't let you do (or makes difficult), and that clearly people sometimes will tweak some inline assembly to get a bit more performance - But has anyone ever seen a developer "Struggle with C's casting rules" - and switch to Assembler to over come that challenge? That just seems like an unexpected approach to that problem of understanding a kind of fundamental C concept...

No, I've never seen someone drop to assy due to something as simple as not understanding typecasting. Historically it has been for speed (used to be common, a lot less common now) or to do something the compiler/language doesn't support. The anecdote falls into the latter class, but only because the original code author didn't understand C well enough.

When I started programming, the running joke was "you can write FORTRAN in any language, some are just more difficult."

One of my coworkers commonly uses pointer math rather than array indexing, so inline asm isn't that much of a stretch. Some C programmers are just thinking in assembly.

That's such a great bite-sized tale. Reminds me of http://folklore.org/.

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.

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.

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.

Yup, right here...

http://news.ycombinator.com/item?id=975575

I wonder if my response to that post triggered him making that blog for clarification. (Basically rebutting my quality complaint.)