G'day. On Sat, Apr 20, 2002 at 10:06:10PM -0700, Steve Fink wrote:
> Do we want to restrict subs to a single entry point? (for example, > what if you want one "initial" entry point, and one "resume" entry > point that figures out where processing left off?) Not necessarily. These are just ideas, remember. I want to restrict the number of ways you can get addresses of labels to ways that an optimizer/JIT compiler can fairly easily obtain them. > Not sure what you mean by "returned from a call". Functions should be able to return pointers to labels. > That sounds like > you're restricting how addresses can be passed around. So I can't have > an address in an integer variable and copy it to another? What's the > difference between that and returning an address from a call? No difference. You can copy labels as many times as you like, so long as you don't _manufacture_ them in arbitrary ways. > So would this be the same as what you were proposing: > > - The only valid absolute code addresses are those of > - Labelled instructions Currently, there are no labelled instructions. I don't really think we need them so long as we have some way to recover the labels (which is really what this discussion is all about). > - No arithmetic is possible on code addresses (the effects are > undefined) Absolutely. > - Local label addresses are only valid within the scope containing > the label (the result of jumping to someone else's local label is > undefined, possibly triggering an exception in debug mode.) At the moment, scope == module. In the future, I can think of several meanings for "scope" which make sense, but sub/method/function works for me too. I think there is a good argument to be made for limiting the organisation of bytecode files to have only one sub per code block, but I'm not sure the argument necessarily applies to Parrot. The JVM has this constraint, but it also doesn't easily support languages with Wirth-style nested subroutines. Parrot probably doesn't want to go to a great deal of trouble to support them, but we don't want to make it unnecessarily painful, either. > - Otherwise, code addresses may be treated as plain INTVALs (stored > in arrays, copied between registers, pushed on the user stack, > etc.) Yup. An optimizer, if it doesn't want to go to a lot of trouble, can make the conservative assumption that any jump_i can potentially jump to any label whose address has been taken somewhere else in the code. That's fine so long as this _is_ a conservative assumption. :-) Cheers, Andrew Bromage
