NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/arch/10958

Internet Message Format | 1992-11-19 | 3.4 KB

Xref: sparky comp.arch:10958 comp.lang.misc:3812
Newsgroups: comp.arch,comp.lang.misc
Path: sparky!uunet!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: [e-mail] (Herman Rubin)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News)
Organization: Purdue University Statistics Department
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 20 Nov 1992 13:33:15 GMT
Lines: 52

In article <[e-mail]> [e-mail] (Dan Prener) writes:
>In article <[e-mail]> [e-mail] (Bret Indrelee) writes:

>>    In article <[e-mail]> [e-mail] (peter da silva) writes:
>>    >In article <[e-mail]> [e-mail] (Herman Rubin) writes:
>>    >> But it is.  The operations often use register arguments and the results
>>    >> are wanted in registers.

>>    >What's a register? Most modern compilers ignore "register", or use it as a
>>    >hint "this is a frequently used value".

>>    >And how is an inline library part of the language more than a subroutine
>>    >or an include file?

            ............................

>Which leads to the optimization issue.  Compilers don't have to be
>completely pessimistic about what might be changed by pointer references.
>With a suitable definition of what it means for a variable to have its
>address taken, pointer references can only change those variables that
>have had their addresses taken.

>So, while it is true that register variables may lead to better optimization,
>that is because they never have their addresses taken.  So, with a compiler
>that keeps track of which variables have their addresses taken, the
>performance improvements resulting from the use of register variables remain,
>even after you delete the "register" declaration.

On most machines, one can do little with objects not in registers other than
read them, either placing the results in registers, or using the results as
instructions.  This means that it something is not in a register, using it
means first reading it.  If it is not kept in a register but stored, this
applies to using it again.  Some machines even restrict register movement;
memory access is unlikely to ever compete favorably with computation again.

If hardware/software designers and compiler writers would take the position
that load/store generally means waste unless the stuff being loaded/stored
is large, we may not have too much of a problem.  But there is one problem
with registers; I know of no current machines on which much use can be made
of the ordering of registers.  There have been a few machines on which
registers WERE addressable, and this has considerable advantages.

Some of the posters have suggested having a struct as a return when multiple
returns are wanted.  This is quite difficult to manage in a register file,
precisely because of the non-addressability.  It would even be a problem if
registers were addressible, because the locations wanted are unlikely to be
in a "struct" format.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: [phone]
[e-mail] (Internet, bitnet)
{purdue,pur-ee}!snap.stat!hrubin(UUCP)