Re: a book or tutorial

[Steve Baker <sjbaker1@airmail.net>]

Martin Donlon wrote:

> It is perfectly possible for someone to write better code than a
> compiler.

In a very small section of very specific code - certainly.

> If you take a application as a whole then yes, a compiler
> could write much better assembler than almost anyone.

Indeed.  The sheer stamina it takes to write (and especially debug)
any significant amount of assembly code ensures that.

> However, taking
> a specfic section of an algorithm it may or may not be possible to
> improve on the compiler generated code. Things like alpha blending or
> texture mapping can easily be optimised in this way, especially when you
> start using MMX/SSE/3DNow opcodes. As a programmer its your job to
> determine which parts or your code my require this kind of treatment and
> which parts are better left alone.

Even in these cases, the biggest problem is the HUGE but SLOW instruction
set of i86 family CPU's.  There are so many bizarre special-purpose
instructions that were stuffed into the CPU for some long-forgotten purpose,
that it's VERY difficult for the compiler to find an optimal sequence.
However, that large and complex instruction set does not come at no cost,
the instruction opcodes are larger than they need to be and FAR too much
silicon is wasted on decoding all that ancient crud.

If only we could dump Microsoft's stranglehold on the OS market, the more
modern lean/mean RISC architecture CPU's would rapidly overtake the bloated
i86 machines in commodity computers.  The keep-it-simple-stupid approach
of RISC gives a well written compiler a MUCH better chance of finding the
optimum instruction sequence - and whilst that'll certainly take more
instructions than on a Pentium, the opcodes are shorter and on most CPU's
will ALL execute in a single cycle.  RISC instruction sets were DESIGNED to
make compiled code run fast and are often pretty hostile to human programmers,
so the death of machine code programming is in sight - if only we can get
Microsoft out of the loop and allow some competition in instruction sets
and CPU architecture.

-- 
Steve Baker   HomeEmail: <sjbaker1@airmail.net>
              WorkEmail: <sjbaker@link.com>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net
                         http://freeglut.sourceforge.net



---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.dk
For additional commands, e-mail: linuxgames-help@sunsite.dk