[patch/rfc] Simplify target stack

[Andrew Cagney]

>> > Just because you can avoid doing it now doesn't mean that's OK.  You
>> >tell that to other developers at every opportunity.
> 
>> 
>> And given a set of alternatives I'll take the one with the greatest bang 
>> for the buck.
> 
> 
> Please don't pretend I'm the only one on this list who has asked for a
> contributor to take the longer way to a goal, in light of later
> cleanups.

I'm not.  I try to apply the `bang for the buck' rule evenly to both 
myself and to others.

For instance, given the choice of asking JeffJ to add a new 
LESS_THAN_SPECIAL architecture method (+ test + doco + ...) xor just 
tighten comments in frame.h, I chose the latter.  A full analysis of the 
problem revealed that the former and zero bang for the buck!

> This is standard practice for keeping the code maintainable,
> and evolving towards improved organization.

There's a balance.  Er to much towards features and code quality goes 
down.  Er to much towards structural perfection, and new features are 
never added.

You'll note that so far, as part of getting PPC64 linux working, I've 
also: fixed struct return, and elimininated the need for a redundant 
architecture method.

> I see that you've checked this patch in despite my objections.

I thought that I had clearly stated the rationale for ordering the 
development the way I had.  That left me, as target vector maintainer, 
and the person willing to do the immediate work, with a judgment call.

> Please
> let me know when you're done with modifying the target vector for a few
> days and I'll just separate instance and ops myself, including moving
> the new to_beneath and to_data fields out of struct target_ops.

It will be a lot more than a few days :-(  And if you wait long enough, 
I'll likely to do it myself!

Andrew