Namespace

Dmitry Semenov hatter at chollian.net
Fri Jan 21 00:30:21 GMT 2000


Hi Oliver

Unfortunately some code optimization is desirable when making graphics
routines like alpha blending or space transformation. GCC cannot generate
some additional instruction provided by INTEL and AMD processors (or any
others). Specialized functions are 200%-1000% quicker sometimes. So just
imagine 1 million points which left after clipping and you have it rotate.
That it not so big part of GIS :)

Best Regards, Dmitry Semenov
EMail: hatter at chollian.net
Web:  www.chollian.net/~hatter

-----Original Message-----
From: Mailing list agent [mailto:mdom at barney.cs.uni-potsdam.de]On Behalf Of
Oliver Eichler
Sent: Thursday, January 20, 2000 7:20 PM
To: kdevelop at barney.cs.uni-potsdam.de
Subject: Re: Namespace


Am Don, 20 Jan 2000 schrieben Sie:
> I take away my question about including assembler sources. Just today I
made
> myself familiar with GCC inline assembler.

Do you really need inline assembler? My experience with that under VC++
is that you will gain next to nothing. Most problems can be programmed
as efficient in C if you keep an eye on the disassembley. Using inline
assembler will most likely trash you stack, violate coding convention
of resource usage of your C compiler and disables all optimization for
that module. The later will consume most of the 'gain' within the
assembler code. Plus it makes your code non portable. It is much better
to write assembler modules with nasm and to import them in C/C++. The
only situation I used inline assembler for good, so far, was to read the
timestamp register of a genuin Intel Pentium processor. Comming to the
conclusion: If you want to read a special purpose register of your
hardware inline assembler is a neat thing. If you want to write highly
optimized code go for a real assembler package.

oliver

Of course inline assembler is a neat thing, too, if you want to learn
assembler without going thru the iddy griddies of writing executable
assembler programs ;)

--
Ingenieure Kellermann, Voigt, Hoepfl, Eichler und Weidner

DSP Solutions                  http://www.dspsolutions.de





More information about the KDevelop mailing list