Re: Is "register" generally ignored?

rkrayhawk@aol.com (RKRayhawk)
9 Mar 2002 02:55:51 -0500

          From comp.compilers

Related articles
Is "register" generally ignored? smeyers@aristeia.com (Scott Meyers) (2002-02-28)
Re: Is "register" generally ignored? {spamtrap}@erewhon.demon.co.uk (Maneki Neko) (2002-03-09)
Re: Is "register" generally ignored? fjh@cs.mu.OZ.AU (2002-03-09)
Re: Is "register" generally ignored? rkrayhawk@aol.com (2002-03-09)
Re: Is "register" generally ignored? bear@sonic.net (Ray Dillinger) (2002-03-21)
| List of all articles for this month |

From: rkrayhawk@aol.com (RKRayhawk)
Newsgroups: comp.compilers
Date: 9 Mar 2002 02:55:51 -0500
Organization: AOL http://www.aol.com
References: 02-02-067
Keywords: optimize
Posted-Date: 09 Mar 2002 02:55:51 EST

There are a lot of compilers and a lot of target machines. Yet it is
true that many efforts have Intel devices as a target.


Such a thing is register starved. The need to be able to save off
current infomation as you re-utilize scarce CPU resources leads to a
need to transpose a 'register' entity into a 'temp' on enough
occassions that the notion of bounding the thing inside the CPU fades.


The whole general discussion of whether your 'register' items are
really kept from memory does not fit entirely into a stack
contemplation by definition (you could 'push' temps or 'registers' out
to a heap if you like to be intricate). Yet usually the resulting
consideration is to decide where in the stack image any pushed
'register' entities will land, which may or may not have an effect on
the efficiency of displacing to that section of the stack image as
opposed to the 'named' autos.


Of course, even CPUs that have comparably more slots for 'register'
data have limits; so if enough flags are flipped on in a compiler's
optimization algorithm it ultimately becomes useful (for the user of
the software) to rethink the coder's specification of what should and
should not be enregistered for optimum speed.


It is interesting that there is chatter about the viability of the
IA-64 market adventure, since it has many more registers. The entire
device is harder for compiler writers to target (not just the wealth
of registers). But the extra registers, the very essence of
enregistration, has not determined outcomes in the market place. That
presents us with a perspective. The "register" specification does not
compete well against alternative optimization strategies where the
machine hits the real world.


The spec "register" harkens from a day that C was idealistically
believed to be assembly language in functional language form. This
still relates to real world work, but only a small part of it. The
mature compilers, especially the C++ and C sharp offerings are tools
with paradigms that are focused at some distance from the CPU
resources.


Best Wishes
Bob Rayhawk


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.