🚀 go-pugleaf

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."

~~~~~~~~~~~~~~~