🚀 go-pugleaf

(sorry for commenting this late, we seem to have some problem with the
 news system here)

In article <2384@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:

(about ASSIGNed GOTOs)

>> >Given the relatively small number of addresses involved, using a lookup
>> >table and a small integer token for each numbered line is an easy solution
>> >to this problem.
>
>It is not just a matter of space but of time.  What is really wanted is
>a *label to go with the GOTO.  Whether this is stored in an integer or
>not is of little concern for wfficient programming.  Even a small looking
>table instead of using a register variable costs.  This should have been an
>automatic efficiency consideration for at least the past 25 years.

Are you _really_ concerned about _one_ extra memory access? (and one likely
to be in the cache at that?) What sort of code do you write?

(And it would be more polite to put it like "What _I_ really want..."
 instead of boldly stating "What is really wanted" all the time. Your wishes 
 and desires may not be the whole worlds.)

>Fine, as long as only the optimizer uses it.
>
>BTW, besides the goto, there should be a branchto, where it is the
>responsibility of the remote code to see that the relevant aspects of
>the current configuration are preserved or restored.  This is, at the
>present time, difficult to do automatically if there are space proglems,
>such as an inadequate number of registers.

What do you mean by this? "where it is the
responsibility of the remote code to see that the relevant aspects of
the current configuration are preserved or restored"? This sounds like
a subroutine call (with callee-save)?
-- 
Bengt Larsson - Dep. of Math. Statistics, Lund University, Sweden
Internet: bengtl@maths.lth.se             SUNET:    TYCHE::BENGT_L