[LCP]register question

[Lawrence Sim]

On Fri, 23 Nov 2001 10:39, Matthew Sanderson wrote:
> 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?

The register keyword is only a suggestion to the compiler, if it thinks 
you are nuts then it won't do it, no matter how hard you suggest.

> 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
>
> _______________________________________________
> This is the Linux C Programming List
>
> :  http://lists.linux.org.au/listinfo/linuxcprogramming List

-- 
Lawrence Sim
Web: http://users.bigpond.net.au/Lawrence_Sim/
'Such is Life' - Ned Kelly, just before he was hanged.

There's just something I don't like about Virginia; the state.