Recursive functions

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Recursive functions

shaqywacky
I've got the VM working except for recursive functions.  I can't seem to think of a simple way to implement this.  

To handle returns, I used the variable return_address.{function_name}.{ID}  

Where ID is a different number every time a function is called it the VM language.  But the problem here is that while a function that calls the function f like this:

push 0
call f
push 0
call f

will generate two unique return address variables(which is good because the program can not call f more than twice), but if it is called like this:

push 0
call f

function f
push 1
call f

f could be called an indeterminate amount of times.

One solution I think I found to this is to manually insert the return address within the VM implementation(IE basically calculating: SP+{lines needed until call complete}).  

Is this the best way to do this?

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Recursive functions

shaqywacky
I was trying my solution and it definitely doesn't work.  I was confusing SP with the program counter.  So now it's obvious that I need to use labels, but I can't see a way to do this.
Reply | Threaded
Open this post in threaded view
|

Re: Recursive functions

shaqywacky
Ok, I'm pretty sure I got it working.  I was very confused about somethings.  EG I keep forgetting that labels don't have anything to do with the stack and that when functions are called multiple times, the same area in ROM is always called.  Basically, things so obvious that I always forget them.

My VM seems to be working(woo!).  Also, I'm just curious but for anyone who actually reads this: How long would you guess it took you to get your VM implementation done?   Mine took forever because of poor choices on the assembler and hardware.
Reply | Threaded
Open this post in threaded view
|

Re: Recursive functions

cadet1620
Administrator
shaqywacky wrote
My VM seems to be working(woo!).  Also, I'm just curious but for anyone who actually reads this: How long would you guess it took you to get your VM implementation done?   Mine took forever because of poor choices on the assembler and hardware.
Congratulations on getting your VM translator working.  I think that it's the trickiest project in the book.

I was hoping that a student would have replied by now as their experience would be much more relevant than mine since I've been working in the computer industry for 35 years.

I pointed out TECS to an ex-student of mine and figured I should work some of it so I could answer questions he might have.  I didn't expect him to go beyond Chapter 6.  I did projects 1-6 in 5 evenings after work.  My student stalled out in chapter 2, but I had become a TECS addict.  I ordered the book.

When the Book got here, I started on the VM translator, again in the evenings after work.  I'd never written a VM translator, but the theory's easy enough.  The tricky thing is that one needs to learn the machine language rather thoroughly to do a reasonable job.  Push, pop, and stack arithmetic were straightforward; call and return were a bit trickier to do efficiently.  My code seemed rather long to me so I did some reverse engineering of Pong to find its call and return code.  Turns out mine was only a few instructions longer--good enough for now.  

The VM took me 6 evenings, with the final "evening" running well into the wee hours of the next day.  If your VM took as long as the first half of the book, you're on par with me.

--Mark