On Sun, Apr 21, 2002 at 01:58:58PM +1000, Andrew J Bromage wrote: > I think the problem could be fixed with some semantic constraints. For > example: > > - No jumps between subs except through the sub's entry point > are allowed.
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?) > - There are only a limited number of ways to generate an > absolute address, such as: > > - Returned from a call. > - Vtable method lookup. > - A special op which turns a relative address (which > must be const) into an absolute address. > > Any attempt to call an absolute address which was not > generated in one of these documented ways (e.g. by performing > some computation) results in undefined behaviour. Not sure what you mean by "returned from a call". 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? Or do you mean return addresses? Ah, that would make sense. So would this be the same as what you were proposing: - The only valid absolute code addresses are those of - Labelled instructions - Instructions following bsr/jsr (return addresses) - No arithmetic is possible on code addresses (the effects are undefined) - 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.) - Otherwise, code addresses may be treated as plain INTVALs (stored in arrays, copied between registers, pushed on the user stack, etc.) I want to be allowed to store the absolute address of a local label in a state structure, return from the subroutine, re-enter with the state information, and jump straight to that label. We'd need to define label scopes.
