note about tail call optimization in relevance to solving problems recursiively

This commit is contained in:
Medium Fries 2019-04-30 15:24:56 -07:00
parent 5663e07456
commit 447d7a3971

View File

@ -4,7 +4,7 @@
> Take a large problem
> Break it up
> Solve the pieces
/lecture
# Definitions
@ -16,3 +16,38 @@ _Recursive dynamic programming_
_Tabulation_
: Bottom up approach
: Go from little problems and build up
# Recursive compiler tricks
Normal iterative:
```
start:
...
jcond start
```
Normal recursion(under non-priveleged procs):
Each "iteration" creates a new frame of whatever size:
hence we approach the hard stack limit
_Sick guess_:
```
At compile we should be able to predict an incoming iteration from a
recusive endpoint.
? is it just parameterized jumps ?
```
_Answer:_
```
Tail recusion optimization
Takes the last statement of function
Assuming its a recursive call, we can replace our current stack frame's arguments
The only state that changes between calls then is just the arguments
```
In this sense we are turning a recusive functino into an iterative one because the whole state is held in one frame & we only ever jump within our routines address space.
However, this tail optimization can only happen at the tail of a routine.