From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-022 Date: Mon, 2 May 94 13:41:49 MET DST C.S.M.P. Digest Mon, 02 May 94 Volume 3 : Issue 22 Today's Topics: Best way to handle Moveable Modals? Can you set the folder in which SFGetFile will open? Control Panels items font Fixed Point Math on PowerMac Keeping DialogPtr's in RAM after startup... Metrowerks News from MacWEEK WaitNextEvent Emulated on PoMac!? X2Fix code generation bug still in SC++ 7.0 The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users as comp.sys.mac.programmer.src. ------------------------------------------------------- >From mahboud@aggroup.com (mahboud) Subject: Best way to handle Moveable Modals? Date: Fri, 08 Apr 1994 12:50:48 -0800 Organization: AG Group, Inc. Hi. What's the best way to handle moveable modals? Specifically, I want to be able to do process(application) switches (i.e. put my app in the background, while a moveable modal is foremost). Prefereably I want to be able to do this by changing a filterproc, not by going through the main event loop. I have tried putting WaitNextEvents in the ModalFilterProc, but it did some weird things. One reason I want to use the filterproc is that I still want to call ModalDialog to handle the events in the window, so I don't have to worry about updates, etc.. Thanks, mahboud ps. I already handle moving the dialog from within my filterproc. - ------------------------------------------------------------- Mahboud Zabetian mahboud@aggroup.com ag group, inc. 2540 camino diablo, suite 200 walnut creek, ca 94596 510-937-7900 voice 510-937-2479 fax 510-937-6704 ara ftp.aggroup.com anonymous ftp +++++++++++++++++++++++++++ >From mahboud@aggroup.com (mahboud) Date: Sun, 10 Apr 1994 14:50:00 -0800 Organization: AG Group, Inc. In article I wrote: > What's the best way to handle moveable modals? Specifically, I want to be > able to do process(application) switches (i.e. put my app in the > background, while a moveable modal is foremost). > > Prefereably I want to be able to do this by changing a filterproc, not by > going through the main event loop. I have tried putting WaitNextEvents in > the ModalFilterProc, but it did some weird things. One reason I want to > use the filterproc is that I still want to call ModalDialog to handle the > events in the window, so I don't have to worry about updates, etc.. > In response to all the mail I got, telling me to use the main event loop and not a filter proc, I'd like to clarify a point. I'd rather not use the main event loop, as I am retro fitting applications, one modal dialog at a time, and by adding to the filter proc of each existing dialog (most share the same filterproc), I would be making fewer changes overall. -mahboud - ------------------------------------------------------------- Mahboud Zabetian mahboud@aggroup.com ag group, inc. 2540 camino diablo, suite 200 walnut creek, ca 94596 510-937-7900 voice 510-937-2479 fax 510-937-6704 ara ftp.aggroup.com anonymous ftp +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 13 Apr 1994 23:24:46 GMT Organization: Apple Computer mahboud, mahboud@aggroup.com writes: > I'd rather not use the main event loop, as I am retro fitting applications, > one modal dialog at a time, and by adding to the filter proc of each > existing dialog (most share the same filterproc), I would be making fewer > changes overall. Given that you can't make them "modeless dialogs that won't let you switch to another window", you can get most of the functionality by modifying the filterProc. Users still won't be able to switch layers while your dialogs are up, unfortunately, because ModalDialog disables layer switching. In your filterProc: * On mouseDown, call FindWindow. If the click is on the title bar of the window, call DragWindow. Then change the event record to a nullEvent. Optionally, you can also respond to command-clicks in other app windows' title bars by dragging those windows without activating them. * On update, check whether the target window is an application window other than the dialog. If so, call whatever application routine handles update events. If you don't do this, moving the dialog will leave permanent white areas behind where the dialog used to be, as well as denying background time to other apps (see the tech note "Pending Update Perils".) --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Fri, 15 Apr 1994 09:46:34 +0800 Organization: NCRPDA, Curtin University In article <1994Apr13.232446.4419@gallant.apple.com>, Jens Alfke wrote: >mahboud, mahboud@aggroup.com writes: >> I'd rather not use the main event loop, as I am retro fitting applications, >> one modal dialog at a time, and by adding to the filter proc of each >> existing dialog (most share the same filterproc), I would be making fewer >> changes overall. > >Given that you can't make them "modeless dialogs that won't let you switch to >another window", you can get most of the functionality by modifying the >filterProc. Users still won't be able to switch layers while your dialogs are >up, unfortunately, because ModalDialog disables layer switching. If you're going to do this, why not just write your own implementation of ModalDialog? It's not that complicated, you just call WNE, and handle events (passing most of them to IsDialogEvent and DialogSelect). You have the same disadvantage of ModalDialog in that you aren't going thru your main loop, so you can't handle AppleEvents and other things that would normally get processed. Peter. _______________________________________________________________________ Peter N Lewis Ph: +61 9 368 2055 +++++++++++++++++++++++++++ >From troy@i-link.com (Troy Gaul) Date: Fri, 15 Apr 1994 18:53:08 -0500 Organization: I-Link, Ltd. In article , peter.lewis@info.curtin.edu.au (Peter N Lewis) wrote: > In article <1994Apr13.232446.4419@gallant.apple.com>, Jens Alfke > wrote: > > >mahboud, mahboud@aggroup.com writes: > >> I'd rather not use the main event loop, as I am retro fitting applications, > >> one modal dialog at a time, and by adding to the filter proc of each > >> existing dialog (most share the same filterproc), I would be making fewer > >> changes overall. > > > >Given that you can't make them "modeless dialogs that won't let you switch to > >another window", you can get most of the functionality by modifying the > >filterProc. Users still won't be able to switch layers while your dialogs are > >up, unfortunately, because ModalDialog disables layer switching. > > If you're going to do this, why not just write your own implementation of > ModalDialog? It's not that complicated, you just call WNE, and handle > events (passing most of them to IsDialogEvent and DialogSelect). You have > the same disadvantage of ModalDialog in that you aren't going thru your > main loop, so you can't handle AppleEvents and other things that would > normally get processed. I've done this, and it's not too bad. Makes retrofitting and still getting the AppleCorrect(tm) behavior fairly easy. With a little thought (and depending on the design of your application), you can even get this secondary event loop to handle high level events (if appropriate). This is left as an exercise for the reader. _troy //////// //////___Troy Gaul____________________________t-gaul@i-link.com__ // // // Infinity Systems ; West Des Moines, Iowa // // // // "Good news is just life's way of keeping you off balance" // // //////___________________________________________________________ // +++++++++++++++++++++++++++ >From Vampire@crypt.demon.co.uk (Vampire) Date: Sun, 17 Apr 1994 09:10:37 GMT Organization: Pennangalan Software I've been watching this thread for a few days now... The way I do this is a little Windows-inspired (don't all flame me, please...I HATE Windows...unfortunately my employers don't... I have a main event loop. (Surprise!). When I want to go Movable Modal, I get the module with the Modal to create its Window as usual, then get it to call a function 'RegisterModal', with the main control module. This function simply registers a second event-loop (particular to the movable modal concerned), and sets an internal Boolean, 'InModal', to TRUE. The main event-loop examines InModal, and if it is TRUE, ALWAYS passes the event onto the registered secondary event loop for handling. The secondary function returns TRUE or FALSE, depending upon whether it handled the event or not. If it didn't, the main-event loop can handle it as normal. That way, the Movable Modal code gets to react to events concerning it, ignore events that don't (e.g. update a background window), and *pretend* to react to events it wants ignored (i.e. mousedowns in another Window of the same application). ============================================================================= |"If I knock on your door, you're a fool; VAMPIRE | if you invite me in, you're a dead fool" (Pennangalan Software) | My dust resides @crypt.demon.co.uk ============================================================================= --------------------------- >From blume@twg.com (David Blume) Subject: Can you set the folder in which SFGetFile will open? Date: Fri, 15 Apr 1994 00:28:03 GMT Organization: Gokuraku Videos - Wollongong Dept. Can you set the folder in which SFGetFile and SFPutFile will open? --David +---------------------------------------------------------------+ | David Blume | "I get tired thinking of all the things I | | blume@twg.com | don't want to do." --Bukowski, _Barfly_ | +---------------------------------------------------------------+ +++++++++++++++++++++++++++ >From dubois@primate.wisc.edu (Paul DuBois) Date: 14 Apr 1994 20:38:06 -0500 Organization: Castra Parvulorum >From article <1994Apr15.002803.14161@twg.com>, by blume@twg.com (David Blume): > Can you set the folder in which SFGetFile and SFPutFile will open? This is how I do it if I have an FSSpec: CurDirStore = fss.parID; SFSaveDisk = -fss.vRefNum; Note that you use the negative of the vRefNum. I think this is horrendous, because it involves assigning values to two low-memory globals. Is there another way to do it? -- Paul DuBois dubois@primate.wisc.edu +++++++++++++++++++++++++++ >From stk@uropax.contrib.de (Stefan Kurth) Date: 17 Apr 1994 01:50:56 +0200 Organization: Contributed Software GbR In article <2okr5uINN970@uakari.primate.wisc.edu>, Paul DuBois wrote: > CurDirStore = fss.parID; > SFSaveDisk = -fss.vRefNum; > > I think this is horrendous, because it involves assigning values to > two low-memory globals. Exactly. > Is there another way to do it? If you can require System 7, yes. (the original poster asked about SFGetFile, so maybe this won't help him). Do a CustomGetFile; in your dlgHook you check for sfHookFirstCall, and if you receive it, change your reply record to whatever location you want to have displayed, and return sfHookChangeSelection. This has the additional advantage that you can specify a certain file to be selected. (You'll have to pass the address of the reply record in the yourDataPtr parameter if you don't want to make it a global var). _____________________________________________________________________ Stefan Kurth Berlin, Germany stk@contrib.de +++++++++++++++++++++++++++ >From pottier@kayak.ens.fr (Francois Pottier) Date: 17 Apr 1994 21:24:12 GMT Organization: Ecole Normale Superieure, PARIS, France In article <2optl1$57h@uropax.contrib.de>, Stefan Kurth wrote: >dlgHook you check for sfHookFirstCall, and if you receive it, change your >reply record to whatever location you want to have displayed, and return >sfHookChangeSelection. This has the additional advantage that you can >specify a certain file to be selected. If you want this to work, you also have to set sfScript to 0. I know it isn't mentioned in Inside Mac, but it's true. Took me days to figure out (thanks to Jon Watte's FAQ for pointing it out!) -- Francois Pottier pottier@dmi.ens.fr --------------------------- >From alex@metcalf.demon.co.uk (Alex Metcalf) Subject: Control Panels items font Date: Fri, 8 Apr 1994 23:20:33 GMT Organization: Demon Internet This is a slightly dumb question... How do you set the font for the DITL resource for a control panel? I've often opened up ResEdit to find the control panel's DITL displayed in Geneva 9 (such as check boxes and static text), but I can't seem to change from the default Chicago 12. Thanks, Alex -- Alex Metcalf, Mac programmer in C, C++, HyperTalk, assembler Internet, AOL, BIX: alex@metcalf.demon.co.uk "Surely you AppleLink: alex@metcalf.demon.co.uk@internet# can't be CompuServe: INTERNET:alex@metcalf.demon.co.uk serious?" Delphi: alex@metcalf.demon.co.uk@inet# FirstClass: alex@metcalf.demon.co.uk,Internet "I'm serious... Fax (UK): (0570) 45636 and don't call Fax (US / Canada): 011 44 570 45636 me Shirley." +++++++++++++++++++++++++++ >From bjaques@vanbc.wimsey.com (Barton Jaques) Date: 10 Apr 1994 20:43:53 GMT Organization: Wimsey Information Services In article , alex@metcalf.demon.co.uk (Alex Metcalf) wrote: > How do you set the font for the DITL resource for a control panel? I've > often opened up ResEdit to find the control panel's DITL displayed in > Geneva 9 (such as check boxes and static text), but I can't seem to change > from the default Chicago 12. In your cdev code, just set TextFont() to whatever you desire, before any drawing is done. Be sure to change it back whenever your code exits. You can change the ResEdit view font under "View As É" in the DITL editor. That only changes how it appears in ResEdit, though; it has no effect on the DITL resource contents. -- bjaques@wimsey.com +++++++++++++++++++++++++++ >From Reid Ellis Date: Sat, 16 Apr 1994 03:47:27 GMT Organization: Alias Research, Inc., Toronto ON Canada Alex Metcalf asks: |How do you set the font for the DITL resource for a control panel? Barton Jaques replies: |In your cdev code, just set TextFont() to whatever you desire, before |any drawing is done. Be sure to change it back whenever your code |exits. Alternatively, include a 'finf' resource, id=-4049, and set its three 16-bit ints to the font id, style, and size you want [in that order]. Caveat: I've been having problems with 'useWFont' popup menus in combination with the 'finf' resource under System 7.0 [it's fine under System 7.1] Reid -- - - Reid Ellis, Alias Research Inc. +1 416 362 9181 --------------------------- >From Willie Rauchwerger Subject: Fixed Point Math on PowerMac Date: 6 Apr 1994 21:22:02 GMT Organization: OU Health Sciences Center My image manipluation software uses fixed-point math for matrix math. However, in my PowerPC port, I am getting hardly no performance boost (seems slower to me) when I hit the matrix calcuations. After running TrapsCheck (very cool stuff), I find that the Fixed point math routines are not native. Ugh. After deciding not to do floating point because of speed, finding that Fixed-point calculations are slower now is not too funny. I would like to keep it using fixed point so that I can get good performance regardless of processor. Any ideas aobut how to get around this? Any ideas when the Fixed point routines will be native? Any separate libraries to do fixed point calculations? - ----------------------------------------------------------------- Willie Rauchwerger AppleLink: Willie Telemedicine Software Guy Internet: willie-rauchwerger@uokhsc.edu OU Health Sciences Center +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Wed, 6 Apr 1994 22:50:44 GMT Organization: Adobe Systems Incorporated Willie Rauchwerger writes > My image manipluation software uses fixed-point math for matrix > math. However, in my PowerPC port, I am getting hardly no > performance boost (seems slower to me) when I hit the matrix > calcuations. > > After running TrapsCheck (very cool stuff), I find that the Fixed > point math routines are not native. Ugh. Fixed point routines are not handled via traps for native code. Rather they are in the shared library InterfaceLib. This is a godd idea as already in 68K land people were using skanky hacks to get around the trap dispatcher overhead for the fixed-point math code. For emulated code, the cost of doing a mixed mode switch to native mode outweighs the benefit of faster antive mode execution. (Especially since the emualtor is going to be executing native multiply instructions anyway at the bottom level.) -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 "Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins) +++++++++++++++++++++++++++ >From fixer@faxcsl.dcrt.nih.gov (Chris Gonna' Find Ray Charles Tate) Date: Wed, 6 Apr 1994 23:46:17 GMT Organization: DCRT, NIH, Bethesda, MD In article <1994Apr6.225044.12892@adobe.com>, zstern@adobe.com (Zalman Stern) writes: >Willie Rauchwerger writes >> >> My image manipluation software uses fixed-point math for matrix >> math. However, in my PowerPC port, I am getting hardly no >> performance boost (seems slower to me) when I hit the matrix >> calcuations. > >For emulated code, the cost of doing a mixed mode switch to native mode >outweighs the benefit of faster native mode execution. (Especially since the >emualtor is going to be executing native multiply instructions anyway at the >bottom level.) Is fixed-point still going to be faster on the PowerPC than floating- point? It may not, since the PPC's floating-point unit is so much faster than (say) the MC6888x's. If someone could come up with some hard figures for this, it'd be handy. Zalman? Anyone? (I *think* I remember hearing that for most things - like, anything more complex than loop counting and such - floating-point is going to be faster on the PPC than integer math. Am I right, or hallucinating again?) - ------------------------------------------------------------------- Christopher Tate | "Blue ice cubes? How degenerate!" MSD, Inc. | fixer@faxcsl.dcrt.nih.gov | < anybody recognize the source? > +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Wed, 06 Apr 1994 18:24:34 -0700 Organization: Internet for the Olympic Peninsula In article <1994Apr6.234617.11486@alw.nih.gov>, fixer@faxcsl.dcrt.nih.gov (Chris Gonna' Find Ray Charles Tate) wrote: > Is fixed-point still going to be faster on the PowerPC than floating- > point? It may not, since the PPC's floating-point unit is so much > faster than (say) the MC6888x's. If someone could come up with some > hard figures for this, it'd be handy. Zalman? Anyone? > > (I *think* I remember hearing that for most things - like, anything > more complex than loop counting and such - floating-point is going to > be faster on the PPC than integer math. Am I right, or hallucinating > again?) It seems to me that working out the details is going to be tough, and variable over time. I *suspect* that switching *some* operations to floating point will speed things up, just because the processor can do more things at once that way. IF you're looking at code which has had instruction scheduling applied to it, and IF the compiler you are using does a good job of that (that's the part likely to vary over time). Bottom line: beware the quick and dirty "benchmark" in this area. For now, write your code in the most convenient (for writing/understanding/maintenance) way. [There was a flap a while back about one of the compilers not strength-reducing loops over arrays from multiplies to adds. My particular quick and dirty "benchmark" (not to be trusted) suggested that on PPC it makes no difference (so why should the compiler bother, except to avoid folks complaining about "poor optimization").] -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From johnmce@world.std.com (John McEnerney) Date: Thu, 7 Apr 1994 16:35:02 GMT Organization: The World Public Access UNIX, Brookline, MA [There was a flap a while back about one of the compilers not strength-reducing loops over arrays from multiplies to adds. My particular quick and dirty "benchmark" (not to be trusted) suggested that on PPC it makes no difference (so why should the compiler bother, except to avoid folks complaining about "poor optimization").] Floating-point adds take about the same time as multiplies (1 more cycle unless it is single-precision). Integer adds are -considerably- quicker than integer multiples: 1 cycle vs. 5 or 9. > Is fixed-point still going to be faster on the PowerPC than floating- > point? Again, it depends on the distribution of the operations. Integer multiplies and divides are -way- slower than floating-point. Adds/subs are -way- faster. For any compiler that does instruction scheduling, you'll probably get better results using floating-point, because the floating-point arithmetic can operate in parallel with the integer instructions used for loops, branches, etc. -- John +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 8 Apr 94 01:19:50 MST Organization: (none) In article <2nv95q$5at@romulus.ucs.uoknor.edu>, Willie Rauchwerger writes: > My image manipluation software uses fixed-point math for matrix > math. However, in my PowerPC port, I am getting hardly no > performance boost (seems slower to me) when I hit the matrix > calcuations. > > After running TrapsCheck (very cool stuff), I find that the Fixed > point math routines are not native. Ugh. > > After deciding not to do floating point because of speed, finding > that Fixed-point calculations are slower now is not too funny. > I would like to keep it using fixed point so that I can get good > performance regardless of processor. > > Any ideas aobut how to get around this? Any ideas when the Fixed > point routines will be native? > > Any separate libraries to do fixed point calculations? > > ------------------------------------------------------------------- > Willie Rauchwerger AppleLink: Willie > Telemedicine Software Guy Internet: willie-rauchwerger@uokhsc.edu > OU Health Sciences Center Since you are claiming a need for critical speed, I wonder why you bother with the overhead of the Fixed-Point trap on the 68K side anyways? Rolling your own 68k fixedpoint routines will save you 100+ CPU cycles for every fixed-point call as that is the overhead of the trap dispatcher. As I understand it, there is no trap dispatcher on the PowerMac: the emulator does it automatically. However, that don't mean that you should be happy with the result either way. Having read this thread backwards, I note that the PowerMac doesn't do native fixed point due to the overhead from the Mixed Mode manager. Why not roll your own routines for both 68K and PowerMac and use each as it is appropriate, thereby avoiding the trap dispatcher on the 68k Macs and the emulator overhead on the PowerMacs? Lawson +++++++++++++++++++++++++++ >From d88-jwa@hemul.nada.kth.se (Jon Wätte) Date: 8 Apr 1994 09:58:42 GMT Organization: The Royal Institute of Technology >fixed point due to the overhead from the Mixed Mode manager. Why not roll your >own routines for both 68K and PowerMac and use each as it is appropriate, >thereby avoiding the trap dispatcher on the 68k Macs and the emulator overhead >on the PowerMacs? Why not define macros for your data representation and manipulation, and have it use single-precision floats on the PPC and fixeds on 68K? That way, you get the superior math performance on the PPC (where float multiplies/divides are faster than integer) and keep the speed on the 68K. And, yes, implementing your own fixed math macros is pretty much a must. -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe -- This article printed on 100% recycled electrons. +++++++++++++++++++++++++++ >From Willie Rauchwerger Date: 8 Apr 1994 14:42:46 GMT Organization: OU Health Sciences Center In article <2o39si$673@news.kth.se> Jon W!tte, d88-jwa@hemul.nada.kth.se writes: >Why not define macros for your data representation and manipulation, >and have it use single-precision floats on the PPC and fixeds on 68K? >That way, you get the superior math performance on the PPC (where >float multiplies/divides are faster than integer) and keep the speed >on the 68K. And, yes, implementing your own fixed math macros is >pretty much a must. OK. It is obvious to me that I need to roll my own fixed point routines. My question is whether there are any out there right now that people have used to get around the trap overhead, or do I really need to roll my own. (I think I can handle most of it, but I worry about it being entirrly correct, and those trig functions...) My next question is, how can floating point be faster than integer math on the PowerPC (or any processor for that matter)? It would seem to me that no matter how fast fp is, integer should faster - otherwise, should I start using fp for counters, etc. :-) - ----------------------------------------------------------------- Willie Rauchwerger AppleLink: Willie Telemedicine Software Guy Internet: willie-rauchwerger@uokhsc.edu OU Health Sciences Center +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 8 Apr 1994 15:40:13 GMT Organization: The Royal Institute of Technology In <2o3qh6$b2c@romulus.ucs.uoknor.edu> Willie Rauchwerger writes: >My next question is, how can floating point be faster than integer >math on the PowerPC (or any processor for that matter)? It would >seem to me that no matter how fast fp is, integer should faster - >otherwise, should I start using fp for counters, etc. :-) The integer unit is not designed the same as the floating-point unit, and the FP unit kicks some serious butt. The only thing preventing you from using floating point registers for counters is that you can't index using floating-point registers, and the conversion to integer is slow. Else, go ahead! (addition and subtraction of course aren't faster in FP, but multiply and divide are) Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe -- "If people bought cars according to the same principles they buy computers, cars would behave like Lamborghinis but would be built and look like Yugos." -- Craig Fields +++++++++++++++++++++++++++ >From rmcassid@uci.edu (Robert Cassidy) Date: Fri, 08 Apr 1994 09:45:15 -0700 Organization: TLG Project In article <2o3tst$99f@news.kth.se>, d88-jwa@dront.nada.kth.se (Jon Wtte) wrote: > In <2o3qh6$b2c@romulus.ucs.uoknor.edu> Willie Rauchwerger writes: > > >My next question is, how can floating point be faster than integer > >math on the PowerPC (or any processor for that matter)? It would > >seem to me that no matter how fast fp is, integer should faster - > >otherwise, should I start using fp for counters, etc. :-) > > The integer unit is not designed the same as the floating-point > unit, and the FP unit kicks some serious butt. > > The only thing preventing you from using floating point registers > for counters is that you can't index using floating-point registers, > and the conversion to integer is slow. Else, go ahead! (addition > and subtraction of course aren't faster in FP, but multiply and > divide are) Doesn't the integer unit handle all of the register loading as well? Wouldn't that be even more incentive to use the fp unit in certain instances? -- Robert Cassidy TLG Project UC Irvine Let's hope 'Information SuperTollroad' isn't the catchphrase of the next decade... +++++++++++++++++++++++++++ >From cforden@netcom.com (Chris Forden) Date: Fri, 8 Apr 1994 16:57:41 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Excerpted from my upcoming article in the May issue of MacTech-- Clever programmers of 68K Macs have done the fastest calculations with integer arithmetic. For instance, the calculation of screen position of 2D CAD objects can be done quickest using the long (32 bit) integer arithmetic available on the 68020 and better. (The FixMath routines in those machinesÕs ROM automatically make use of the extended instructions.) Some programmers were even willing to put up the aggravation of doing all the worst-case analyses of overflow and underflow needed to use fixed-point math routines reliably. However, on the PowerPC, the floating point performance is so much improved that now one gets faster execution by using floating point routines than by using fixed point arithmetic in any case where precautions would need to be taken against overflow error or precision loss due to underflow. Those two enemies of integer arithmeticÐ overflow and underflowÐ ravage more fixed point math schemes than programmers expect a priori. Therefore calculating with floating point is generally much easier than adapting fixed-point arithmetic to oneÕs needs. So how much faster is floating point? A friend of mine timed various implementations of an FFT-based image processing algorithm running on several Mac platforms. Here are his results tabularized, including single precision floating point, for a one-way 512 x 512 FFT: IIci w/cache Power Mac proto ------------ --------------- integer 52 sec 14.5 sec single float 80 sec 3 sec Integer arithmetic on the Power Mac prototype was about the same as the Quadra 840avÕs, but single precision float on the Power Mac was 4.5 times faster than the faster (integer with special long mul assembly) arithmetic on Q840av. We were using a bottom-of-the-line Power Mac prototype, running at only 50 MHz. Double-precision floating point on the PowerPC is only 0% to 20% slower than single-precision floating point. The 64 bits of the double-precision format mean you have great freedom from precision loss. The PowerPC also has a multiply-and-add instruction, often called Òmultiply and accumulateÓ. It combines a multiplication and an addition into a single instruction. Many signal processing programs for audio or images can make heavy use of that instruction, which optimizing -- cforden@netcom.com 's self-referential signature quote: "Huh?" +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 9 Apr 94 16:30:50 MST Organization: (none) In article <2o3qh6$b2c@romulus.ucs.uoknor.edu>, Willie Rauchwerger writes: > In article <2o39si$673@news.kth.se> Jon W!tte, d88-jwa@hemul.nada.kth.se > writes: >>Why not define macros for your data representation and manipulation, >>and have it use single-precision floats on the PPC and fixeds on 68K? >>That way, you get the superior math performance on the PPC (where >>float multiplies/divides are faster than integer) and keep the speed >>on the 68K. And, yes, implementing your own fixed math macros is >>pretty much a must. > > OK. It is obvious to me that I need to roll my own fixed point routines. > My question is whether there are any out there right now that people > have used to get around the trap overhead, or do I really need to roll > my own. (I think I can handle most of it, but I worry about it being > entirrly correct, and those trig functions...) > > My next question is, how can floating point be faster than integer > math on the PowerPC (or any processor for that matter)? It would > seem to me that no matter how fast fp is, integer should faster - > otherwise, should I start using fp for counters, etc. :-) > FP adds and subtracts are every bit as fast as fixed point adds and subtracts. In fact, I understand that it is possible to get extra speed out of the 601 by using fp indexes in loops... Lawson +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Thu, 14 Apr 1994 01:14:02 -0700 Organization: Internet for the Olympic Peninsula In article <2nv95q$5at@romulus.ucs.uoknor.edu>, Willie Rauchwerger wrote: > After deciding not to do floating point because of speed... A preconception which has long been true, on a wide variety of hardware. But...you may well find that using float (the 4-byte form) on PPC is the right way to go. Run your time trials on your program built that way (and let us know how they come out). [Enabling the Instruction Scheduling optimization could well be important here. If you're using a compiler which does it well or even semi-well.] -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From Dave Falkenburg Date: Fri, 15 Apr 1994 16:30:31 GMT Organization: Apple Computer, Inc. In article <1994Apr8.011950.1@west.cscwc.pima.edu> , 103t_english@west.cscwc.pima.edu writes: >Having read this thread backwards, I note that the PowerMac doesn't do native >fixed point due to the overhead from the Mixed Mode manager. Why not roll your >own routines for both 68K and PowerMac and use each as it is appropriate, >thereby avoiding the trap dispatcher on the 68k Macs and the emulator overhead >on the PowerMacs? Many of the FixMath routines are "split" traps, which do not support patching anymore. On PowerPC, they are implemented inside InterfaceLib directly, and are not called through the trap dispatcher... -Dave Falkenburg -Apple Computer, Inc. +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 17 Apr 94 08:09:19 MST Organization: (none) In article <1994Apr15.163031.5662@gallant.apple.com>, Dave Falkenburg writes: > In article <1994Apr8.011950.1@west.cscwc.pima.edu> , > 103t_english@west.cscwc.pima.edu writes: >>Having read this thread backwards, I note that the PowerMac doesn't do > native >>fixed point due to the overhead from the Mixed Mode manager. Why not > roll your >>own routines for both 68K and PowerMac and use each as it is appropriate, >>thereby avoiding the trap dispatcher on the 68k Macs and the emulator > overhead >>on the PowerMacs? > > Many of the FixMath routines are "split" traps, which do not support > patching > anymore. On PowerPC, they are implemented inside InterfaceLib directly, > and > are not called through the trap dispatcher... > > -Dave Falkenburg > -Apple Computer, Inc. I take it that they are "native" then? Lawson --------------------------- >From rrose@CSOS.ORST.EDU (-= Godfather Moof =-) Subject: Keeping DialogPtr's in RAM after startup... Date: 13 Apr 1994 23:44:59 GMT Organization: CS Outreach Services, Oregon State University, Corvallis, OR, USA I'm writing an INIT that I would like to load a DialogPtr into ram at startup so that the trap macro I am patching can use it later. So far I've tryed converting the ptr to a handle and locking the handle, but without success. I've tryed just opening up the file the Dialog Box is located in, but that's to much of a hassle in case the dialog resource gets deleted, (which it might). Can anyone help? /-/ Dogcow lives... ___/ /__ /__ ___/ Godfather Moof: | / /| | rrose@csos.orst.edu |/_/ | | | | | | He'll make you an offer you can't refuse. | | | | +++++++++++++++++++++++++++ >From zobkiw@datawatch.com (joe zobkiw) Date: Thu, 14 Apr 1994 20:41:09 GMT Organization: Datawatch Corporation In article <2oi05r$jco@jadzia.CSOS.ORST.EDU>, rrose@CSOS.ORST.EDU (-= Godfather Moof =-) wrote: > I'm writing an INIT that I would like to load a DialogPtr into ram at > startup so that the trap macro I am patching can use it later. So far > I've tryed converting the ptr to a handle and locking the handle, but without > success. I've tryed just opening up the file the Dialog Box is located in, > but that's to much of a hassle in case the dialog resource gets deleted, > (which it might). > Forget abou it. Simply (at INIT time) call the following routine (passing CurResFile() as the refNum) to learn where your INIT is. Then, in your patch, when you need access to your resources, simply open the INIT file and use the resources. Don't forget to close it when you are done. OSErr FindFileSpec(short refNum, short *foundVRefNum, long *foundDirID, unsigned char *fileName) { FCBPBRec pb; OSErr err = noErr; pb.ioCompletion = NULL; pb.ioNamePtr = fileName; pb.ioVRefNum = 0; pb.ioRefNum = refNum; pb.ioFCBIndx = 0; err = PBGetFCBInfoSync(&pb); *foundVRefNum = pb.ioFCBVRefNum; *foundDirID = pb.ioFCBParID; return err; } ___________________________________________________________ _/_/_/_/ Joe Zobkiw ,,, _/ Senior Software Engineer - - _/ Datawatch Corporation L _/_/_/_/ zobkiw@datawatch.com - +++++++++++++++++++++++++++ >From petm@soda.berkeley.edu (Peter Mattis) Date: 16 Apr 1994 23:29:00 GMT Organization: Computer Science Undergrad Assoc., UCBerkeley In article , joe zobkiw wrote: >In article <2oi05r$jco@jadzia.CSOS.ORST.EDU>, rrose@CSOS.ORST.EDU (-= >Godfather Moof =-) wrote: > >> I'm writing an INIT that I would like to load a DialogPtr into ram at >> startup so that the trap macro I am patching can use it later. So far >> I've tryed converting the ptr to a handle and locking the handle, but without >> success. I've tryed just opening up the file the Dialog Box is located in, >> but that's to much of a hassle in case the dialog resource gets deleted, >> (which it might). >> > >Forget abou it. Simply (at INIT time) call the following routine (passing >CurResFile() as the refNum) to learn where your INIT is. Then, in your >patch, when you need access to your resources, simply open the INIT file >and use the resources. Don't forget to close it when you are done. [SNIP] Yes, but what happens if the user moves the init file? (Hmm...bit of a problem, isn't it?) The method I used for displaying a dialog box in the manner you describe is to get the handle to the 'DITL' (dialog items list) resource at start time. Remember to call DetachResource and HLock the handle. This handle can then be used in a call to NewDialog to create a dialog with the your items in it. Be careful and make sure the item list doesn't get deleted somewhere along the line. -Peter Mattis +++++++++++++++++++++++++++ >From ari@world.std.com (Ari I Halberstadt) Date: Sun, 17 Apr 1994 03:22:03 GMT Organization: The World Public Access UNIX, Brookline, MA In article <2opsbs$jed@agate.berkeley.edu>, Peter Mattis wrote: > >The method I used for displaying a dialog box in the manner you >describe is to get the handle to the 'DITL' (dialog items list) resource >at start time. Remember to call DetachResource and HLock the handle. >This handle can then be used in a call to NewDialog to create a dialog >with the your items in it. > >Be careful and make sure the item list doesn't get deleted somewhere >along the line. You would also have to ensure that the dialog only accesses resources from the system file. For instance, you couldn't specify a popup control using 'CNTL' and 'MENU' resources. You could write code to create the popup menu on the fly, or you could write code to create the control and menu by saving copies of the resources, and then attach the popup to the dialog. It's easier, as suggested in a prior post, just to open the extension's resource file before creating the dialog. I don't think it's too unreasonable to expect an extension to be able to find its own file or some preferences file. If the user goes and moves the file, a simple alert (or notification manager alert) could issue a gentle admonishment. -- Ari Halberstadt ari@world.std.com #include "These beetles were long considered to be very rare because very few entomologists look for beetles in the mountains, in winter, at night, during snow storms." -- Purves W. K., et al, "Life: The Science of --------------------------- >From Robert Hess Subject: Metrowerks News from MacWEEK Date: Sat, 9 Apr 1994 02:35:44 GMT Organization: MacWEEK As a service, here are some snippets from Monday!s MacWEEK. I'll try to do this in the future when there's developer-related news but it will be as time permits... St. Laurent, Quebec -- Metrowerks Inc., the developer community's bold new kid on the block, has received a big boost from a formidable ally, IBM Corp., and will announce several major additions to its CodeWarrior product this week. Metrowerks has formed an agreement with IBM which gives Metrowerks access to Big Blue's compiler optimization technology for current and future PowerPC processors. As a result, Mac developers will have access to the best PowerPC code generators available, said Jean Belanger, Metrowerks' chairman. "In addition to having the fastest compiler, we'll be able to generate the fastest code," he said. At Apple's Worldwide Developers Conference next month Metrowerks will ship: MPW MW CW: Metrowerks will make its native and 680x0 compilers available to users of Apple's Macintosh Programmer's Workshop. The combination will bring CodeWarrior's speed and MPW's large project- and team-management tools together. Native-hosted 68K codegen: Metrowerks President and CEO Greg Galanos said, "The new compiler is four to five times as fast as our 680x0-based compiler and eight times as fast as Think." Metrowerks will ship its 680x0 and PowerPC compilers as fat binaries, so both can run and generate code for either processor line. The MPW-hosted compiler will be included free. Since developers feel Apple has not committed to continue supporting the language, Metrowerks will introduce an Object Pascal version of its compiler by year-end. Metrowerks is now bundling CodeWarrior with NeoLogic Systems' NeoPersist, an object-oriented data storage utility for programmers. An encrypted copy of NeoAccess, an object-oriented database extension of NeoPersist, is also included; users can upgrade for $649. Metrowerks plans to open its first U.S. office in Austin, Texas, June 1. The Austin office will be the headquarters of the technical support, quality assurance and sales divisions. [For the full text, see MacWEEK or ZiffNet on CompuServe, eWorld or AppleLink] ======================================================================== Robert Hess, WEEKgeek robert_hess@macweek.ziff.com MacWEEK AppleLink: WNDZSX 301 Howard CompuServe: 72511,333 San Francisco, Calif. 94105 America Online: MacWEEK (415) 243-3576 days MCI: RHESS (415) 243-3651 fax (415) 647-5549 nights I speak for myself. now doesn!t that make you feel better? And sometimes not even that. ======================================================================== +++++++++++++++++++++++++++ >From gewekean@studentg.msu.edu (Andrew Geweke) Date: Sat, 9 Apr 1994 01:08:09 -0400 Organization: Michigan State University In article , Robert Hess writes: > As a service, here are some snippets from Monday!s MacWEEK. I'll try to > do this in the future when there's developer-related news but it will > be as time permits... Thank you very much for this! There are obviously lots of people who still can't really get MacWEEK. > St. Laurent, Quebec -- Metrowerks Inc., the developer community's bold > new kid on the block, has received a big boost from a formidable ally, > IBM Corp., and will announce several major additions to its CodeWarrior > product this week. > > Metrowerks has formed an agreement with IBM which gives Metrowerks > access to Big Blue's compiler optimization technology for current and > future PowerPC processors. As a result, Mac developers will have access > to the best PowerPC code generators available, said Jean Belanger, > Metrowerks' chairman. "In addition to having the fastest compiler, we' > ll be able to generate the fastest code," he said. Am I the only one saying Wow? I've heard only huge rave reviews about IBM's compilers, but figured they were only available with the Macintosh on RISC SDK. Great! +++++++++++++++++++++++++++ >From sw@network-analysis-ltd.co.uk (Sak Wathanasin) Date: Sat, 9 Apr 94 09:34:08 GMT Organization: Network Analysis Ltd In article (comp.sys.mac.programmer), Robert Hess writes: > Metrowerks will ship its 680x0 and PowerPC compilers as fat binaries, so > both can run and generate code for either processor line. The MPW-hosted > compiler will be included free. Will this apply retrospectively to those of us who bought DR1 (2,3..)? Or do I have to buy the MPW-hosted compiler separately? If the latter, where do I get it from? Sak Wathanasin Network Analysis Limited 178 Wainbody Ave South, Coventry CV3 6BX, UK Internet: sw@network-analysis-ltd.co.uk uucp: ...!uknet!nan!sw AppleLink: NAN.LTD Phone: (+44) 203 419996 Mobile:(+44) 850 587411 Fax: (+44) 203 690690 +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Sat, 9 Apr 1994 08:41:27 GMT Organization: Adobe Systems Incorporated Andrew Geweke writes > Am I the only one saying Wow? I've heard only huge rave reviews about IBM's > compilers, but figured they were only available with the Macintosh on RISC > SDK. Great! IBM's compilers are *not* on the Macintosh on RISC SDK. They are only available for IBM's AIX operating system. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 "Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins) +++++++++++++++++++++++++++ >From johnmce@world.std.com (John McEnerney) Date: Sat, 9 Apr 1994 09:03:06 GMT Organization: The World Public Access UNIX, Brookline, MA > Metrowerks has formed an agreement with IBM which gives Metrowerks > access to Big Blue's compiler optimization technology for current and > future PowerPC processors. As a result, Mac developers will have access > to the best PowerPC code generators available, said Jean Belanger, > Metrowerks' chairman. "In addition to having the fastest compiler, we' > ll be able to generate the fastest code," he said. So that the rumours don't fly to far too fast on this one, let me clarify the situation as it will affect you, the users. We have an agreement which says that as I develop the next version of our PowerPC code generator, I'm free to ask for advice, experiences, etc. from some of the guys at IBM's Watson Research Center where the POWER architecture was originally designed. It turns out much of my current code generator design is already based on some papers that they wrote at Watson anyway. They are willing to be pretty free with their experience, but I imagine they will also keep some tricks to themselves. No source code is involved, at least not to my knowledge. The important point is that Metrowerks is going to invest pretty much 100% of my time developing aggressive global optimization for future versions of our product. How closely we compare with IBMs xlc compilers depends mostly on how good a job I do at that. Our agreement with IBM is an offshoot of a relationship we have with some great guys in IBM Microelectronics, who want to see the PowerPC chip succeed and see Apple's broad market penetration with a low-cost desktop PowerPC as crucial to their success. By the way, although IBM seems to have a real stuffed-shirt image, Watson Research seems like a cool place. People there look just like us! Also, it was cool to sit in the office of a guy who wrote probably the first paper on Common Subexpression Elimination in a compiler. In my early years at Symantec we always wrestled with the "THINK for fast compiles, MPW for production code" image, one that Apple liked to propagate, until we got serious in v5.0 and wrote a real code generator. I don't want Metrowerks to be pigeonholed like that. For DR3 and probably DR4, we will be the "fast" compiler which makes some concessions in the optimization area. (This has not stopped a large number of commercial developers of well-known products from using CodeWarrior to "go native") After that, we intend to generate code as good as anybody else's. -- John McEnerney, Metrowerks PowerPC Product Architect +++++++++++++++++++++++++++ >From d88-jwa@hemul.nada.kth.se (Jon Wätte) Date: 9 Apr 1994 12:30:13 GMT Organization: The Royal Institute of Technology In <9404090108.AA09272@geweke.ppp.msu.edu> gewekean@studentg.msu.edu (Andrew Geweke) writes: >Am I the only one saying Wow? I've heard only huge rave reviews about IBM's >compilers, but figured they were only available with the Macintosh on RISC >SDK. Great! Nope, the Macintosh on RISC SDK uses the Lucid compiler, PPCC. To use xlc, you have to have an IBM RS/6000 with the development environment, figure on spending $15000 and upwards... -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe -- Clearly, most humans are not rational beings; they are rationalizing beings. -- Mel Walker +++++++++++++++++++++++++++ >From johnmce@world.std.com (John McEnerney) Date: Sun, 10 Apr 1994 04:24:59 GMT Organization: The World Public Access UNIX, Brookline, MA sw@network-analysis-ltd.co.uk (Sak Wathanasin) writes: >> Metrowerks will ship its 680x0 and PowerPC compilers as fat binaries, so >> both can run and generate code for either processor line. The MPW-hosted >> compiler will be included free. >Will this apply retrospectively to those of us who bought DR1 (2,3..)? >Or do I have to buy the MPW-hosted compiler separately? If the latter, where >do I get it from? We'll just tack these onto the CD for DR3, DR4, etc. You'll ghet them automatically (as long as you regstered!) -- John McEnerney, Metrowerks PowerPC Product Architect +++++++++++++++++++++++++++ >From sw@network-analysis-ltd.co.uk (Sak Wathanasin) Date: Mon, 11 Apr 94 00:24:40 GMT Organization: Network Analysis Ltd In article (comp.sys.mac.programmer), johnmce@world.std.com (John McEnerney) writes: > >Will this apply retrospectively to those of us who bought DR1 (2,3..)? > >Or do I have to buy the MPW-hosted compiler separately? If the latter, where > >do I get it from? > > We'll just tack these onto the CD for DR3, DR4, etc. You'll ghet them > automatically (as long as you regstered!) Do we have to wait for DR3 for the MPW-hosted compiler? I thought the press release said that it would be released at the WWDC. I'd be happy to buy a separate copy of the MPW-hosted compiler if it were available... Sak Wathanasin Network Analysis Limited 178 Wainbody Ave South, Coventry CV3 6BX, UK Internet: sw@network-analysis-ltd.co.uk uucp: ...!uknet!nan!sw AppleLink: NAN.LTD Phone: (+44) 203 419996 Mobile:(+44) 850 587411 Fax: (+44) 203 690690 +++++++++++++++++++++++++++ >From johnmce@world.std.com (John McEnerney) Date: Mon, 11 Apr 1994 07:03:19 GMT Organization: The World Public Access UNIX, Brookline, MA >Do we have to wait for DR3 for the MPW-hosted compiler? I thought the press >release said that it would be released at the WWDC. I'd be happy to buy a >separate copy of the MPW-hosted compiler if it were available... DR3 is the version which we will be shipping at the WWDC! Of course, since we will probably get it in the mail just as we ourselves are leaving for WWDC, you might not get yours until after the WWDC depending on shipping time etc. -- John McEnerney, Metrowerks PowerPC Product Architect +++++++++++++++++++++++++++ >From Robert Hess Date: Mon, 11 Apr 1994 16:44:35 GMT Organization: MacWEEK In article <9404090108.AA09272@geweke.ppp.msu.edu> Andrew Geweke, gewekean@studentg.msu.edu writes: >Thank you very much for this! There are obviously lots of people who still >can't really get MacWEEK. Well, keep in mind: a) My employer won't let me post the full article; b) This is going be as time permits. So you're still better off getting the full scoop via MacWEEK or online. ======================================================================== Robert Hess, WEEKgeek robert_hess@macweek.ziff.com MacWEEK AppleLink: WNDZSX 301 Howard CompuServe: 72511,333 San Francisco, Calif. 94105 America Online: MacWEEK (415) 243-3576 days MCI: RHESS (415) 243-3651 fax (415) 647-5549 nights I speak for myself. now doesn!t that make you feel better? And sometimes not even that. ======================================================================== +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Sun, 10 Apr 1994 12:27:59 +0800 Organization: NCRPDA, Curtin University >Since developers feel Apple has not committed to continue supporting the >language, Metrowerks will introduce an Object Pascal version of its >compiler by year-end. And there was much rejoicing! Now, what was the upgrade strategy for this? If the upgrade from Pascal to Object Pascel is sufficiently cheap, then I'd love to buy a copy now and help get the bugs out! Peter. _______________________________________________________________________ Peter N Lewis Ph: +61 9 368 2055 +++++++++++++++++++++++++++ >From gurgle@netcom.com (Pete Gontier) Date: Sun, 17 Apr 1994 04:22:07 GMT Organization: cellular peter.lewis@info.curtin.edu.au (Peter N Lewis) writes: >>Since developers feel Apple has not committed to continue supporting the >>language, Metrowerks will introduce an Object Pascal version of its >>compiler by year-end. >And there was much rejoicing! Now, what was the upgrade strategy for >this? If the upgrade from Pascal to Object Pascel is sufficiently cheap, >then I'd love to buy a copy now and help get the bugs out! Since the license for DR2 includes updates through DR5 or so, and since DR5 isn't supposed to ship this year, and since Object Pascal *is* supposed to ship this year, my guess is that buying CodeWarrior now is sufficient. Metrowerks may not have thought along this precise path, so when you call them to confirm, mention it. -- Pete Gontier, CTO, Integer Poet Software; gurgle@netcom.com +++++++++++++++++++++++++++ >From mwron@aol.com (MW Ron) Date: 17 Apr 1994 16:24:02 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , gurgle@netcom.com (Pete Gontier) writes: >> Since the license for DR2 includes updates through DR5 or so, and since DR5 isn't supposed to ship this year, and since Object Pascal *is* supposed to ship this year, my guess is that buying CodeWarrior now is sufficient. Right, Every CD will include the latest compiler versions available. With more source codes and 3rd party demos and tools. If you purchase the DR\2 pre-release version you will receive DR\3. DR\4, DR\5 as well, these CD's will come out every 4 months. The only upgrading necessary could be from a Bronze to a Gold if you needed to write for a PowerPC later on. Ron Liechty mwron@aol.com Metrowerks Inc. --------------------------- >From greer@utdallas.edu (Dale M. Greer) Subject: WaitNextEvent Emulated on PoMac!? Date: 11 Apr 1994 15:50:35 GMT Organization: The University of Texas at Dallas Someone on the CodeWarrior mailing list said that WaitNextEvent runs in emulation mode on the Power Macintosh. This was in response to a programmer frustrated by jerky animation on the Power Mac. It was recommended that he put code to call WaitNextEvent after some number of passes through the event loop, say every tenth pass. It seems like WaitNextEvent would be one of the most frequently used routines by most applications, so why didn't Apple make it native? Will it be native for System 7.5? -- Dale Greer, greer@utdallas.edu +++++++++++++++++++++++++++ >From fixer@faxcsl.dcrt.nih.gov (Chris Gonna' Find Ray Charles Tate) Date: Mon, 11 Apr 1994 16:34:10 GMT Organization: DCRT, NIH, Bethesda, MD In article <2obrkb$2i8@news.utdallas.edu>, greer@utdallas.edu (Dale M. Greer) writes: > >Someone on the CodeWarrior mailing list said that WaitNextEvent runs >in emulation mode on the Power Macintosh. This was in response to >a programmer frustrated by jerky animation on the Power Mac. It was >recommended that he put code to call WaitNextEvent after some number of >passes through the event loop, say every tenth pass. > >It seems like WaitNextEvent would be one of the most frequently used >routines by most applications, so why didn't Apple make it native? Will >it be native for System 7.5? I expect it's *because* it's one of the most-called routines. If it were native, then *every time* an emulated application called it would entail at least two mode switches (into native to run the trap, then back out again to run the application). Mode switching is expensive. Now, it *could* be that the trap is run native when you're running in native mode, but emulated when you're running under the emulator; it seems to me this would be optimal. Does anyone know whether this is indeed the case under the current PowerMac system software? - ------------------------------------------------------------------- Christopher Tate | "Blue ice cubes? How degenerate!" MSD, Inc. | fixer@faxcsl.dcrt.nih.gov | < anybody recognize the source? > +++++++++++++++++++++++++++ >From Erik Schwiebert Date: 11 Apr 1994 18:12:43 GMT Organization: Cornell University In article <1994Apr11.163410.6724@alw.nih.gov> Chris Gonna' Find Ray Charles Tate, fixer@faxcsl.dcrt.nih.gov writes: >In article <2obrkb$2i8@news.utdallas.edu>, greer@utdallas.edu (Dale M. Greer) writes: >> >>Someone on the CodeWarrior mailing list said that WaitNextEvent runs >>in emulation mode on the Power Macintosh. This was in response to >>a programmer frustrated by jerky animation on the Power Mac. It was >>recommended that he put code to call WaitNextEvent after some number of >>passes through the event loop, say every tenth pass. >> >>It seems like WaitNextEvent would be one of the most frequently used >>routines by most applications, so why didn't Apple make it native? Will >>it be native for System 7.5? > >I expect it's *because* it's one of the most-called routines. If it were >native, then *every time* an emulated application called it would entail >at least two mode switches (into native to run the trap, then back out >again to run the application). Mode switching is expensive. > >Now, it *could* be that the trap is run native when you're running in >native mode, but emulated when you're running under the emulator; it seems >to me this would be optimal. Does anyone know whether this is indeed the >case under the current PowerMac system software? well, according to the example in New Inside Mac: PowerPC Software (or whatever the title is), Apple gives an example that shows exactly what Dale Greer said. ie, the code only calls WNE every once in a while. I dont have the book, but it looked something like this: procedure mainloop; var theEvent:eventRecord; begin if (tickCount - gTimeOfLastCall) > gTimeToWait then begin gotEvent := waitNextEvent(blah, blah, blah ...) gTimeOfLastCall := tickCount; else gotEvent := false; if gotEvent then case whatever of whatever etc... end; anyways, you get the idea... where gTimeToWait is 10 ticks or something like that (getCaretTime maybe?) - ----------------------------------------------------------------- "So live that you can |------------------| "Life is a tragedy for look any man in the | evs1@cornell.edu | those who feel, and a eye and tell him |------------------| comedy for those who go to hell." | Erik V. | think." -- Anonymous | Schwiebert | -- Jean De La Bruyere - ----------------------------------------------------------------- +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Mon, 11 Apr 1994 11:01:28 -0700 Organization: Internet for the Olympic Peninsula In article <1994Apr11.163410.6724@alw.nih.gov>, fixer@faxcsl.dcrt.nih.gov (Chris Gonna' Find Ray Charles Tate) wrote: > In article <2obrkb$2i8@news.utdallas.edu>, greer@utdallas.edu (Dale M. Greer) writes: > > > >Someone on the CodeWarrior mailing list said that WaitNextEvent runs > >in emulation mode on the Power Macintosh. This was in response to > >a programmer frustrated by jerky animation on the Power Mac. It was > >recommended that he put code to call WaitNextEvent after some number of > >passes through the event loop, say every tenth pass. > > > > I expect it's *because* it's one of the most-called routines. If it were > native, then *every time* an emulated application called it would entail > at least two mode switches (into native to run the trap, then back out > again to run the application). Mode switching is expensive. > > Now, it *could* be that the trap is run native when you're running in > native mode, but emulated when you're running under the emulator; it seems > to me this would be optimal. Does anyone know whether this is indeed the > case under the current PowerMac system software? It is possible to create "fat" traps...run 68K or PPC. It was done for several traps which **are unlikely to be patched**. It's not clear that existing apps which patch traps can deal with the fat ones. Of course, no one ever patches WaitNextEvent, and everyone who does so does it "right", and will instantly retrofit "fat" patches. -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From sbarta@magnus.acs.ohio-state.edu (Scott Barta) Date: 11 Apr 1994 15:33:23 -0400 Organization: The Ohio State University > well, according to the example in New Inside Mac: PowerPC Software (or > whatever the title is), Apple gives an example that shows exactly what > Dale Greer said. ie, the code only calls WNE every once in a while. I > dont have the book, but it looked something like this: > [code deleted] > anyways, you get the idea... where gTimeToWait is 10 ticks or something > like that (getCaretTime maybe?) There's one big problem with all of this. While your application is burning up cycles waiting to do its next WNE, it's _not_ giving up cycles to other applications. Very unfriendly. I'm surprised that Apple is advocating this, unless they're thinking ahead to some happy day when applications will be able to preempt each other without WNE. I would think that you'd just want to call WNE as often as possible and grit your teeth through the mode switches until the needed Toolbox calls go native...shucks, your program may not be fully _debugged_ by then. :-) -- --Scott Barta --sbarta@magnus.acs.ohio-state.edu +++++++++++++++++++++++++++ >From b-clark@nwu.edu (Brian Clark) Date: Mon, 11 Apr 1994 16:33:16 -0500 Organization: Northwestern University In article <199404111933.PAA15286@bottom.magnus.acs.ohio-state.edu>, sbarta@magnus.acs.ohio-state.edu (Scott Barta) wrote: > There's one big problem with all of this. While your application is > burning up cycles waiting to do its next WNE, it's _not_ giving up cycles > to other applications. Very unfriendly. I'm surprised that Apple is > advocating this, unless they're thinking ahead to some happy day when > applications will be able to preempt each other without WNE. I would think > that you'd just want to call WNE as often as possible and grit your teeth > through the mode switches until the needed Toolbox calls go > native...shucks, your program may not be fully _debugged_ by then. :-) A recent develop had a question on this, I believe. Someone had a app that did a calculation, called WNE, did another calc, etc. When translated to native code, more time was being after yielding to other apps than to perform calculations. The suggestion was to call WNE less often, based on some fixed timing schedule, and not on how fast or slow a particular series of calculations took. This seems to be perfectly defensible. +++++++++++++++++++++++++++ >From ivanski@world.std.com (Ivan M CaveroBelaunde) Date: Mon, 11 Apr 1994 21:53:59 GMT Organization: The World Public Access UNIX, Brookline, MA Erik Schwiebert writes: >In article <1994Apr11.163410.6724@alw.nih.gov> Chris Gonna' Find Ray >Charles Tate, fixer@faxcsl.dcrt.nih.gov writes: >>In article <2obrkb$2i8@news.utdallas.edu>, greer@utdallas.edu (Dale M. >Greer) writes: >>>Someone on the CodeWarrior mailing list said that WaitNextEvent runs >>>in emulation mode on the Power Macintosh. This was in response to >>>a programmer frustrated by jerky animation on the Power Mac. It was >>>recommended that he put code to call WaitNextEvent after some number of >>>passes through the event loop, say every tenth pass. >well, according to the example in New Inside Mac: PowerPC Software (or >whatever the title is), Apple gives an example that shows exactly what >Dale Greer said. ie, the code only calls WNE every once in a while. I >dont have the book, but it looked something like this: >procedure mainloop; > var theEvent:eventRecord; >begin > if (tickCount - gTimeOfLastCall) > gTimeToWait then begin > gotEvent := waitNextEvent(blah, blah, blah ...) > gTimeOfLastCall := tickCount; > else > gotEvent := false; > if gotEvent then > case whatever of whatever > etc... >end; It's kind of nasty (since it hogs the machine while you do nothing, because gotEvent is hard-set to false if WNE is not called). A big problem, I see, is that GetOSEvent and OSEventAvail are emulated - a good alternative would have been to use those to process events while in the foreground (this makes your app hog the machine while it is in front, but it's processing user interactions, not sitting in an idle loop like the code above; of course, if you're not in the foreground you should relinqueish the CPU ASAP). I could easily see the rationale for WNE/GNE being emulated that the likelihood of a Mixed Mode Switch when doing the process swap is exceedingly high anyway (I think the device manager is still emulated, and WNE calls SystemTask). But hogging the machine AND not responding to user events strikes me as unnecessarily evil. I do hope the event handling (OS Event Mgr, Toolbox, Device Mgr) goes fat (not native, too many 68K emulated apps would suffer performance problems) in the next release - would go a long way towards easing that problem. -Ivan - - Ivan Cavero Belaunde (ivanski@world.std.com) Avid VideoShop Project Lead Avid Technology, Inc. +++++++++++++++++++++++++++ >From greer@utdallas.edu (Dale M. Greer) Date: 11 Apr 1994 22:24:03 GMT Organization: The University of Texas at Dallas Brian Clark (b-clark@nwu.edu) wrote: > In article <199404111933.PAA15286@bottom.magnus.acs.ohio-state.edu>, > sbarta@magnus.acs.ohio-state.edu (Scott Barta) wrote: > > There's one big problem with all of this. While your application is > > burning up cycles waiting to do its next WNE, it's _not_ giving up cycles > > to other applications. Very unfriendly. I'm surprised that Apple is > A recent develop had a question on this, I believe. Someone had a app that > did a calculation, called WNE, did another calc, etc. When translated to > native code, more time was being after yielding to other apps than to > perform calculations. The suggestion was to call WNE less often, based on > some fixed timing schedule, and not on how fast or slow a particular series > of calculations took. This seems to be perfectly defensible. Wouldn't it be nice if Apple had made a new GetMyPriority function, which would get a value from a new resource which would tell your code how many ticks to wait before calling WaitNextEvent. Of course, the success of this would depend on everyone using it, but if they did, then the user could set priorities for each application as easily as setting the memory requirements. Theoretically. ;) As an alternative to having the programmer provide the waiting logic, why couldn't Apple have made a little piece of code to call GetMyPriority, or something similar just before calling the emulated WaitNextEvent? This little piece of code could just return until its timer timed out, when it would then act like a regular call to WaitNextEvent. -- Dale Greer, greer@utdallas.edu +++++++++++++++++++++++++++ >From lsr@taligent.com (Larry Rosenstein) Date: Mon, 11 Apr 1994 22:46:20 GMT Organization: Taligent, Inc. In article <2obrkb$2i8@news.utdallas.edu>, greer@utdallas.edu (Dale M. Greer) wrote: > Someone on the CodeWarrior mailing list said that WaitNextEvent runs > in emulation mode on the Power Macintosh. This was in response to A good application will call WaitNextEvent with the appropriate sleep value, which means it doesn't get called as often as you'd think. > recommended that he put code to call WaitNextEvent after some number of > passes through the event loop, say every tenth pass. That might be appropriate for animation where you want to maintain control as much as possible. I don't think you'd want to do this based on number of passes, but rather based on elapsed time as someone suggested. -- Larry Rosenstein Taligent, Inc. lsr@taligent.com +++++++++++++++++++++++++++ >From leblonk@netcom.com (Marcel Blonk) Date: Tue, 12 Apr 1994 00:12:32 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Dale M. Greer (greer@utdallas.edu) wrote: : It seems like WaitNextEvent would be one of the most frequently used : routines by most applications, so why didn't Apple make it native? Will : it be native for System 7.5? Most time spent in WNE, as seen from an app, is actually spent in the other (background) apps that call WNE. Jerky animation and such, is caused by other apps taking up too much time in the background (read: calling WNE only every once in a while). The actual time spent in WNE itself is negligible, therefore I can understand that apple doesn't make it a priority to natify (from the verb 'to native') WNE (compare eg. the average app spends 70% of it's time in DrawText) mb +++++++++++++++++++++++++++ >From steeeve@aol.com (Steeeve) Date: 12 Apr 1994 03:12:27 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <2obrkb$2i8@news.utdallas.edu>, greer@utdallas.edu (Dale M. Greer) writes: >>>> Someone on the CodeWarrior mailing list said that WaitNextEvent runs in emulation mode on the Power Macintosh. <<<< I just finished up some code from which I expected to see a big speed gain on the Power Mac, but it turned out to be slower than on a Quadra 800. I was essentially doing this: do some calculations; fall through event loop; I realized that in this case the only reasonable event was a mouse click, so I changed it to while( ! Button() ) do some calculations; flush any other events; //so that the click is processed fall through event loop; Of course I probably should have done it like this in the first place, but on a 6100 it went from 190,000 calculations per hour to 1,475,000. -Steve +++++++++++++++++++++++++++ >From woody@alumni.caltech.edu (William Edward Woody) Date: 12 Apr 1994 07:44:53 GMT Organization: California Institute of Technology, Alumni Association In article <199404111933.PAA15286@bottom.magnus.acs.ohio-state.edu>, Scott Barta wrote: >> well, according to the example in New Inside Mac: PowerPC Software (or >> whatever the title is), Apple gives an example that shows exactly what >> Dale Greer said. ie, the code only calls WNE every once in a while. I >> dont have the book, but it looked something like this: >> > [code deleted] >> anyways, you get the idea... where gTimeToWait is 10 ticks or something >> like that (getCaretTime maybe?) > > >There's one big problem with all of this. While your application is >burning up cycles waiting to do its next WNE, it's _not_ giving up cycles >to other applications. Very unfriendly. I'm surprised that Apple is >advocating this, unless they're thinking ahead to some happy day when >applications will be able to preempt each other without WNE. I would think >that you'd just want to call WNE as often as possible and grit your teeth >through the mode switches until the needed Toolbox calls go >native...shucks, your program may not be fully _debugged_ by then. :-) Actually it turns out to be an extremely reasonable thing to do if you want your application to get as much of the CPU as possible while yielding in a way which feels very responsive to foreground applications. If you make gTimeToWait 15 ticks, then when the user starts typing in the foreground application he will be forced to wait no longer than 1/4 second before his application responds; for most applications users won't feel a significant delay in the responsiveness of the application. And since WNE won't return to the CPU-intensive application until there is a delay in events arriving at the foreground application (such as when the user pauses a second to think while typing in Microsoft Word), the foreground application will get all the CPU needed to respond to the user's typing or drawing. I've used this technique in quite a few applications and have been quite pleased at the amount of CPU my background CPU-intensive application gets, while still getting reasonable responsiveness in the foreground application. - Bill (Who isn't quite sure he understands why pre-emptive multi-tasking is so hot, given how unresponsive a Sun workstation feels compared to his less powerful Macintosh.) -- "A secret face--a touch of grace William Edward Woody A man must learn to give a little space woody@alumni.cco.caltech.edu A peaceful state--a submissive trait A man must learn to gently dominate" -- Rush, "Animate" +++++++++++++++++++++++++++ >From d88-jwa@mumrik.nada.kth.se (Jon Wätte) Date: 12 Apr 1994 08:44:59 GMT Organization: The Royal Institute of Technology In <2obrkb$2i8@news.utdallas.edu> greer@utdallas.edu (Dale M. Greer) writes: >It seems like WaitNextEvent would be one of the most frequently used >routines by most applications, so why didn't Apple make it native? Will >it be native for System 7.5? Wrong. WaitNextEvent isn't that important; when applications call it, they expect some time to pass (since other apps can get switched in during the call) The real power suckers were DrawText() and FillRect() (==EraseRect()) plus a couple of others (the memory manager in some cases :-) -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe -- This article printed on 100% recycled electrons. +++++++++++++++++++++++++++ >From neeri@iis.ee.ethz.ch (Matthias Neeracher) Date: 14 Apr 94 11:05:29 Organization: Integrated Systems Laboratory, ETH, Zurich In article , leblonk@netcom.com (Marcel Blonk) writes: > Dale M. Greer (greer@utdallas.edu) wrote: > : It seems like WaitNextEvent would be one of the most frequently used > : routines by most applications, so why didn't Apple make it native? Will > : it be native for System 7.5? > Most time spent in WNE, as seen from an app, is actually spent in the > other (background) apps that call WNE. This is true to a certain degree. However, excessive calling of WNE *while the application still has something to do* may slow down your code considerably. Matthias - --- Matthias Neeracher neeri@iis.ee.ethz.ch "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and weighs 30 tons, computers in the future may have only 1,000 vacuum tubes and weigh only 1 1/2 tons." ---Popular Mechanics, March 1949 +++++++++++++++++++++++++++ >From leblonk@netcom.com (Marcel Blonk) Date: Thu, 14 Apr 1994 19:05:26 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Matthias Neeracher (neeri@iis.ee.ethz.ch) wrote: : In article , leblonk@netcom.com (Marcel Blonk) writes: : > Dale M. Greer (greer@utdallas.edu) wrote: : > : It seems like WaitNextEvent would be one of the most frequently used : > : routines by most applications, so why didn't Apple make it native? Will : > : it be native for System 7.5? : > Most time spent in WNE, as seen from an app, is actually spent in the : > other (background) apps that call WNE. : This is true to a certain degree. However, excessive calling of WNE : *while the application still has something to do* may slow down your : code considerably. True, but the issue here is, that to make the WNE code native, wouldn't do much to improve performance. Not calling WNE too much has always been an issue on the mac, way before the PowerMac. mb +++++++++++++++++++++++++++ >From Jens Alfke Date: Mon, 18 Apr 1994 20:07:43 GMT Organization: Apple Computer On any reasonably fast Mac it's a bad idea to call WNE too often; not that the implentation itself is slow, but there are limitations in the OS on how fast process switches can happen, so when you call WNE you should expect to be gone for at least a tick or two if there are any other non-sleeping processes on that machine. Scott Barta, sbarta@magnus.acs.ohio-state.edu writes: > There's one big problem with all of this. While your application is > burning up cycles waiting to do its next WNE, it's _not_ giving up cycles > to other applications. Very unfriendly. I'm surprised that Apple is Well they're not advocating calling it only once a minute! It's probably best to call WNE about once a second max while you're in the foreground. If you're in the background you may want to call it four times a second or so. If you call WNE too often you're also giving up lots of cycles to a loop inside the Process Manager that waits for TickCount to advance. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From Dave Falkenburg Date: Mon, 18 Apr 1994 20:54:51 GMT Organization: Apple Computer, Inc. In article <1994Apr18.200743.26643@gallant.apple.com> Jens Alfke, jens_alfke@powertalk.apple.com writes: >Well they're not advocating calling it only once a minute! It's probably best >to call WNE about once a second max while you're in the foreground. If you're >in the background you may want to call it four times a second or so. If you You should ALWAYS dynamically calculate the sleep time! When in the background, err on the side of calling WNE more than you'd like with LARGE sleep values. When running in the foreground, you should periodically call through, but alter the frequency of your calling through if you are doing something very compute-bound. If you AREN'T compute bound, always call through... In most cases, the worst thing this will do is pollute your instruction cache with other people's code. Of course, if you are doing something USER-bound (like a word processor) you probably always want to call through anyway. >call WNE too often you're also giving up lots of cycles to a loop inside the >Process Manager that waits for TickCount to advance. Actually, I usually don't disagree with Jens, but this ONLY happens when NO EVENTS are flying around and EVERY process is asleep... In the future, when we have a "real" operating system, we'll block instead... -Dave Falkenburg -Apple Computer, Inc. --------------------------- >From Jeff DuMonthier Subject: X2Fix code generation bug still in SC++ 7.0 Date: 6 Apr 1994 14:54:33 GMT Organization: NASA GSFC I recently posted sample code which demonstrated a code generation bug in SC++ 6.0.1. I have updated to 7.0 and the bug is still there, with maybe a slight difference. The following code demonstrates two variations: #include Fixed FixIt1(extended x) { Fixed f = X2Fix(x); //< This works return f; } Fixed FixIt2(extended *x) { Fixed f = X2Fix(*x); //< This just fails. return f; } void main(void) { extended x = 1.0; extended *xp = &x; Fixed f1 = FixIt1(x); Fixed f2 = FixIt2(&x); Fixed f3 = X2Fix(x); Fixed f4 = X2Fix(*xp); //< Illegal instruction. } I started with a C++ project and used the factory default compilation options for the project and for rebuilding the libraries. The following behavior is what I observed tracing through the program with the source debugger: FixIt1 works correctly and f1 will be assigned 0x00010000. FixIt2 does not work and f2 will be assigned 0 (local variable f in FixIt2 is also assigned 0). The assignment to f3 using X2Fix(x) works but f4 = X2Fix(*xp) results in an illegal instruction error message (run time, not a syntax error). Here is the disassembled code: FixIt1(long double): 00000000: 4E56 0000 LINK A6,#$0000 00000004: 2F03 MOVE.L D3,-(A7) 00000006: 594F SUBQ.W #$4,A7 00000008: 486E 0008 PEA $0008(A6) 0000000C: A844 _X2Fix 0000000E: 201F MOVE.L (A7)+,D0 00000010: 2600 MOVE.L D0,D3 00000012: 261F MOVE.L (A7)+,D3 00000014: 4E5E UNLK A6 00000016: 205F MOVEA.L (A7)+,A0 00000018: 4FEF 000A LEA $000A(A7),A7 0000001C: 4ED0 JMP (A0) 0000001E FixIt2(long double *): 00000000: 4E56 0000 LINK A6,#$0000 00000004: 2F03 MOVE.L D3,-(A7) 00000006: 594F SUBQ.W #$4,A7 00000008: 486E 0008 PEA $0008(A6) 0000000C: A844 _X2Fix 0000000E: 201F MOVE.L (A7)+,D0 00000010: 2600 MOVE.L D0,D3 00000012: 261F MOVE.L (A7)+,D3 00000014: 4E5E UNLK A6 00000016: 205F MOVEA.L (A7)+,A0 00000018: 584F ADDQ.W #$4,A7 0000001A: 4ED0 JMP (A0) 0000001C main: 00000000: 4E56 FFF4 LINK A6,#$FFF4 00000004: 48E7 1E30 MOVEM.L D3-D6/A2/A3,-(A7) 00000008: 2D7C 3FFF 8000 MOVE.L #$3FFF8000,$FFF4(A6) FFF4 00000010: 42AE FFF8 CLR.L $FFF8(A6) 00000014: 426E FFFC CLR.W $FFFC(A6) 00000018: 45EE FFF4 LEA $FFF4(A6),A2 0000001C: 264A MOVEA.L A2,A3 0000001E: 41EE FFF4 LEA $FFF4(A6),A0 00000022: 3F28 0008 MOVE.W $0008(A0),-(A7) 00000026: 2F28 0004 MOVE.L $0004(A0),-(A7) 0000002A: 2F10 MOVE.L (A0),-(A7) 0000002C: 4EBA 0000 JSR FixIt1(long double) 00000030: 2600 MOVE.L D0,D3 00000032: 486E FFF4 PEA $FFF4(A6) 00000036: 4EBA 0000 JSR FixIt2(long double *) 0000003A: 2800 MOVE.L D0,D4 0000003C: 594F SUBQ.W #$4,A7 0000003E: 486E FFF4 PEA $FFF4(A6) 00000042: A844 _X2Fix 00000044: 201F MOVE.L (A7)+,D0 00000046: 2A00 MOVE.L D0,D5 00000048: 594F SUBQ.W #$4,A7 0000004A: 484B BKPT #$3 0000004C: A844 _X2Fix 0000004E: 201F MOVE.L (A7)+,D0 00000050: 2C00 MOVE.L D0,D6 00000052: 4CDF 0C78 MOVEM.L (A7)+,D3-D6/A2/A3 00000056: 4E5E UNLK A6 00000058: 4E75 RTS 0000005A I don't know 68000 assembler, but I can see that FixIt1 and FixIt2 are identical up to the instruction before returning. This does not seem correct since one is passed a pointer and one is passed a 10 byte extended value. Just before the last _X2Fix in main is this instruction: BKPT. Is that the illegal instruction? What is it? The workaround as with the 6.0.1 version of the bug is to always use X2Fix on a local copy of an extended value, not a pointer or a reference. +++++++++++++++++++++++++++ >From N.Perry@massey.ac.nz (N.Perry) Date: Wed, 13 Apr 1994 09:08:22 GMT Organization: School of Maths & Info. Sci., Massey University, Palmerston North, NZ Jeff DuMonthier has posted that a bug in the compilation of extended *arg being passed to X2Fix is still in 7.0. I looked into this and discovered that the problem is even worse than Jeff thought :-( The following function: Fixed FixIt5(extended *x) { extended *h = x; Fixed f = X2Fix(*h); //< ouch! return f; } produces the code: FixIt5(long double *): 00000000: 4E56 0000 LINK A6,#$0000 00000004: 48E7 1020 MOVEM.L D3/A2,-(A7) 00000008: 202E 0008 MOVE.L $0008(A6),D0 0000000C: 2440 MOVEA.L D0,A2 0000000E: 594F SUBQ.W #$4,A7 00000010: 484A BKPT #$2 00000012: A844 _X2Fix 00000014: 201F MOVE.L (A7)+,D0 00000016: 2600 MOVE.L D0,D3 00000018: 4CDF 0408 MOVEM.L (A7)+,D3/A2 0000001C: 4E5E UNLK A6 0000001E: 205F MOVEA.L (A7)+,A0 00000020: 584F ADDQ.W #$4,A7 00000022: 4ED0 JMP (A0) Now a BKPT is not very good for your Mac - I think a crash is inevitable :-( (For 68K hackers, the hex 484A looks like an attempt to code up PEA (A2), a non-existant instruction...) I'll send it off to Symantec tech support. Hope this helps someone *before* their Mac locks up! Cheers, Nigel -- Dr Nigel Perry Email: N.Perry@massey.ac.nz Department of Computer Science Tel: +64 6 356 9099 ext 8900 Massey University Fax: +64 6 350 5611 Palmerston North, New Zealand +++++++++++++++++++++++++++ >From Ron_Hunsinger@bmug.org (Ron Hunsinger) Date: Sat, 16 Apr 94 17:20:27 PST Organization: Berkeley Macintosh Users Group N.Perry@massey.ac.nz (N.Perry) writes: >Now a BKPT is not very good for your Mac - I think a crash is >inevitable :-( (For 68K hackers, the hex 484A looks like an attempt to >code up PEA (A2), a non-existant instruction...) PEA (A2) is a perfectly valid instruction, exactly equivalent in speed, code size, and function to MOVE.L A2,-(A7). Either would have been correct in this sequence. I think you meant to say "484A looks like an attempt to code up PEA A2, which is a non-existent instruction." (Actually, it looks like they were trying to split the difference between PEA (A2) [4852] and MOVE.L A2,-(A7) [1F0A]. They got the sum of 4840 [PEA] and 000A [A2]. If they had started with 1F00 [MOVE.L ,-(A7)], or added 0012 [(A2)], they would have been OK.) -Ron Hunsinger +++++++++++++++++++++++++++ >From pottier@kayak.ens.fr (Francois Pottier) Date: 17 Apr 1994 21:26:59 GMT Organization: Ecole Normale Superieure, PARIS, France In article <0013C774.fc@bmug.org>, Ron Hunsinger wrote: >(Actually, it looks like they were trying to split the difference between >PEA (A2) [4852] and MOVE.L A2,-(A7) [1F0A]. They got the sum of 4840 [PEA] >and 000A [A2]. If they had started with 1F00 [MOVE.L ,-(A7)], or added >0012 [(A2)], they would have been OK.) Do you guys really know all these opcodes by heart ? I'm amazed! -- Francois Pottier pottier@dmi.ens.fr --------------------------- End of C.S.M.P. Digest **********************