rbj@icst-cmr.ARPA (Root Boy Jim) (07/09/86)
Sam Kendall of Thinking Machines writes: In article <2036@brl-smoke.ARPA> you write: >I have said all along that there is no reason why a compiler can't >perform the following transformation: > > LEGAL DESIRED > foo() foo() > { register int j; { register int j; > auto int k; > k = j; > bar(&k); bar(&j); > j = k; > } } > >Sort of a Call by Value-Result, eh? You mean that the compiler should transform the users's code on the right into the code on the left, I assume. Yes. How would you handle this: f(){ register int j; j = 0; bar(&j); j = 1; if (*static_p == j) /* this test wil fail */ ... } int *static_p; bar(p) int *p; { static_p = p; } Of course, your transformation would work in most cases, but for the compiler to verify that would take some pretty sophisticated global analysis. A compiler that could actually do such global analysis could convert the register variable to non-register auto when it can't verify your transformation is okay. Good point. We certainly have introduced another glitch here, but one we are all familiar with. Consider in FORTRAN that when you call a subroutine as CALL FOO(ARG). Your poor variable (passed by reference) is subject to modification by FOO. To avert this, you can CALL FOO(ARG + 0). This forces a temporary location to be generated for the expression, thereby forcing a call by value. But back to C. I have traded absolute pointer accuracy for temporary pointer convenience. That is, the address of a register variable is only valid for the life of the callee. But Wait! That's a Mimic! Register variables are really fast auto variables, so after `f' returns, your static_p is worthless anyhow. It seems I have merely narrowed the scope a bit. Is it worth it? Possibly. Scope glitches seem less limiting than storage class ones. You pays your money and you takes your choice. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> I'm dressing up in an ill-fitting IVY-LEAGUE SUIT!! Too late...
rbj@icst-cmr.ARPA (Root Boy Jim) (07/09/86)
> Good point. We certainly have introduced another glitch here, but one we > are all familiar with. Consider in FORTRAN that when you call a subroutine > as CALL FOO(ARG). Your poor variable (passed by reference) is subject to > modification by FOO. To avert this, you can CALL FOO(ARG + 0). This > forces a temporary location to be generated for the expression, thereby > forcing a call by value. Are you arguing that because Fortran is gross, it is okay for C to be gross also? Yitch. No, I think fortran does the right thing here. > But back to C. I have traded absolute pointer accuracy for temporary > pointer convenience. That is, the address of a register variable is > only valid for the life of the callee. In other words, you are breaking the semantics of C. This is a very bad thing, certainly not worth it for the rather minor gain in convenience or efficiency that you propose. Let the programmer assign the register variable to an auto variable and pass the auto variable's address -- it is in the tradition of C to make programmers perform optimizations like this if they really want them. > But Wait! That's a Mimic! Register variables are really fast auto > variables, so after `f' returns, your static_p is worthless anyhow. > > It seems I have merely narrowed the scope a bit. Is it worth it? > Possibly. Scope glitches seem less limiting than storage class ones. This is an issue of lifetime, not scope. Okay, scope in the time domain :-) Also, a glitch where something that should be allowed isn't and causes an error message (taking the address of a register variable) is MUCH better than a glitch where something that should be allowed, and is according to the manual, quietly fails (using static_p). Except that I've never wanted to do what you propose, and I have often wanted the address of a register. We all know registers are different from `regular' (auto) variables. It's just a question of what differences. Taking the address of any auto variable is risky business; you can easily forget if it's valid or not. Why should it be surprising that registers are more transient? Do you have a Zippy quote database, from which a line is randomly selected for each letter/news item you send out? Sort of a Zippy "fortune"? Make that `Pinhead Fortune'. Yow! It comes with GNU EMACS. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> I just forgot my whole philosophy of life!!!
rbj@icst-cmr (Root Boy Jim) (07/10/86)
RBJ-> >But Wait! That's a Mimic! Register variables are really fast auto
>variables, so after `f' returns, your static_p is worthless anyhow.
Gwyn-> But the objection is still valid. If the compiler were to fake up
some addressable storage for a copy of a register variable, then
afterward it would need to ensure that the contents of that location
track the contents of the register, since the pointer could then be
legitimately used to refer to the data in the register. This would
negate the whole point of "register".
Would it? Okay, so we have to pushmi-pullyu the register anytime we
call any function, or reference any global variable starwise, or
perhaps reference either the result of the function or even any
arguments originally passed by reference.
This is starting to get compilicated! Anyone for a 500k C Compiler?
It would probably still be smaller and faster than ADA :-)
Dennis knew what he was doing. The restriction of & applied to a
register variable is deliberate and sensible.
I agree. I was merely speculating on the tradeoff's involved.
So when are they going to start making droids with addressable registers again?
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
He is the MELBA-BEING...the ANGEL CAKE...XEROX him...XEROX him --