chris@mimsy.UUCP (Chris Torek) (07/30/88)
[I have redirected this to comp.misc, as perhaps I should have done earlier] In article <517@dms.UUCP> albaugh@dms.UUCP (Mike Albaugh) writes: > First, in re: assembly. While I thoroughly concur that it should >be used sparingly, I cannot condone an outright prohibition. Certainly---for instance, having /sys/vax/locore.s written in assembly, rather than in `asm' statements with intermixed C code, is clearly proper. Things such as #define VECTOR(x) (((void (**)())VEC_BASE)[x]) ... void my_keyintr(), (*old_keyintr)(); ipl_t ipl; ipl = iplraise(IPL_KEYINTR); old_keyintr = VECTOR(17); VECTOR(17) = my_keyintr; setipl(ipl); are somewhat `iffy', although I prefer the C code in this particular case. Stuff like f() { long *savedstack = &savedstack - 7; ... is, for me, on the other side of that line. >... Anyway, what is the orthodox way to deal with the fact that your >50,000 lines of debugged, tested code become 50,000 lines of >un-debugged, un-tested code every time a new release of the compiler >comes out. I know about regression testing, but the last time it ONLY >munged the multiply that was concerned with the average up-time of a >machine, so I didn't hear about it until a machine in the field had >been running continuously for over 32767 minutes. Any suggestions? I doubt you will find any infallible method. The obvious answer is a more strict regression test: add such multiplication to your test suite. Indeed, add anything that has ever triggered a compiler bug to your test sets. (This can quickly become unweildy :-) ) Knuth likes the `exercise every line of code' test: instrument the compiler, and arrange to have everything in it run at least once (including, of course, the error recovery code). This usually requires external hooks, and it helps immensely to have a compiler that does the instrumentation automatically. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris