🚀 go-pugleaf

In article <4i2oof$9lg@solutions.solon.com>, sl14@crux3.cit.cornell.edu (S. Lee) writes:
|> In article <4hv065$jao@solutions.solon.com>,
|> Konrad Schwarz <schwarz@a2.complang.tuwien.ac.at> wrote:
|>  >In article <4hqef9$1oj@solutions.solon.com>, hrubin@stat.purdue.edu (Herman Rubin) writes:
|>  >|> Question 1.  Is there a quick way of using a variable label?
|>  >|> The way it would be used is to identify the label to which one
|>  >|> wants to transfer, and then have some other place or places 
|>  >|> transfer to that point?  Transfers, loads, and stores take a
|>  >|> significant part of the running time of the algorithm, and
|>  >|> so something like setjmp and longjmp are to be avoided.

|>  >	register label = 0;
|>  >dispatch: switch (label) {
|>  >	case 10:
|>  >		do_something;
|>  >		label = 12;
|>  >		goto dispatch;
|>  >	...
|>  >	}

|> Which might be easier coded as
|> 
|> int label = 0;
|> while (1) {
|>     switch (label) {
|>     case 10:
|> 	do_something();
|> 	label = 12;
|> 	continue;
|>     ...
|>     }
|> }

True, true, and in practice I code similarly.  However, from previous
postings, I gather H. Rubin is very concerned with efficiency; my code
needs a jump less than yours in the absence of jump chain optimization.
Not very likely, but I wanted to be beyond all reproach in this category.

The second change you make is to remove the register qualification from
the variable ``label.''  I have seen many suggestions that register is
obsolete and that the compiler can make much better decisions to whether
a variable should be held in a register or not.  Many earlier compilers
where quite simple-minded about the register qualifier; the first $n$
variables declared register where allocated to register, where $n$ depends
on the architecture of the processor.   For example, 16-bit MS compilers
supported only two real register variables, putting them in the SI and DI
special registers, which then become unuseable for anything else.

This is not the only way to implement the register qualification.
It is, after all, only a hint to the compiler that the variable should go
in a register.  C (all forms) has always mandated that a register
variable's address cannot be taken, which immediately implies that
this variable cannot be aliased.  If you compare the assembly code generated
from C with many register statements to the same source without register
statements on a RISC machine, you will immediately see many more
variables actually being held in registers and much less load and store
traffic to main memory.  The restrictions ANSI C has on aliasing
are more fragile than many people may believe.

To wit, the Optimizing Techniques section of the Programmer's Guide on Digital
Unix contains the suggestions:

   ·   Use register  declarations  liberally.  The compiler
          automatically  assigns variables  to registers.   However,
          specifically  declaring  a register  type enables the
          compiler  to make  more  aggressive assumptions  when
          assigning  register  variables.

     ·   Avoid taking  and passing addresses (that  is, &
          values).   Using  & values can create  aliases, make  the
          optimizer  store variables  from  registers  to their  home
          storage locations, and significantly  reduce
          optimization  opportunities.

(Sometime ago, I found this to be true on a HP machine too)

It also contains the suggestion
     ·   Write  straightforward  code.  For example,  do not use
          ++ and -- operators  within  an expression.   When
          you use these  operators  for their  values instead  of
          their  side-effects,  you often get bad code.  For
          example,  the following coding is not recommended:

          while (n--)
              {
             .
             .
             .
              }

          The following coding is recommended:

          while (n != 0)
              {
              n--;
             .
             .
             .
              }
with which I am not particularly happy with.

>From a programming point of view, using ``register'' has some of the benefits
associated with using ``const''---by adding constraints, you improve the
chance of finding errors at compile time.   (I admit this is a weak point.)

To sum it up:  the register qualification should not be understood to
indicate heavy useage, but to indicate the absense of aliasing.

Konrad Schwarz