Not to take issue with JG on this but stacking operations definitely store a lot more machine state than normal program linkage would require and so even on the most current machines they take a lot longer.
It would be a bad idea to do wholesale replacement of traditional entry/exit linkage with BAKR/PR. But we're talking in terms of microseconds per instruction. The stacking instructions are enormously valuable in situations where the alternative would require you to obtain storage. They will ALWAYS outperform OS storage obtain/release by many orders of magnitude. So use them appropriately for your situation and there's no real down side. At this point I would usually feel compelled to throw in a remark about interactions with recovery. But I am on a phone, so I won't. CC On Jun 27, 2013, at 9:37 AM, "John Gilmore" <jwgli...@gmail.com> wrote: > I wish I had some definitive timing results to provide. I do not. > > I can, however, report that timings for otherwise identical blocks of > SRB code within which BAKR/PR and alternatives to them are used do not > at all support the notion that BAKR/PR is slower than they. > > John Gilmore, Ashland, MA 01721 - USA
