jfw.mit-ccc@Mit-Mc@sri-unix (11/24/82)
Date: 22 Nov 1982 12:56:48-EST I must admit that I am confused about the new csav routines. It is claimed that csav is faster than csv, but when I do the time computation (using the timing listed in the PDP 11/45 Processor Handbook), I get: routine CORE MOS Bipolar CSV 10.88 6.30 4.80 CSAV 12.36 6.75 4.95 Is this merely perversity of the 11/45? Also, I am not sure of what problem csav fixes. As near as I can tell, they seem to be equally susceptible to being gunched by a signal. --John Woods jfw@mit-ccc@mit-mc
ark (11/24/82)
The advantage of csav over csv is that if a signal comes in at just the wrong time during csv, the stack pointer registers may not be pointing where they should. In particular, r5 may contain a return address rather than a stack frame pointer.
ecn-pa:bruner (11/25/82)
The "csv" signal bug can cause unexpected bus errors or memory faults in programs that use setjmp/longjmp. Suppose that function X calls "setjmp", then calls function Y, which calls other things. When a signal is received, the signal processing function Z is called. Suppose Z calls "longjmp". "longjmp" traces back through the stack frames to find the stack frame for Y (this contains R2,R3,R4 from X) and returns to X. If the signal was received right after a "jsr r5,csv" (before R5 is changed to point to the new stack frame) then R5 contains a text address (or, if it is separated I/D, a possibly-nonexistant data address), and the stack traceback will eventually go out of bounds (memory fault) or encounter an odd address (bus error). --John Bruner
gwyn@Brl@sri-unix (11/25/82)
From: Doug Gwyn <gwyn@Brl> Date: 24 Nov 82 18:05:12-EST (Wed) The relative speed of csv and csav is processor-dependent. It does appear that on most processors csv would be a tiny bit faster. My guess is that the "tst -(sp)" in csav to obtain an extra scratch cell on the top of the stack was added after the original timing measurements, since without this instruction csav is definitely faster. The interrupt problem csav was supposed to solve involves having a signal interrupt the csv sequence, then a longjmp() performed by the signal catcher. I haven't traced through the sequence of events involved, though.
trt (11/29/82)
I am not sure why csav was ever claimed to be faster than csv-- it makes an extra memory reference, after all. Speed was not the issue. Editor core dumps were. The csav/cret sequence CAN be sped up though. In cret, change rts pc to mov (sp)+,pc (Perhaps the engineers worked harder on "mov" than "rts".) Tom Truscott
trt (11/29/82)
A minor point (drat, I should have read all the followups), but tst -(sp) is not as fast as sub #2,sp Strange, but true. Perhaps the csav timings used the "sub" version and then someone "improved" it to use "tst"? Tom Truscott