Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac.programmer Subject: Re: ROM doesn't unlock Handles (was: ROM unlocks Handles). LONG Message-ID: <9433@hoptoad.uucp> Date: 29 Dec 89 23:59:05 GMT References: <3875@atr-la.atr.co.jp> <4525@helios.ee.lbl.gov> <3888@atr-la.atr.co.jp> <9419@hoptoad.uucp> <3899@atr-la.atr.co.jp> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 75 In article <3899@atr-la.atr.co.jp> alain@atr-la.atr.co.jp (Alain de Cheveigne) writes: > /* saveBits is a Handle containing a BitMap record > followed by the bit image data. It needs locking > because CopyBits can move memory. */ > > state = HGetState((Handle) saveBits); > HLock((Handle) saveBits); > fixBitMap(saveBits); > CopyBits(&(w->portBits),*saveBits, > &(w->portRect),&(**saveBits).bounds,srcCopy,NULL); > HSetState((Handle) saveBits, state); /* restore state */ > >The "contents of the block" in the quotation above would refer here to >the BitMap record and its associated bit image data. Using the "copy >to temp" method to avoid locking would require a big piece of stack or >non-relocatable heap, time to copy, and the faith that whatever you >use to copy won't scramble the heap. BlockMove() is said to be safe, >but I'm less sure about calling strcpy() on a string in a Handle. A bitmap is only 14 bytes. The compiler can move it using three MOVE.Ls and a MOVE.W. I'm pretty sure that's faster than calling a trap -- that is, even the overhead of trap dispatch is more expensive than that, to say nothing of what the trap does once you get to it. I see what you mean now, and of course some locking does need to be done. For instance, if the baseAddr field of your bitmap is made relocatable, as you seem to be doing and as some code I'm now working on does, then you want to lock it, extract the pointer, stick it in the bitmap, and then revert to the previous state after CopyBits. Not only is it big, but it's variable-sized. But a BitMap structure is cheaper to copy into a temp variable than to save/lock/restore, e.g., BitMap map = **saveBits; /* four instructions to copy */ >The reason for putting the offscreen bitmaps in Handles is that they >are allocated and released as the user creates and disposes windows. >As the user is expected to use many windows (up to say, 50 in a >session), using Pointers instead would badly fragment the heap. Right. Good choice. >I'm less worried about WindowPtrs because they are all the same size, and >I expect new ones to tend to occupy the slots left by old ones. Well, maybe and maybe not. I throw caution to the winds and go ahead and allocate all my windows in the heap, but it's just bad design in the MacOS that they aren't relocatable, and they *can* cause heap fragmentation. You can't touch GrafPort's at the interrupt level anyway, because of the clipRgn and visRgn fields, so there's no reason the whole structure shouldn't be relocatable. No doubt by the time the designers realized this, they had all this hand-optimized assembly language code in the OS already written and it would have been impossible to modify. Another reason to use C to write operating systems. (I understand the MacOS was written largely in Lisa Pascal, then hand-optimized because the compiler was too stupid to do it. Changing a data structure from pointer to handle is not too hard in a compiler, because the compiler will pick up all the places that need to be changed, but a naive Pascal compiler won't put out fast enough code for many OS modules, or small enough code to put an entire OS in 64K. So all the code would need to be re-hand-optimized, a process which is likely to introduce many new errors and take a very long time. A naive C compiler can be fast enough with careful register declarations and expression phrasing. Optimizing compilers for either language should work just about as well.) -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "The Diabolonian position is new to the London playgoer of today, but not to lovers of serious literature. From Prometheus to the Wagnerian Siegfried, some enemy of the gods, unterrified champion of those oppressed by them, has always towered among the heroes of the loftiest poetry." - Shaw, "On Diabolonian Ethics"