[LCP]register question

[Matthew Sanderson]

O Linux C Gurus,

Can anyone confirm my suspicion, that egcs/gcc now totally ignore the
'register' keyword, and perform their own register allocation identically
whether or not it's there?

Neither the man page nor the info pages explain either way. I didn't yet
check the actual assembly that they generate.

--m@

On Wed, 21 Nov 2001, David Spencer wrote:

> Erik Mouw wrote:
> > 
> > To wake you up from a pretty dream: Pentium class CPUs (even the P-4)
> > are not at all considered modern. It's a design that dates back from
> > the early eighties (8086), and it has legacy things like segmentation,
> > a real mode, and an overly extensive instruction set. Even worse is
> > that it has only four general purpose registers (eax - edx), of which
> > three are also used for things like indexing and shift counts, which
> > leaves you with only one real general purpose register. Compare that
> > with other CPUs which usually have a RISC architecture with plenty of
> > general purpose registers (at least 16).
> 
> I thought the segmentation, real mode and the rest of the legacy stuff
> were "emulated" and that the "normal" operation of the Pentium was in
> fact relatively modern (e.g. the memory model of the Penty is actually
> flat, but you can do segmented if you want).  Of course just having the
> legacy stuff on chip will slow the thing down by virtue of the extra
> decoding.
> 
> > The drawback is that you can get less optimal code because you force
> > the compiler to put the wrong variable in a register
> 
> No - the register keyword is only a hint, which the compiler does not
> have to use at all.  These days though most fairly frequently accessed
> memory will be cached anyway so moving it a few mm closer to the ALU by
> putting it into registers will be pretty futile anyway.  There are other
> ways of speeding stuff up: use a better algorithm, rewrite the tight
> stuff in assembler etc, and if you are already using optimal code, buy a
> faster processor, or buy a multiprocessor system so that your tight loop
> isn't interrupted by keyboard scans.  Or, ultimately, reimplement the
> software in hardware.
> 
> But yes the original point is still valid: you have to profile an
> application to find out the bottlenecks before you can streamline it.
> 
> Dave.
> _______________________________________________
> This is the Linux C Programming List
> :  http://lists.linux.org.au/listinfo/linuxcprogramming List
>