Should every return-address be unique?

[peterxu422]

When the vm command 'call' is invoked, should the return address that gets pushed onto the stack be a unique label each time, or only when a different function is being called?

For example, if you look at slide 16 of Lecture 8 titled 'Example: a typical calling scenario', you see a diagram illustrating the flow of the program control when the function p() is called. My question is, is it necessary to make a unique ret-addr label every time we encounter 'call' (so unique addresses for fact(4), mult(1,2), mult(2,3), etc.) or only when we call fact() and mult() (so the ret-addr for mult(1,2) and mult(2,3) can be the same)?

My guess is that yes, you would need to make a unique address each time, in which case I would implement it by having a counter added to some base string (like 'retAddr') each time I encounter 'call' which will guarantee that I have unique return-addresses.

However, I feel that this may be somewhat of an inelegant solution, as I can see that if I had a very large program, I'll have ASM code reading 'retAddrXXXXXXXXXXX'). My intuition is leading me to believe that if I make calls like mult(1,2) and mult(2,3), there should be some commonality between them and thus perhaps does not require me to make a unique return address for each call to a mult() function.

Any input?

[cadet1620]

You must have a unique label for every return IP in your program.  Otherwise, when the called function returns it will continue execution somewhere other than immediately following the call.

Appending a unique number is the correct thing to do.  Don't worry about how large the number will be; it can't be larger than 32768 since there's only 32K of ROM.  My game, which is 27K long uses 757 unique labels for all purposes. (Think about it; you don't actually need to preface the number with 'retAddr' etc., but it does make it easier to debug than if all your labels were L_nnnn.)

--Mark