About "You are not expected to understand this:"<p>> So we tried to explain what was going on [in the listing]. "You are not expected to understand this" was intended as a remark in the spirit of "This won't be on the exam," rather than as an impudent challenge.<p>> The real problem is that we didn't understand what was going on either. The savu/retu mechanism for doing process exchange was fundamentally broken because it depended on switching to a previous stack frame and executing function return code in a different procedure from the one that saved the earlier state. This worked on the PDP-11 because its compiler always used the same context-save mechanism; with the Interdata compiler, the procedure return code differed depending on which registers were saved.<p><a href="http://9p.io/who/dmr/odd.html" rel="nofollow">http://9p.io/who/dmr/odd.html</a><p>Similar trickery can be found with the RETF instruction in x86 processors. With the 8086, it was the fastest way to do an indirect far calls (in x86 jargon, a call that can address more than 64K of memory), since there's no way to do it using just registers. It pops the address from the stack, then the code segment/selector, and jumps to there. Simple, right?<p>This caused havoc in later processors when RETF got optimized. The new processors predict that RETF will always, well... return, and preload instructions based on that assumption. If it was used as a far call, it would reliabily ruin the instruction cache, making it actually quite a slow way to do far calls.