jans@mako.UUCP (Jan Steinman) (04/30/85)
Here's a short register dump routine. It works fine on UTek (a Berklyoid), but I don't have access to V or true 4.2. It is probably non-portable to those. I wrote it in under an hour and it worked the first time. I used assembly because I couldn't figure out how to do it in C, but I don't claim to be a seasoned C hacker. Would others care to demonstrate HOL approaches to the problem, preferably in a friendly, non-inflamitory manner? To assemble on your favorite NS32000-based system: cpp dumpRegs.s | as -o dumpRegs.o ------------------------------ cut here -------------------------------------- /**** dumpRegs ****************************************************** * * This is a simple register dump routine. It accepts one parameter, which * must be a pointer to a zero-terminated string. It's return value is * undefined: whatever was in R0 upon call. All general-purpose registers are * preserved. */ .data L_fmt: .asciz "\t%s\n r7 r6 r5 r4 r3 r2 r1 r0\n%8x %8x %8x %8x %8x %8x %8x %8x\n fp sp sb upsr\n%8X %8x %8x %8x\n\n" .text .globl _printf .globl _dumpRegs _dumpRegs: sprd upsr,tos /*Stack parameters in reverse order. */ sprd sb,tos sprd sp,tos sprd fp,tos save $0xff /*Registers display in reverse order. */ movd 13*4(sp),tos /*Stack the caller's message pointer, */ addr L_fmt,tos /* and our "print" template. */ jsr _printf /*Print the stuff, */ adjspb $-2*4 /* delete the string parameters, */ restore $0xff /* restore the genereal registers, */ adjspb $-4*4 /* and delete the other parameters. */ ret $0 /*Caller must delete the msg pointer. */ -- :::::: Jan Steinman Box 1000, MS 61-161 (w)503/685-2843 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::
mat@amdahl.UUCP (Mike Taylor) (05/03/85)
> Here's a short register dump routine. It works fine on UTek (a Berklyoid), > but I don't have access to V or true 4.2. It is probably non-portable to > those. I wrote it in under an hour and it worked the first time. I used > assembly because I couldn't figure out how to do it in C, but I don't claim to > be a seasoned C hacker. Would others care to demonstrate HOL approaches to > the problem, preferably in a friendly, non-inflamitory manner? > > To assemble on your favorite NS32000-based system: > The following routine steals registers off the stack on my system (Amdahl) in C. It isn't much more portable than yours, though. I don't have an NS32000 and I didn't finish the job, but it's similar, and it seems to work. regs(message) char *message; { struct r { int regval[6]; } rinst; char *format = "\t%s\n r14 r13 r12 r10 r9 r8 \n%8x %8x %8x %8x %8x %8x\n"; int *point; point = &rinst ; point = point + 14; /* this is a cheat */ printf(format,message,point->regval[5], point->regval[4], point->regval[3], point->regval[2], point->regval[1], point->regval[0]); } -- Mike Taylor ...!{ihnp4,hplabs,amd,sun}!amdahl!mat [ This may not reflect my opinion, let alone anyone else's. ]
mwm@ucbtopaz.CC.Berkeley.ARPA (05/03/85)
In article <741@mako.UUCP> jans@mako.UUCP (Jan Steinman) writes: >Here's a short register dump routine. Would others care to demonstrate >HOL approaches to the problem, preferably in a friendly, non-inflamitory >manner? I can't resist :-). The problem is obviously machine-dependent, so here are solutions for two different architectures, In two different languages. First, for DEC mainframes and compatibles, we have a C macro: #define dump_regs(label) do \ {static int *r = (int *) 0; \ printf("%s\n%8d%8d%8d%8d%8d%8d%8d%8d%8d%8d%8d%8d%8d%8d%8d%8d", \ label, r[0], r[1], r[2], r[3], r[4], r[5], r[6], r[7], \ r[010], r[011], r[012], r[013], r[014], r[015], \ r[016], r[017]); \ } while (0) Unfortunately, I don't have access to a system to test it on, but it compiles, and should work. Now, for any true stack machine, this clu proc will work: dump_regs = proc (label: string) signals (no_registers) signal no_registers end dump_regs And, just to prove that I really am I Unix wizard, I'll note that you can write a C routine to do exactly what you want on any Unix box, with "just a small kernel mod" (in C, of course) :-). The point? You mean I was supposed to have a point? Well, I do. The entire discussion of HOL vs. asmbumbler is silly. There are problems that are suited to both. Things that need lots of speed, or need to get into the nitty-gritty of the hardware should probably be done in assembler (but may not have to). Things that you want to be portable to many machines should be done in a HOL. Enough, <mike