Re: Tools

[Mithras <mithras@dhp.com>]

I've been lurking on this list for the past year and a half, but this
topic is very important to my self-education efforts.

On Fri, 7 Jan 2000, Erik wrote:
> > Yes, knowing assembler is important, and even with todays compilers,
> > sometimes you have to use assembler. For example, we have a sound mixer
...
> > blending blitter", moving a few megs per second of data)... Turned out
> > okay without it (Quadra is a simple game), but maybe it would help my
> > 486 if I did it.
> > 
> 
> I don't think you should learn assembly to use it occasionally... I really
> doubt there's a serious need. I think asm is important to learn so you
> understand why x++ is better than x=x+1 (unless the compiler optimizes that for
> you...). And stuff like loops... having an idea of how that gets handled by the
> machine lets you make your programs more friendly to the machine. (but we still
> need skilled asm hackers to glue together the compilers so they use mmx and
> 3dnow and superdoopermegahyperglobalultra4324252 instructions... :)

This question, the true priority of assembler for linux game hacking, is
very important to me.  I don't yet have the experience to support an
opinion of my own, but I have got a book by Michael Abrash on graphics
programming.  I don't intend that his reputation alone should be a point
in the debate, but since choosing his book to guide my education in
graphics programming, I'm interested in how much the current wisdom of the 
mailing list agrees with his opinion:

>From 'graphics programming, Black Book' p. 29:
: Never underestimate the importance of the flexible mind.  Good assembly
: code is better than good compiled code.  Many people would have you
: believe otherwise, but they're wrong.  That doesn't mean that high-level
: languages are useless; far from it.  High-level languages are the best
: choice for the majority of programmers, and for the bulk of the code of
: most applications.  When the *best* code -- the fastest or smallest code
: possible -- is needed, though, assembly is the only way to go.

This has sounded plausible to me, and so when I discovered that several of
the book's examples use x86 assembly, I decided that I ought to learn
it (work still in progress).  Have I been mistaken?  From what I've read
so far, assembler optimization is valuable not only in the lower system
functions, but also in top-level loops.  If that were so, then we couldn't
depend on drivers and accelerator firmware alone to have the best
performance, game-level programmers too would be responsible to find the
bottlenecks in their own code.  Or so it appears.

I have a second concern related to assembler, which is how do I get
interactive debugging for asm, such as gdb gives for Cish programs?  I've
been able to get disassembly to work in gdb, but I haven't been able to
step by asm instructions, rather than by C source lines.  I remember a
nice interactive asm debugger I used on my C64 years ago, with commands to
examine the registers and disassemble either around the point of execution
or particular memory ranges, but I haven't been able to reproduce that
since I've started experimenting with Linux (I do so humbly &
frustratingly admit).  If anyone can get me on the right track, I'll be
very happy.

Thanks,

Ben Taylor