Re: Tools

[Erik <br0ke@math.smsu.edu>]

On 10-Jan-2000 Mithras wrote:
> 
> 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:
> 

I haven't read his work, but I've heard people complain that his solution to
everything is assembly... 

Before 3d accelerator cards started becoming popular, assembly was pretty much
required for fast 2d, much less 3d. However, with opengl and shtuff, all the
intensive operations where asm shines are being exported to specialized
hardware. Double buffering used to be a critical place for assembly, now we
just do glXSwapBuffers() or glutSwapBuffers() and it does it on the card,
stealing essentially 0 time from your program. Things like light calculation
are all on the card (unless you write your own, as many profession games do).
It used to be critical to games, now it's not.

Assembly destroys portability. If your program uses no assembly, then you can
compile on other architectures without any real effort. Just copy the source to
the target machine, maybe verify endian, and poof, you have an arch port. With
xp libraries, you can even drop the source on different os's and have it
compile with no fighting. Assembly requires complete rewrites for every
architecture, and often rewrites for different os's. 

Don't let this stop you from learning assembly, tho. :) A good background in
assembly often makes a better C programmer, as you understand how the machine
really works at a byte level.

>>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.
> 

Write the code in a higher level language, like C or C++. Then profile it. If
you notice something simple that's getting a lot of activity and stealing a lot
of CPU time, optimize that in the higher level language as much as you can. If
it's STILL not satisfactory, and you think you see a perfect way to do it in
assembly, comment out the code and write an assembly version and see if that
makes a real difference. If it does, then leave it assembly, leave the C
comments, and maybe do some #ifdef uglieness to provide portability. Most of
the time, good C code will be competitive with, if not outrun the assembly. The
people who write good assembly of any scale are really wizards at their art
imho :) (plus you want the C there for readability, or if someone wants to
compile it on a different arch but doesn't know assembly for that arch/os, they
can comment out the asm and uncomment the C and have it functional. Better yet,
use an #ifdef so the configure script can pick that up...)

> 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.
> 

C64 had a bunch of different "monitors" which gave you opcode access to the
runtime memory. I thought warpspeed had the best, tho fastloads was workable :)
that was cool sh*t in the 80's. I don't know if I'd suggest doing realtime
direct memory munging on a "modern" os. I know there were plenty of "oopses" on
my c64's and c128 where I'd have to reset the 'puter. You really couldn't do
any damage from locking the os or blowing something up on those, except maybe
lose data. An oops on a machine with a hard drive or a multi-user os can make a
big mess. If you do direct memory munging, make sure you're NOT root... I
beleive gdb can do direct memory shtuff. It reads with 
"disassemble <begin> <end>", but I don't know if it can assembly, too. :/ 

gcc -S something.c    <-- will produce something.s which is the assembly for
the C program
gcc will also assemble .s programs, acting as a frontend for as86 or gas I
beleive

> Thanks,
> 
> Ben Taylor
> 
> 

        -Erik <erik@smluc.org> [http://math.smsu.edu/~br0ke]

The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep
Refrigerated.