folta@tove.umd.edu (Wayne Folta) (12/27/89)
I have two questions regarding graphics programming using THINK C's Class Library: 1. I take it that the Class Library eliminates the explicit use of an event loop (the details being handled in Application). Is this true? 2. What if I want to write a program that is constantly drawing, but is interrupted by user actions. The Class Library seems set up to work well with static documents that only change under user control. But I want to write something like a Mandelbrot program which continues to draw until the user clicks to zoom in. Should my drawing become a Chore? I also have a question about writing a very custom profiler: 3. I would like to write my own profiler that generates an entry for every single instruction, noting the instruction's location and the memory (if any) addressed by the instruction. Is this easily done on such a fine-grained level? -- Wayne Folta (folta@cs.umd.edu 128.8.128.8)
siegel@endor.harvard.edu (Rich Siegel) (12/27/89)
In article <21446@mimsy.umd.edu> folta@tove.umd.edu (Wayne Folta) writes: >I have two questions regarding graphics programming using THINK C's Class >Library: > >1. I take it that the Class Library eliminates the explicit use of an event > loop (the details being handled in Application). Is this true? Only in the sense that the class library handles the event loop for you... >2. What if I want to write a program that is constantly drawing, but is > interrupted by user actions. The Class Library seems set up to work well > with static documents that only change under user control. But I want > to write something like a Mandelbrot program which continues to draw > until the user clicks to zoom in. Should my drawing become a Chore? (Not being entirely conversant with the TCL, I'm not too sure about this one. Perhaps Greg Dow can shed some light here.) >I also have a question about writing a very custom profiler: > >3. I would like to write my own profiler that generates an entry for > every single instruction, noting the instruction's location and the > memory (if any) addressed by the instruction. Is this easily done on > such a fine-grained level? Ha. Ha. Haha. Ahem. :-) To trace individual instructions, you need to insert a vector to your own Trace exception handler in the appropriate exception vector. This hypothetical exception handler can then interpret the exception stack frame to get the executing instruction. At this point, to determine anything more than the actual instruction's content, you'd need to actually decode the instruction; break down the mode and register fields, if any, and then decode the effective address in the same fashion that the processor would do it. And of course, you'd have to handle illegal addresses and illegal instructions appropriately, and decode coprocessor instructions, and so on. In recording the information, you need to keep in mind that your exception handler cannot move memory, since it's executing at interrupt time (trace interrupt, to be exact). I would suggest that you are approaching the problem backwards; instead of profiling on such a fine level of detail, profile the individual routines to determine where the most time is being spent. Then, take a good hard look at that routine. Unroll loops, reuse registers, minimize stack usage, and if you need to, whip out your trusty 68000 manual and determine the relative timings of various instructions, so that you can figure out which ones will do your task most effeciently. In my opinion, it's not worth the effort to write a profiler such as you describe (though I understand that the MPW profiler takes a pretty good pass at it). It's more worth your time to expend the effort in writing moderately efficient code, and then banging hard on the time-critical stuff later, after everything works. R. ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "When someone who makes four hundred and fifty dollars an hour wants to tell you something for free, it's a good idea to listen." ~~~~~~~~~~~~~~~
ted@hpwrce.HP.COM ( Ted Johnson) (12/28/89)
> In my opinion, [opinion deleted...] ... >Rich Siegel >Staff Software Developer >Symantec Corporation, Language Products Group ... >"When someone who makes four hundred and fifty dollars an hour wants to >tell you something for free, it's a good idea to listen." Are you referring to yourself? (The quote isn't attributed to anyone) Sounds like Symantec pays you VERY WELL! ;-) -Ted