Mail Archives: djgpp/2000/04/11/16:04:39
"Alexei A. Frounze":
> Well, but it work with registers even when value needs to be zeroed, shifted and
> so on. It loads registers in very simple situations, where possible to adjust
> some bytes and we're done.
What appears to me is that among a set of time-optimising variants, GCC doesn't
seem to choose the most space-optimising one. But maybe the values of registers
are re-used later in your code ? Some <32 bit manipulations are said to slow
down a lot the Pentium-class processors.
> > On Intel x86s there is not much to do - there are so few registers - but
> > anyway GCC is very smart at register mapping !
> Not a few. That's enough.
Well... but _compared_ to other processors the choice of registers is very poor.
> I don't think GCC is a very good optimizing compiler. Anyway it has something
> over other compilers: it's free, it's portble and multiplatform.
There are surely improvements till reaching Watcom C or Lahey Fortran that are
written with Intel code generation in mind.
But who knows (with the latest ecgs & Co ?)
> It always works this way. So I forced my functions to have only 32-bit
> parameters and return values. This solves this ugly problem.
> > You should try an equivalent test on a very
> > strong typed GCC front-end like GNAT...
> What's GNAT?
The GNU Ada95. You can see Ada95 as a standardized Turbo Pascal with some
enhancements. Since type conversions are explicit (unlike TP for the 8/16/32
bit integers), you detect the "ugly problems" at source :-).
______________________________________________________
Gautier -- http://members.xoom.com/gdemont/gsoft.htm
- Raw text -