scott moore wrote:
> The result register is not an ordinary register. Because it only has to
> be loaded at the exit of the function, it does not compete for resources
> with any other register.
Maybe on your machines the result register is special, but on VAX,
Alpha, and Itanium, the result register is normal register. I can be
used for anything right up to the point where the function returns.
The act of "assigning" the function result to
> a register (or whatever) at the end of the function is distinctly
> different from common variable register allocation, and should not be
> unified with, and treated the same as, common variables.
Well, it is in my compilers. The function result variable might live in
R0 during the body and the "special move" at the end might be optimized
away. Other times, the function result variable might live in various
registers and/or stack locations and get moved to R0 right at the end.
It is already strange.
>
> This aside, let's go back to WWWD (What Would Wirth Do). The basis of
> Wirth design philosophy is that we don't include language features
> unless there is no other way to easily accomplish the same result
> without it.
>
> Extrapolating the result to a full variable neither enables the language
> to do something it formerly could not, nor does it significantly
> facilitate an ability that did not formerly exist. The alternative to
> function results as variables is, yes, a variable, as in a formally
> declared variable.
>
> Finally, the purpose of the function result mechanism is to provide,
> yes, function results. Promoting it to a full variable changes the
> meaning and purpose of the feature, duplicates a language feature that
> is already in existence (variables), and worse, creates a hybrid
> "variable" that has special, and inexplicable, powers over a standard
> variable, with the addition that it isn't declared in an obvious way
> either.
Yep, we're in agreement here. Function result variables aren't full
variables. You can't READ into them, you can't pass them to VAR
parameters, etc.
However, we didn't "promote" anything. The function result variable is
still the same. What we added is another variable that gets
automatically assigned to the function result at the function's exit.
You still have to fill it in (or it may have an initial state).
Functions that want to "build" the function result (especially for
functions that return records or arrays) really want to read the
"current" result in their body. So instead of changing the existing
syntax to allow reading of the "current" result, we added a new syntax
that forced the programmer to pick a new name of the function result
that could be read as well as written.
Classic Pascal already has the weird function result variable that
wasn't a real variable. It was already special cased in the grammer.
Throw some of the mud at Wirth.
>
> This feature qualifies as pure syntactic (and semantic) sugar. It's one
> of the many reasons I don't sup****t the extended standard.
Well, it may appear to be syntatic sugar to you (and perhaps to me, it
wasn't one of my favorite items in EP), but it does have a purpose.
With the addition of functions that return run-time sized values, it is
confusing how to declare your local variable of the correct size.
>
> With respect, I know we disagree over the standard. However, realize
> that your part in the standard was as a fundamental implementer of it
> (which I do respect). My part was the possession of shock and awe
> when I first read a copy of it. That is why, I suspect, we will never
> see eye to eye on these matters.
>
There are several parts of EP that I think were a waste of time both to
define and to implement.
--
John Reagan
HP Pascal/{A|I}MACRO/COBOL for OpenVMS Project Leader
Hewlett-Packard Company
|
