From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-026 Date: Fri, 13 May 94 0:30:43 MET DST C.S.M.P. Digest Thu, 12 May 94 Volume 3 : Issue 26 Today's Topics: Can I send Apple Event from Script Editor? Disk Cache performance evaluation test software Extension Shell 1.3 - Help for INIT writers FFT benchmark using CodeWarrior How do I find the window colour ??? Private inheritance faulty in SC++ 7.0 Source Control Questions Using xlc to generate PowerMacintosh code 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 RTY868@email.nml.mot.com (Masaaki Iwasa) Subject: Can I send Apple Event from Script Editor? Date: Wed, 27 Apr 1994 09:03:56 GMT Organization: Nippon Motorola Limited, Tokyo Japan Dose someone know if an Apple Event can be sent from within Script Editor to an Apple Event aware but not Apple Scriptable program? I want to send Apple events to Microsoft Project 3.0 from Script Editor. I know I can send them from HyperCard. No way?? -- Masaaki Iwasa LMPS, Nippon Motorola Limited Email: RTY868@email.nml.mot.com / MHA01341@niftyserve.or.jp +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Thu, 28 Apr 1994 07:28:26 -0700 Organization: Internet for the Olympic Peninsula In article , RTY868@email.nml.mot.com (Masaaki Iwasa) wrote: > Dose someone know if an Apple Event can be sent from within Script Editor > to an Apple Event aware but not Apple Scriptable program? > > I want to send Apple events to Microsoft Project 3.0 from Script Editor. I > know I can send them from HyperCard. You can send arbitrary Apple events to any application which has the proper bit set to say it accepts high level events. The syntax in AppleScript for doing so is rather ugly...if you have Think Project Manager 6 (or, likely 7, but I'm not sure of that), try turning recording on in the Script Editor, then going into Think Project Manager and changing the option regarding the generation of MacsBug symbols. That should record as a generic event, and give you an idea of the syntax. UserLand Frontier provides a somewhat clearer syntax for sending such events...in either scripting system, you can of course write subroutines which hide the gory mess from the rest of your code. -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From isis@netcom.com (Mike Cohen) Date: Thu, 28 Apr 1994 18:29:22 GMT Organization: ISIS International RTY868@email.nml.mot.com (Masaaki Iwasa) writes: >Dose someone know if an Apple Event can be sent from within Script Editor >to an Apple Event aware but not Apple Scriptable program? >I want to send Apple events to Microsoft Project 3.0 from Script Editor. I >know I can send them from HyperCard. >No way?? >-- >Masaaki Iwasa LMPS, Nippon Motorola Limited >Email: RTY868@email.nml.mot.com / MHA01341@niftyserve.or.jp you can send any event using something like: tell application "foo" to <> directobject given <> someotherparam Note that the << and >> should really be opt-backslash & shift-opt-backslash. -- Mike Cohen - isis@netcom.com NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20 +++++++++++++++++++++++++++ >From paul@ctalk.exnet.com (Paul G Smith) Date: Thu, 28 Apr 94 21:45:33 GMT Organization: commstalk, & Full Moon Software Inc In article (comp.sys.mac.programmer), isis@netcom.com (Mike Cohen) writes: > > >Dose someone know if an Apple Event can be sent from within Script Editor > >to an Apple Event aware but not Apple Scriptable program? > > >I want to send Apple events to Microsoft Project 3.0 from Script Editor. I > >know I can send them from HyperCard. > > >No way?? > > >-- > >Masaaki Iwasa LMPS, Nippon Motorola Limited > >Email: RTY868@email.nml.mot.com / MHA01341@niftyserve.or.jp > > you can send any event using something like: > tell application "foo" to <> directobject given > <> someotherparam > There is another way to do this... not guaranteed to be the best solution for your needs, but it will make for easier scripting: Why not create an 'aete' resource for Microsoft Project? It's not a trivial task, admittedly, but it's not all that hard (especially if you take one from another app to use as a starting point). There is a template for ResEdit for editing aete resources. When you have done this, and given a human-readable terminology to the apple events, you'll find it _very_ easy to script them from the Script Editor. best regards, Paul - -------------------------------------------------------------- Paul G Smith, Commstalk HQ || UK ph: +44 727 844232 P O Box 116, ST ALBANS || fax: +44 727 856139 Hertfordshire. AL1 2RL. UK || US ph: 408 253 7199 & Full Moon Software, Inc || fax: 408 252 2378 P O Box 700237, SAN JOSE, CA 95170 || AppleLink: COMMSTALK.HQ --------------------------- >From Stuart Cheshire Subject: Disk Cache performance evaluation test software Date: 9 Apr 1994 17:38:54 GMT Organization: Stanford University The test program writes 512K to disk, using various block sizes, from 1024 FSWrite calls of 512 bytes each to 32 FSWrite of 16K each. Each test is done three ways, firstly with simple FSWrite, then with FSWrite alternating with PBFlushFile, and then with FSWriteNoCache. The first is what you might naively write in a program which is trying to run cooperatively in the background while transferring a file to disk. It results in all the writes going to the cache, and then the Mac freezes solid for ten seconds when the file is closed. The second is an attempt to fix this by flushing the file to disk after every write. It achieves the goal of spreading the delay over all the writes, instead of having a big freeze at the end, but it still takes over 10 seconds. The third method was pointed out to me by Jim Matthews (author of Fetch). It uses the little known (but supported -- see IM:Files, page 89) non-caching option of PBWrite. Similarly, this achieves the goal of spreading the delay over all the writes, but it also makes it go up to 25 times faster. Results: Tests were performed with a Macintosh Quadra 700, System 7.0.1/Tuneup 1.1.1, 768KB disk cache, 32 bit addressing, no virtual memory, 20MB RAM: Testing Writing 512K in various block sizes Testing 0.5K blocks Standard writes: Write: 39 (! 0s) Close: 691 (!11s) Total: 730 (!12s) Write and flush: Write: 689 (!11s) Close: 1 (! 0s) Total: 690 (!11s) No-cache writes: Write: 689 (!11s) Close: 1 (! 0s) Total: 690 (!11s) Testing 1K blocks Standard writes: Write: 26 (! 0s) Close: 691 (!11s) Total: 717 (!11s) Write and flush: Write: 691 (!11s) Close: 1 (! 0s) Total: 692 (!11s) No-cache writes: Write: 346 (! 5s) Close: 0 (! 0s) Total: 346 (! 5s) Testing 2K blocks Standard writes: Write: 23 (! 0s) Close: 692 (!11s) Total: 715 (!11s) Write and flush: Write: 691 (!11s) Close: 0 (! 0s) Total: 691 (!11s) No-cache writes: Write: 85 (! 1s) Close: 0 (! 0s) Total: 85 (! 1s) Testing 4K blocks Standard writes: Write: 21 (! 0s) Close: 692 (!11s) Total: 713 (!11s) Write and flush: Write: 691 (!11s) Close: 1 (! 0s) Total: 692 (!11s) No-cache writes: Write: 51 (! 0s) Close: 0 (! 0s) Total: 51 (! 0s) Testing 8K blocks Standard writes: Write: 21 (! 0s) Close: 691 (!11s) Total: 712 (!11s) Write and flush: Write: 690 (!11s) Close: 1 (! 0s) Total: 691 (!11s) No-cache writes: Write: 39 (! 0s) Close: 0 (! 0s) Total: 39 (! 0s) Testing 16K blocks Standard writes: Write: 17 (! 0s) Close: 692 (!11s) Total: 709 (!11s) Write and flush: Write: 694 (!11s) Close: 0 (! 0s) Total: 694 (!11s) No-cache writes: Write: 26 (! 0s) Close: 1 (! 0s) Total: 27 (! 0s) Notice that: 1. With the simple writes, every block size, even 16K, incurs a Mac-crippling ten second freeze when the file is closed. 2. Using write and flush takes the same time as simple writes, but spread over all the Write calls instead of in a single big freeze at the end. 3. In BOTH of the above cases, it takes at best 691 ticks to write 512K, making a data rate of 44.5K/sec. 4. Using No-cache writes incurs no freeze for the close call, and if you are writing 4K blocks it achieves 602K/sec, more than ten times faster than the simple writes. If you are prepared to go to 16K blocks, it exceeds a megabyte per second -- more than 25 times faster than simple writes with the same block size. If anyone wishes to run the test program and give me results for other configurations, why not post those results here. Stuart Cheshire * WWW * Stanford Distributed Systems Group Research Assistant * Escondido Village Resident Computer Coordinator * Macintosh Programmer >From Stuart Cheshire Subject: Disk Cache performance evaluation test software Date: 9 Apr 1994 18:48:06 GMT Organization: Stanford University // Copyright (C) 23rd November 1993 // Stuart Cheshire #include #include #define FILE_SIZE 0x80000 #define MAX_BLOCK_SIZE 0x4000 static char *buffer; static SysEnvRec sysenvirons; static const unsigned char filename[] = "\pFlusherTestFile"; static IOParam fileflusher; static OSErr FSWriteNoCache(short refnum, long *count_p, const Ptr buffer_p) { OSErr retcode; ParamBlockRec pb; pb.ioParam.ioCompletion = 0; pb.ioParam.ioRefNum = refnum; pb.ioParam.ioBuffer = buffer_p; pb.ioParam.ioReqCount = *count_p; pb.ioParam.ioPosMode = fsAtMark | 0x20; /* don't cache */ pb.ioParam.ioPosOffset = 0; retcode = PBWrite(&pb, false); *count_p = pb.ioParam.ioActCount; return(retcode); } static void filetest(unsigned long block_size, short testcase) { long inOutCount, t1, t2, t3; short fRefNum, i, num_blocks = FILE_SIZE / block_size; FSDelete(filename, sysenvirons.sysVRefNum); if (Create(filename, sysenvirons.sysVRefNum, '????', '????')) { printf("Create failed\n"); exit(1); } if (FSOpen(filename, sysenvirons.sysVRefNum, &fRefNum)) { printf("FSOpen failed\n"); exit(1); } fileflusher.ioCompletion = NULL; fileflusher.ioResult = noErr; fileflusher.ioRefNum = fRefNum; t1 = TickCount(); for (i=0; i * WWW * Stanford Distributed Systems Group Research Assistant * Escondido Village Resident Computer Coordinator * Macintosh Programmer +++++++++++++++++++++++++++ >From qsi@cnh.wlink.nl (Peter Kocourek) Date: Sun, 10 Apr 1994 15:45:39 +0100 Organization: (none) Stuart Cheshire wrote in a message on 09 Apr 94 [... test results deleted] SC> Notice that: SC> 1. With the simple writes, every block size, even 16K, incurs SC> a Mac-crippling ten second freeze when the file is closed. Actually, this depends on the size of the cache; the smaller the cache, the sooner you'll get decent performance with increasing block size. Once a certain threshold is passed (in terms of blocksize vs. cachesize), the performance will improve enormously. Unfortunately, even with just a 32K cache, you need a fairly large blocksize (I forget the exact figures). I have run similar tests with a port of the Unix iozone program, which benchmarks file system performance, and that's how I discovered the rather useless nature of the cache. I did not know about the no-cache bit, though... YHS:QSI! +++++++++++++++++++++++++++ >From whbenson@lbl.gov (Bill Benson) Date: Tue, 12 Apr 1994 15:13:52 -0800 Organization: Lawrence Berkeley Lab Does anyone know if there would be any (significant) performance gain from disabling the cache while reading? (as opposed to writing) -Bill Benson, Lawrence Berkeley Lab, whbenson@lbl.gov +++++++++++++++++++++++++++ >From Alan_B._Harper@bmug.org (Alan B. Harper) Date: Tue, 12 Apr 94 02:04:15 PST Organization: Berkeley Macintosh Users Group There was an interesting note by Mike Scanlin in MacTech magazine (April 1993, p. 75) about the Apple disk cache. I can't quote the entire article, but a relevant section is > The formula [Apple] uses to decide if any given read or write should > be cached is: > numCacheBlocks = user-defined cache size DIV 512; > maxCachedReadWrite = (numCacheBlocks - 1) * 16; > So with a cache size of 256K you get > numCacheBlocks = 512; > maxCachedReadWrite = 8176 > That means that any read/write larger than 8176 bytes will not be cached. So in > my test app [described in the article], nothing was being cached until the cache > was 384K or larger, at which time my 8K writes were being cached (and I got > a 13x performance slow-down). Basically, this means that if your app either does its own caching, or if it writes something it knows it won't need again, always set the no-cache bit. +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Thu, 14 Apr 1994 16:08:37 +0800 Organization: NCRPDA, Curtin University In article <0013A0ED.fc@bmug.org>, Alan_B._Harper@bmug.org (Alan B. Harper) wrote: >Basically, this means that if your app either does its own caching, or if it >writes something it knows it won't need again, always set the no-cache bit. Not entirely. Even if you know it will be read again, it is often better to disable the cache. For example, I get better performance out of Anarchie downloading files and then feeding them to StuffIt Expander if the cache is inhibited during the download even though I know Expander will read the file as soon as I'm finished. Basically, disable the cahce unless you are writing 10 byte blocks, and *DONT* write ten byte blocks! If you write lots of small blocks, the FSClose time goes exponential, at least in tests I did. Writing a 1 Meg file could end up with close times measured in minutes. Peter. _______________________________________________________________________ Peter N Lewis Ph: +61 9 368 2055 +++++++++++++++++++++++++++ >From platypus@cirrus.som.cwru.edu (Gary Kacmarcik) Date: 16 Apr 1994 17:03:25 GMT Organization: Case Western Reserve University, Cleveland, Ohio (USA) In article whbenson@lbl.gov (Bill Benson) writes: > > Does anyone know if there would be any (significant) performance gain from > disabling the cache while reading? (as opposed to writing) the simple answer is that you aren't likely to see any performance gain, and (and if do this indiscriminantly) you'll make things much worse. when you read a chunk from the disk, if it's not in the cache, the disk _must_ be accessed. there's no way around this, and disk accesses are slow. of course, if the data is in the cache, then the read is quite fast. this is the basic idea of caches - keep useful data in the cache to avoid having to access the disk. knowing what data is going to be useful is difficult, but a few rules of thumb have proved useful: if it was accessed recently, it is likely to be accessed again soon if an area was accessed, the surrounding area is likely to be accessed in the near future thus, whenever you access the disk, cache it somewhere because you're likely to need it again. and grab a little bit more than you need, because you're likely to need that, too. turning off the caches effectively disables this optimization. the only time it may be useful is if you know _absolutely_ that you'll never need it again. even then, you probably won't notice the speed benefit (since the disk access is the most significant part, and you can't avoid that). if you load something into the cache that isn't used, it'll eventually get swapped out for useful data. it's usually not worth worrying about. WRT writes, turning off the cache can be useful because it _does_ "eliminate" the disk access by deferring it until later. hope this clears things up, -gary j kacmarcik platypus@cirrus.som.cwru.edu +++++++++++++++++++++++++++ >From Cameron Esfahani Date: Sun, 17 Apr 1994 09:20:34 GMT Organization: Apple Computer, Inc. In article Gary Kacmarcik, platypus@cirrus.som.cwru.edu writes: > knowing what data is going to be useful is difficult, but a few rules of > thumb have proved useful: > if it was accessed recently, it is likely to be accessed again soon > if an area was accessed, the surrounding area is likely to be accessed > in the near future > > thus, whenever you access the disk, cache it somewhere because you're likely > to need it again. and grab a little bit more than you need, because you're > likely to need that, too. > > if you load something into the cache that isn't used, it'll eventually > get swapped out for useful data. it's usually not worth worrying about. > One problem with this is that you have to get the space in the cache from someplace! Then you have to decide what information to throw out, just so you can read in this extra information which might never be used... > > WRT writes, turning off the cache can be useful because it _does_ "eliminate" > the disk access by deferring it until later. > I think you have this backwards; by turning off the cache how does that eliminate the disk access? If anything, having a cache will eliminate the write out to disk by sticking it in the cache and deferring the write until later... Cameron Esfahani dirty@apple.com I make things go faster... +++++++++++++++++++++++++++ >From platypus@cirrus.som.cwru.edu (Gary Kacmarcik) Date: 18 Apr 1994 22:21:20 GMT Organization: Case Western Reserve University, Cleveland, Ohio (USA) In article <1994Apr17.092034.5202@gallant.apple.com> Cameron Esfahani writes: > > In article Gary Kacmarcik, > platypus@cirrus.som.cwru.edu writes: > > > > WRT writes, turning off the cache can be useful because it _does_ "eliminate" > > the disk access by deferring it until later > > I think you have this backwards; by turning off the cache how does > that eliminate the disk access? If anything, having a cache will > eliminate the write out to disk by sticking it in the cache and > deferring the write until later... whoa! what was i smoking when i wrote that... Cameron is, of course, correct in his correction. -gary +++++++++++++++++++++++++++ >From lsr@taligent.com (Larry Rosenstein) Date: Wed, 20 Apr 1994 23:07:56 GMT Organization: Taligent, Inc. In article , peter.lewis@info.curtin.edu.au (Peter N Lewis) wrote: > Basically, disable the cahce unless you are writing 10 byte blocks, and > *DONT* write ten byte blocks! If you write lots of small blocks, the > FSClose time goes exponential, at least in tests I did. Writing a 1 Meg This is good advice for other reasons as well. If the file lives on a server being accessed via ARA, then writing small-sized blocks will be extremely slow. -- Larry Rosenstein Taligent, Inc. lsr@taligent.com +++++++++++++++++++++++++++ >From jumplong@aol.com (Jump Long) Date: 28 Apr 1994 12:51:06 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , lsr@taligent.com (Larry Rosenstein) writes: >> Basically, disable the cahce unless you are writing 10 byte blocks, and >> *DONT* write ten byte blocks! If you write lots of small blocks, the >> FSClose time goes exponential, at least in tests I did. Writing a 1 Meg > > This is good advice for other reasons as well. If the file lives on a > server being accessed via ARA, then writing small-sized blocks will be > extremely slow. Here's a little more information about AppleShare... I'm not sure about AppleShare Pro and AppleShare 4.0 (I suspect it hasn't changed), but the AppleShare 3.0.x, Macintosh File Sharing and AppleShare 2.0 file servers always set the noCache bit for all file access on the server system. They do that because if there are multiple users hitting multiple files on the server, any blocks cached by one user tend to be flushed by I/O by from another user. On the AppleShare client system, the noCache bit is ignored (the AppleShare foreign file system does not use the File Manager's cache *at* *all*). The only thing cached by the AppleShare foreign file system is entries returned by AFPEnumerate which is used to get information in response to indexed GetFInfo and GetCatInfo calls (and the cached directory entries are only kept for a very short period of time). Since the AppleTalk Filing Protocol (AFP) is built on top of the AppleTalk Transaction Protocol (ATP), the amount of data transferred from server to client or client to server is limited to around 4K per AFP request (the maximum size of an ATP reply). Larger requests to AFP are broken up by the protocol code. For example, If you do a PBRead asking for 8K of data from a file on an AppleShare server, AFP will ask the server for 8K and will get back around 4K. So, it will ask for the remaining 4K to finish up the request. So, with the AppleShare 3.0.x, Macintosh File Sharing and AppleShare 2.0 file servers, the server reads everything in 4K chunks and writes everything in 4K chunks, no matter how large the requests were on the client side. AppleShare Pro and AppleShare 4.0 improve performance dramatically by caching data on the server. For example, if an 8K read request is received from a client, the server reads 8K into its cache and returns 4K (because of the ATP limitation). When the AFP client asks for the remaining 4K, the server gets it from its cache which saves a hit to the disk. So, with file access to an AppleShare volume: o The noCache bit in your Reads and Writes makes no difference whatsoever. o Using large Read and Writes from the client will improve performance - especially with AppleShare Pro and AppleShare 4.0. -- Jim Luther --------------------------- >From grantd@dcs.gla.ac.uk (Dair Grant) Subject: Extension Shell 1.3 - Help for INIT writers Date: Wed, 27 Apr 1994 16:45:51 GMT Organization: Computing Science Dept., Glasgow University, Glasgow, Scotland Extension Shell is a library of source code for writing System 7 Extensions. Full source code is provided, as well as six sample Extensions demonstrating how to write Extensions with Extension Shell. Extension Shell acts as an Extension-independent loading mechanism. It takes care of the generic stuff needed by all Extensions (showing icons, installing things into the System Heap, posting Notification Manager messages), and reduces the amount of coding needed to produce new Extensions. To write an Extension with Extension Shell, you just decide what you want installed, compile it into a code resource, and paste in Extension Shell. Trap patches, VBL tasks, Shutdown tasks, Time Manager tasks, Gestalt selectors, low-memory filters (e.g., jGNEFilter), and blocks of code can all be installed through a simple "fill out the details in a table" mechanism. It requires THINK C 6.0. -dair - -------------------+-------------------------------------------------------- Dair Grant | There are two major products that come out of Berkeley: grantd@dcs.gla.ac.uk | LSD and Unix. We don't believe this to be a Finger for PGP Key | coincidence. - Jeremy Anderson - -------------------+-------------------------------------------------------- +++++++++++++++++++++++++++ >From grantd@dcs.gla.ac.uk (Dair Grant) Date: Wed, 27 Apr 1994 17:30:24 GMT Organization: Computing Science Dept., Glasgow University, Glasgow, Scotland grantd@dcs.gla.ac.uk (Dair Grant) writes: >Extension Shell is a library of source code for writing System 7 >Extensions. Full source code is provided, as well as six sample >Extensions demonstrating how to write Extensions with Extension >Shell. [munch] Ooops. I forgot to mention that I've sent it off to macgifts. It should be showing up there within a couple of days. Too many late nights trying to get my final year project finished... :-( -dair - -------------------+-------------------------------------------------------- Dair Grant | There are two major products that come out of Berkeley: grantd@dcs.gla.ac.uk | LSD and Unix. We don't believe this to be a Finger for PGP Key | coincidence. - Jeremy Anderson - -------------------+-------------------------------------------------------- --------------------------- >From andys@nsrvan.van.wa.us Subject: FFT benchmark using CodeWarrior Date: 26 Apr 94 08:58:24 PST Organization: National Systems & Research, Vancouver WA I ran the FFT benchmark which was posted to comp.sys.powerpc by whitney@galileo.Meakins.McGill.CA. I ran this on several computers including a PowerMac 6100/60. I compiled the program using CodeWarrior DR2 which uses the Apple math library. I also am including the SpecInt and SpecFP results which gsnow@clark.edu posted earlier: these FFT results are from whitney@galileo.Meakins.McGill.CA: FFT Time SpecInt SpecFP RS6000 Model 320 55.0 20.9 39.4 RS6000 Model 530 41.0 28.5 64.6 RS6000 Model 250 40.0 62.6 72.2 RS6000 Model 590 18.0 117.0 242.4 These are the results from the tests I ran. Notice I ran with and without the compilers optimizer turned on: RS6000 Model 550 (Opt) 25.0 35.4 71.7 RS6000 Model 550 (No-Opt) 61.0 35.4 71.7 Decstation 5000/260 (Opt) 46.0 57.1 54.5 Decstation 5000/260 (No-Opt) 56.0 57.1 54.5 Decstation 5000/240 (Opt) 99.0 27.9 35.8 Dec3000 Alpha 300L (OVMS-Opt) 54.0 45.9 63.6 Dec3000 Alpha 300L (OVMS-NoOpt) 125.0 45.9 63.6 Dec3100/90 (VMS No-Opt) 133.0 ???? ???? Dec3100/90 (VMS Opt) 108.0 ???? ???? PowerMac 6100/60 (No-Opt) 66.0 ~55.0 ~73.0 PowerMac 6100/60 (Opt) 65.0 ~55.0 ~73.0 PowerMac 6100/60 (Opt/double_t) 77.0 ~55.0 ~73.0 I think this is very interesting because it tells me that the CodeWarrior optimizer has a LONG way to go. Notice what the RS6000 Model 550 did using xlc with and without the optimizer. The optimizer gave a 244% speedup. The PowerMac with no optimization did almost as well as the RS6000 Model 550 without optimization. I think we have a lot to look forward to as CodeWarrior progesses!! Another note, the FFT program uses floats, I tried to change these floats to double_t and the time came out to 77.0 with the optimizer turned on. I also tried changing the struct alignment just for the heck of it and all three settings [PowerPC, 68k, 68k 4-byte] all came out with the same times. One more note, when I say optimizations above I meant I turned on the highest level of optimization each compiler has. +++++++++++++++++++++++++++ >From usenet@lowry.eche.ualberta.ca (Brian Lowry) Date: 26 Apr 1994 22:39:43 GMT Organization: Chem Eng - Univ of Alberta In article <1994Apr26.085824.223@nsrvan.van.wa.us>, andys@nsrvan.van.wa.us wrote: > I think this is very interesting because it tells me that the > CodeWarrior optimizer has a LONG way to go. I was under the impression that the DR2 CodeWarrior C compiler did not actually have optimization implemented, regardless of the project settings. You might want to contact MetroWerks and ask them. I haven't seen any evidence of optimization in low-level stuff... -- Brian Lowry +++++++++++++++++++++++++++ >From ameline@provence.torolab.ibm.com (Ian R. Ameline) Date: 27 Apr 1994 00:09:05 GMT Organization: C-Set++ Development, IBM Canada Laboratory. In <1994Apr26.085824.223@nsrvan.van.wa.us>, andys@nsrvan.van.wa.us writes: [Performance Numbers deleted] >I think this is very interesting because it tells me that the >CodeWarrior optimizer has a LONG way to go. Notice what the >RS6000 Model 550 did using xlc with and without the optimizer. Well, IBM has been writing optimizing compilers for over 20 years. I believe the current XLC optimizer has been in development for around 10 years, with some really bright people involved with it. There should be little surprise that we're good at this sort of thing. >The optimizer gave a 244% speedup. The PowerMac with no optimization >did almost as well as the RS6000 Model 550 without optimization. >I think we have a lot to look forward to as CodeWarrior progesses!! I've heard an unconfirmed rumour on the net that they've licenced some IBM optimization technology. I don't know if it's true or not, but if it is, perhaps your last sentence is correct. Regards, | "Once you have flown, you will walk the earth with Ian R. Ameline, PP-ASEL | your eyes turned skyward, for there you have been, (speaking for myself only)| and there you long to return" -- Leonardo DaVinci ViaCrypt PGP Key fingerprint = 3B B8 CF E9 CA 1B 9C 75 01 7F B2 64 10 7F 96 85 +++++++++++++++++++++++++++ >From Tigger Date: Tue, 26 Apr 1994 03:45:25 GMT Organization: Pomona College In article <2pkaf1$jo5@tornews.torolab.ibm.com> Ian R. Ameline, ameline@provence.torolab.ibm.com writes: > > I've heard an unconfirmed rumour on the net that they've licenced > some IBM optimization technology. I read it in at least two different trade rags, and it was reported as news, not rumors. I believe one of the articles included quotes from a higher-up at Metrowerks. Sounds like more than a rumor to me. -- | Greg Orman greg@pomona.claremont.edu | | A man's best friends: a Harley, a Beretta and a Gund. | +++++++++++++++++++++++++++ >From johnmce@world.std.com (John McEnerney) Date: Wed, 27 Apr 1994 15:54:38 GMT Organization: The World Public Access UNIX, Brookline, MA >Another note, the FFT program uses floats, I tried to change these >floats to double_t and the time came out to 77.0 with the optimizer >turned on. On the PowerPC, 'float' is usually faster than 'double', particularly with multiply/divide instructions. >The PowerMac with no optimization >did almost as well as the RS6000 Model 550 without optimization. This is definitely attributable to the 550 being faster. When optimizations are turned off, CodeWarrior handily outperforms xlc (xlc makes little use of registers when optimization is turned off) >I think we have a lot to look forward to as CodeWarrior progesses!! The current version so CodeWarrior actually do almost no optimization beyond global register allocation. This can make some programs faster, but because of the plentiful registers on the PowerPC it does not make an improvement in many cases. Future versions wil include all of the usual optimizations. -- John +++++++++++++++++++++++++++ >From platypus@cirrus.som.cwru.edu (Gary Kacmarcik) Date: 27 Apr 1994 19:48:49 GMT Organization: Case Western Reserve University, Cleveland, Ohio (USA) In article Tigger writes: > > In article <2pkaf1$jo5@tornews.torolab.ibm.com> Ian R. Ameline, > ameline@provence.torolab.ibm.com writes: > > > > I've heard an unconfirmed rumour on the net that they've licenced > > some IBM optimization technology. > > I read it in at least two different trade rags, and it was reported > as news, not rumors. I believe one of the articles included quotes > from a higher-up at Metrowerks. Sounds like more than a rumor to me. John McEnerey (from Metrowerks) attempted to clarify the articles that were published. these articles implied that Metrowerks has licensed some of IBM's code. this is not the case. included is an excerpt from John's original post. -gary [QUOTED MESSAGE FOLLOWS] Newsgroups: comp.sys.mac.programmer Path: usenet.ins.cwru.edu!eff!news.kei.com!world!johnmce From: johnmce@world.std.com (John McEnerney) Subject: Re: Metrowerks News from MacWEEK Message-ID: Organization: The World Public Access UNIX, Brookline, MA References: <9404090108.AA09272@geweke.ppp.msu.edu> Date: Sat, 9 Apr 1994 09:03:06 GMT Lines: 44 > 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. [... rest deleted ...] +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Wed, 27 Apr 1994 21:59:22 GMT Organization: Adobe Systems Incorporated John McEnerney writes > This is definitely attributable to the 550 being faster. When > optimizations are turned off, CodeWarrior handily outperforms xlc (xlc > makes little use of registers when optimization is turned off) I've observed that if you have debugging information turned on and optimization turned off, xlc goes out of its way to generate *exactly* the seqeunce of operations you wrote in your program. This means that variables are "homed" to their memory locations at the end of each line of code if they are modified. Variables also seem to be preserved as live to the end of their declared scope. The result of these things is a rather inefficient but easy to debug program. I never compile with both optimization and debug symbols off so I don't know if this is a property of turning optimization off, or a property of turning debugging on with optimization off. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 There is no lust like the present. +++++++++++++++++++++++++++ >From whitney@galileo.Meakins.McGill.CA () Date: Thu, 28 Apr 1994 02:40:14 GMT Organization: McGill University andys@nsrvan.van.wa.us wrote: : I ran the FFT benchmark which was posted to comp.sys.powerpc by : whitney@galileo.Meakins.McGill.CA. I ran this on several computers : including a PowerMac 6100/60. : I think this is very interesting because it tells me that the : CodeWarrior optimizer has a LONG way to go. I have also draw this conclusion, but this well known. One has be careful on what conclusions one draws from this simple benchmark. My intention was to use it as sanity check against the numbers I have in magazines and on the net. The benchmark was intended to simulate the number crunching efforts of researchers in our respiratory research lab. We have data sets that usually larger than most caches so I included that in my benchmark. Those that takes benchmarks seriously would say that this makes the benchmark meaningless and that it does little more than detect the presence or absence of a 512 K cache. ( Perhaps it is the case that all our research efforts amount to little more than detecting 512K caches :-) ) Of course, running code in a memory bound fashion tends to diminish the advantage of the super-scalar designs particularly more sophisticated designs such as the POWER2 machines ( as seen the benchmarks ). Furthermore the fft implementation is a very simple one. It has not been reworked for data that exceeds the cache size. Again this was deliberate on my part. More often than not we use simple coding techniques. : One more note, when I say optimizations above I meant I turned on : the highest level of optimization each compiler has. I used cc -O only because we may move binaries from machine to machine - perhaps from the RS6000 to the PowerMac. Whitney +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 27 Apr 94 23:06:02 MST Organization: (none) In article , Tigger writes: > In article <2pkaf1$jo5@tornews.torolab.ibm.com> Ian R. Ameline, > ameline@provence.torolab.ibm.com writes: >> >> I've heard an unconfirmed rumour on the net that they've licenced >> some IBM optimization technology. > > I read it in at least two different trade rags, and it was reported > as news, not rumors. I believe one of the articles included quotes > from a higher-up at Metrowerks. Sounds like more than a rumor to me. > > -- > | Greg Orman greg@pomona.claremont.edu | > | A man's best friends: a Harley, a Beretta and a Gund. | On AOL, the architect of the CodeWarrior C/C++ came out and clarified issues. He won't be able to do much until next year at the earliest... Lawson +++++++++++++++++++++++++++ >From johnmce@world.std.com (John McEnerney) Date: Thu, 28 Apr 1994 06:24:57 GMT Organization: The World Public Access UNIX, Brookline, MA usenet@lowry.eche.ualberta.ca (Brian Lowry) writes: > I was under the impression that the DR2 CodeWarrior C compiler did not >actually have optimization implemented, regardless of the project settings. > You might want to contact MetroWerks and ask them. I haven't seen any >evidence of optimization in low-level stuff... The DR2 and DR3 versions of CodeWarrior (for PowerPC) have no real optimizations. I use the Global Optimization option as a catch-all for anything that is likely to slow down the compiler. For now, it only controls global register allocation. This does quite a nice job of cleaning up your register usage (for example, variables with disjoint lifetimes will get the same register, and it does a pretty good job with function calls) but usually does not provide a significant performance increase because there are so many registers on the PowerPC. Although this is not a huge optimization, the algorithm is O(N^2) so it tends to slow the compiler down quite a bit, which is why the smart register allocator isn't used all the time. DR4 will probably add some common subexpression elimination. Future versions will add the traditional global optimizations, which will slow down the compiler quite a bit more when they are enabled. -- John McEnerney, Metrowerks PowerPC Product Architect --------------------------- >From rjc@crosfield.co.uk (Roger Clark) Subject: How do I find the window colour ??? Date: Thu, 28 Apr 1994 11:05:40 GMT Organization: Crosfield, Hemel Hempstead, UK Hi, I'm trying to find out what "Window colour" has been set by the "Colour" control panel. I have tried using GetAuxWin(nil,&theAuxWinHandle); in an attempt to get the "default" window information, but this gives colours of black or white (0xffff,0xffff,0xffff or 0x0,0x0,0x0) for the various components (like content,frame,text,highlight and title bar). Does anyone know what I'm doing wrong, or have a better solution. Thanks in advance. Roger Clark. +++++++++++++++++++++++++++ >From Carl R. Osterwald Date: Thu, 28 Apr 94 17:10:45 GMT Organization: National Renewable Energy Laboratory In article <1994Apr28.110540.5738@crosfield.co.uk> Roger Clark, rjc@crosfield.co.uk writes: > I'm trying to find out what "Window colour" has been set by the "Colour" >control panel. I have tried using GetAuxWin(nil,&theAuxWinHandle); in >an attempt to get the "default" window information, but this gives colours >of black or white (0xffff,0xffff,0xffff or 0x0,0x0,0x0) for the various >components (like content,frame,text,highlight and title bar). Two items on ftp.apple.com should give you the information you require: * Tech Note TB 33 - "Color, Windows and 7.0" * DTS code snippet "WDEFColorSample" +++++++++++++++++++++++++++ >From devon_hubbard@taligent.com (Devon Hubbard) Date: Thu, 28 Apr 1994 17:32:40 GMT Organization: Taligent, Inc. In article <1994Apr28.110540.5738@crosfield.co.uk>, rjc@crosfield.co.uk (Roger Clark) wrote: > Hi, > I'm trying to find out what "Window colour" has been set by the "Colour" > control panel. I have tried using GetAuxWin(nil,&theAuxWinHandle); in > an attempt to get the "default" window information, but this gives colours > of black or white (0xffff,0xffff,0xffff or 0x0,0x0,0x0) for the various > components (like content,frame,text,highlight and title bar). > > Does anyone know what I'm doing wrong, or have a better solution. > > > Thanks in advance. > Roger Clark. Have you seen Infinity Windoid yet? He supports the floating window being the color that the system has assigned and, giving full credit here to Troy Gaul, here's how he does it. - --- static void GetWctbColor(WindowPeek window, short partCode, RGBColor *theColor) { // Given a partCode, return the RGBColor associated with it. (Using the // default window color table.) AuxWinHandle awHndl; short count; // Get the Color table for the window if it has one. (void) GetAuxWin((WindowPtr) window, &awHndl); count = (**(WCTabHandle) ((**awHndl).awCTable)).ctSize; // If the table didn't contain the entry of interest, look to the // default table. if (count < partCode) { GetAuxWin(nil, &awHndl); count = (**(WCTabHandle) ((**awHndl).awCTable)).ctSize; } // If the entry is there, use it, if not make a best guess at a default value. if (count < partCode) UseDefaultColor(partCode, theColor); else *theColor = (**(WCTabHandle) ((**awHndl).awCTable)).ctTable[partCode].rgb; } - ---- You might want to get his cool Infinity Windoid archive from your nearest site so you can see everything he's doing. - ------------------------------------------------------------------------ Devon Hubbard Silicon Pilot devon_hubbard@taligent.com Taligent, Inc --------------------------- >From tonym@netcom.com (Tony Mann) Subject: Private inheritance faulty in SC++ 7.0 Date: Wed, 27 Apr 1994 21:58:51 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Using SC++ 7.0, the following code should not compile, but it does: class Bag { public: Bag(); int GetCount() { return count; } private: int count; }; class Set: private Bag // note "private" keyword { public: Set(); }; int foo(Bag& b) { return b.GetCount(); } main() { Bag *b = new Set; // ** should generate error; it does not Set s; foo(s); // ** should generate error; it does not return 0; } The compiler is allowing a Set to be implicitly converted to a Bag; this should not be allowed, since Set privately inherits from Bag. Symantec has been notified. - Tony Mann --------------------------- >From David Plumpton Subject: Source Control Questions Date: Tue, 19 Apr 1994 03:12:09 GMT Organization: NorTel Are there any real alternatives to using MPW projector? If you had to manage a multiplatform project using Macintosh, Unix and Windows, which source control system on which platform would you choose? Thanks in advance. - ----------- David Plumpton: plumpto@bnr.ca "I'm a New Zealand Zoo Official, and this monkey's going to Newton!" +++++++++++++++++++++++++++ >From rgc3679@halcyon.halcyon.com (Bob Carpenter) Date: 20 Apr 1994 19:42:23 GMT Organization: A World of Information at Your Fingertips In article <1994Apr19.031209.7354@bnr.ca>, David Plumpton wrote: >Are there any real alternatives to using MPW projector? >If you had to manage a multiplatform project using Macintosh, >Unix and Windows, which source control system on which >platform would you choose? > I'd use SCCS under Unix. It's fairly powerful, and with scripts you can tailor it to your liking. See the sccs man pages for the details. --BobC +++++++++++++++++++++++++++ >From sw@network-analysis-ltd.co.uk (Sak Wathanasin) Date: Thu, 21 Apr 94 09:52:55 GMT Organization: Network Analysis Ltd In article <2p40iv$d1f@nwfocus.wa.com> (comp.sys.mac.programmer), rgc3679@halcyon.halcyon.com (Bob Carpenter) writes: > In article <1994Apr19.031209.7354@bnr.ca>, > David Plumpton wrote: > >Are there any real alternatives to using MPW projector? > >If you had to manage a multiplatform project using Macintosh, > >Unix and Windows, which source control system on which > >platform would you choose? > > > > I'd use SCCS under Unix. It's fairly powerful, and with scripts > you can tailor it to your liking. You cannot be serious: the contortions you have to go through just to mark a set of versions as belonging to a particular release! (Yes, I know about the what prog > prog.slist trick :-() Anyway, I've just come off a Windows/Mac project straight into another one, so the issue is very much on my mind. The main problems with using a non-Mac source control system are a) filename lengths For the first project, we used PVCS on a PC-compatible. Using LAN Mgr for the Mac, we mounted the PC vols on the Mac desktop, and saved our src files there. We then hopped on to a PC to check stuff in and out. Even though LAN Mgr lets you use full Mac filenames, when we came to use PVCS we discovered very quickly that we had to use 8.3 filenames. That meant chasing through all our makefiles, .r files &c - bugs from which are still haunting me (some of the files, like .r files only get rebuilt very occasionally). b) they destroy the Mac rez fork I knew that we couldn't save rsrc files in PVCS, so I had a couple of small MPW scripts that derez'ed rsrc files before saving them on the PC volume. Well, that worked, but we then found that when we checked stuff back out of PVCS that we had lost all our tab settings, font settings, and most important, our MPW markers in every source file. (Sound of grinding teeth...) My current project uses SCCS, and we are going to have similar problems. Anyway, the last time this subject came up, Tom Emerson of Symantec pointed me at SourceSafe by OneTree Software P.O. Box 11639 Raleigh, NC 27604 USA (919)-821-2300 fax (919)-821-5222 I didn't get a chance to follow this up, though I will do this time (promise, really, honest :-). Another possiblility you might like to look at is RCS - there is a Mac port by Tim Endres, available from nic.switch.ch or ftp.msen.com (in /pub/vendors/ice). Please report any experiences with this, especially if you've used it on a real project. Actually, I quite like Projector, especially when backed up with suitable MPW scripts (look for DTS Goodies on a developer CD). I don't see why it can't be used for storing Unix and Windows src files, since Projector, unlike SCCS can hold binary files. 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 xxx (Christoph Reichenberger) Date: Mon, 25 Apr 1994 07:10:27 GMT Organization: Uni Software Plus In article <2p40iv$d1f@nwfocus.wa.com>, rgc3679@halcyon.halcyon.com (Bob Carpenter) wrote: > In article <1994Apr19.031209.7354@bnr.ca>, > David Plumpton wrote: > >Are there any real alternatives to using MPW projector? > >If you had to manage a multiplatform project using Macintosh, > >Unix and Windows, which source control system on which > >platform would you choose? > > Voodoo (the name stands for Versions Of Outdated Documents Organized Orthogonally) is a (Mac) version management tool for the simple and clear management of projects in which files are created in numerous versions (variants and revisions). Since Voodoo is capable of managing arbitrary files, the program can be employed for more than just the organization of software projects in a narrow sense (program development). Even the writing of a book, for example, is a project in which multiple elementary building blocks (the individual chapters, illustrations, etc.) evolve in various revisions. Using Voodoo can also pay off here. Voodoo allows both variant and revision control, and it manages not only variants and revisions of single files, but of a whole software project (multi files, multi users, multi variants, access rights, ...). The tool offers a neat graphical user interface and is not only suitable for mere source code control but can handle all different kinds of files with amazing compression rates: typical size of delta between arbitrary files 5% (in words: five per cent) !!!! no matter whether the files are plain text or any other documents - e. g. MSWord, WriteNow, Canvas, FileMaker ...). Contrary, if you try to manage non-text-files with Projector or SCCS you will not get any space reduction. Voodoo differs from previous source code control systems in its orthogonal approach to version management. This means that for every component of a project hierarchy you can not only store its revision history but also different variants of the same component.The orthogonal organization of revisions and variants leads to a much clearer organization that with other RCS/SCCS-based tools like Projector/SourceServer and others. A lite version of Voodoo is being distributed on a shareware basis (30 $). The package included contains VoodooLite 1.5 together with a readme document and a manual. You can get the current version directly from our ftp-server at: ftp.swe.uni-linz.ac.at in /pub/voodoo Additionally it should be available via ftp at least at the following sites: sumex-aim.stanford.edu in /info-mac/dev mac.archive.umich.edu in /mac/util/organization The full (commercial) version of Voodoo is being distributed world-wide by: UNI Software Plus Softwarepark Hagenberg A-4232 Hagenberg AUSTRIA (Europe) Fax.: +43 (7236) 37 69 EMail: voodoo@unisoft.co.at For further information on Voodoo Lite or on the full version please contact the author: Christoph Reichenberger Tel: +43-7262-2166 Erlenweg 2 Fax: +43-7236-3338-30 A-4320 Perg, Austria Internet: chrei@unisoft.co.at Feel free to contact me, if you have further questions concerning Voodoo. Christoph, the author of Voodoo +++++++++++++++++++++++++++ >From hoshi@sra.co.jp (Hoshi Takanori) Date: 27 Apr 94 11:34:50 Organization: Software Research Associates, Inc.,Japan In article <1994Apr19.031209.7354@bnr.ca> David Plumpton writes: > Are there any real alternatives to using MPW projector? > If you had to manage a multiplatform project using Macintosh, > Unix and Windows, which source control system on which > platform would you choose? I've just started using RCS on my MacMiNT. It's great! hoshi --------------------------- >From Ken Prehoda Subject: Using xlc to generate PowerMacintosh code Date: 15 Apr 1994 00:36:24 GMT Organization: Univ of Wisc-Madison I have access to an RS/6000 with the xlc compiler. My question is how do I use this compiler to generate code for the mac. Could someone with experience in this area please give me some pointers? Thanks, Ken Prehoda kenp@nmrfam.wisc.edu +++++++++++++++++++++++++++ >From creiman@netcom.com (Charlie Reiman) Date: Fri, 15 Apr 1994 07:15:24 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Ken Prehoda writes: >I have access to an RS/6000 with the xlc compiler. My >question is how do I use this compiler to generate >code for the mac. Could someone with experience in >this area please give me some pointers? You can't, really. The xlc that apple is giving to developers is modified to support the pascal keyword (ignored), #pragma align=68k (very important), and pascal strings (also important). Also, their xlc generates instructions for the PowerPC which probably isn't an option on older versions of xlc. If you don't need any of these, then you can generate .o files, then drop those into an MPW development environment and use the usual makepef, ppclink, et al. If you can get the inside track SDK, it's actually pretty cool (if you are an unix hacker, anyway). I've always wanted to cross compile my mac apps under unix. Now, I can. -- "You can't cancel the project! We already made the T-shirts!" Charlie Reiman creiman@netcom.com +++++++++++++++++++++++++++ >From mgleason@cse.unl.edu (Mike Gleason) Date: 15 Apr 1994 11:13:39 GMT Organization: NCEMRSoft creiman@netcom.com (Charlie Reiman) writes: |Ken Prehoda writes: |>I have access to an RS/6000 with the xlc compiler. My question is how |>do I use this compiler to generate code for the mac. Could someone with |>experience in this area please give me some pointers? |You can't, really. The xlc that apple is giving to developers is |modified to support the pascal keyword (ignored), #pragma align=68k |(very important), and pascal strings (also important). Also, their xlc |generates instructions for the PowerPC which probably isn't an option |on older versions of xlc. Too bad... one could write a preprocessor that could handle the 'pascal' and pascal strings, then use that before the cpp for xlc. Can't get around the #pragma align=68k or PowerPC generation, though. |If you don't need any of these, then you can generate .o files, then |drop those into an MPW development environment and use the usual |makepef, ppclink, et al. If you can get the inside track SDK, it's |actually pretty cool (if you are an unix hacker, anyway). I've |always wanted to cross compile my mac apps under unix. Now, I can. Me too. One thing I did just figure out how to do, which has nothing to do with PowerPC, is send my mac code over to a unix box and run lint on it, or actually "compile" my mac code with gcc for sole purpose of seeing all the cool warnings it spews. Seems kind of silly, but the only mac compiler I can use right now is Think C 5, which doesn't give me warning messages. -- --mg mgleason@cse.unl.edu +++++++++++++++++++++++++++ >From Ken Prehoda Date: 15 Apr 1994 14:58:51 GMT Organization: Univ of Wisc-Madison Charlie Reiman, creiman@netcom.com writes: >You can't, really. The xlc that apple is giving to developers is >modified to support the pascal keyword (ignored), #pragma align=68k >(very important), and pascal strings (also important). Also, their xlc >generates instructions for the PowerPC which probably isn't an option >on older versions of xlc. Thanks for the info. The version of xlc that I have will align=68k and will also generate instructions for the 601. Also, I can get rid of the pascal keyword easy enough. In other words, I think I can get it to do all of the things that you say. However, is it possible to compile a complete mac application on the RS/6000 (i.e. I don't have MPW)? >If you don't need any of these, then you can generate .o files, then >drop those into an MPW development environment and use the usual >makepef, ppclink, et al. If you can get the inside track SDK, it's >actually pretty cool (if you are an unix hacker, anyway). I've >always wanted to cross compile my mac apps under unix. Now, I can. Me too. And that's the main reason I'm even bothering with all this. Not to mention how much I like xlc. Thanks again, Ken Prehoda kenp@nmrfam.wisc.edu +++++++++++++++++++++++++++ >From proth@toto.cs.uiuc.edu (Phil Roth) Date: Fri, 15 Apr 1994 16:10:22 GMT Organization: Picasso Group, DCS, University of Illinois, Urbana-Champaign In article <2olst3$9oi@crcnis1.unl.edu>, mgleason@cse.unl.edu (Mike Gleason) writes: |> creiman@netcom.com (Charlie Reiman) writes: |> |> |Ken Prehoda writes: |> |>I have access to an RS/6000 with the xlc compiler. My question is how |> |>do I use this compiler to generate code for the mac. Could someone with |> |>experience in this area please give me some pointers? |> |> |You can't, really. The xlc that apple is giving to developers is |> |modified to support the pascal keyword (ignored), #pragma align=68k |> |(very important), and pascal strings (also important). Also, their xlc |> |generates instructions for the PowerPC which probably isn't an option |> |on older versions of xlc. |> |> Too bad... one could write a preprocessor that could handle the 'pascal' |> and pascal strings, then use that before the cpp for xlc. Can't get |> around the #pragma align=68k or PowerPC generation, though. The last version of xlc I installed on our research RS/6000 supposedly has PowerPC code generation support ( using -qarch=ppc ). The man page claims that it will "Produce an object that contains instructions that will run on any of the 32-bit PowerPC hardware platforms." Also, one can specify an alignment option for aligning structs and unions. The choices are 'power' for the POWER architecture, 'twobyte' for two byte alignment, and 'packed' for one byte alignment. How would this relate to the 'align=68k' pragma discussed above? Pascal strings would be an interesting addition, nevertheless. Phil Roth proth@cs.uiuc.edu +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Fri, 15 Apr 1994 10:15:09 GMT Organization: Adobe Systems Incorporated Ken Prehoda writes > I have access to an RS/6000 with the xlc compiler. My > question is how do I use this compiler to generate > code for the mac. Could someone with experience in > this area please give me some pointers? Both Metrowerks and Apple's Macintosh on RISC SDK will accept XCOFF object files from the RS/6000. And if you have the very latest version of IBM's compilers, you should be able to compile with the Universal headers. (I believe Charlie Reiman's comment that the Mac specific features are not in the shipping version of IBM's compiler is incorrect.) You'll likely need to muck with the xlc configuration though. You can either do this by hand feeding in a bunch of flags on the command line, or by making a custom xlc.cfg file. (Which is only slightly more fun than smacking yourself in the head with an axe repeatedly.) The important compiler options you'll need are: -qmacpstr -qpascal -qenum=small -qcpluscmt -qldbl128 -qchars=signed -D__powerc=1 -Dpowerc=1 -DUSE68KINLINES=0 -U_AIX You'll need a -I directive pointing to the Universal headers somewhere on your AIX box. (Unless the code doesn't rely on Macintosh interfaces in which case its a lot easier. For example if you just have some computation intensive routines you want to compile.) You might also want to add a -qNOSTDINC to tell xlc not to search the standard system include directories. You can link on the AIX box as well if you have the right libraries, which can probably be snagged off Apple's SDK. You'll have to move the XCOFF result over to a Mac and run makepef in MPW. Optionally, it may be easier to haul the .o files over to your Mac (being sure to use a binary transfer method that preserves every last bit in its pristine natural form) and use Apple's PowerPC linker within MPW. (I've never used Apple's SDK, so I really have no idea how that works.) Once you've gotten a fully linked XCOFF file, you can feed it to makepef to produce your PEF container. (And you'll have to do that in MPW 'cause I doubt Apple is distributing the RS/6000 version of makepef anywhere.) I'll let John McEnerney detail how you use AIX generated objects with CodeWarrior. So far I've figured out that you need a file of type XCOF and creator UNIX which is a shared reuseable XCOFF library. I believe this implies that CodeWarrior will only link against shared libraries this way, that you can't link the code directly into your app. (Then again I really have no idea how it works.) If that's true, you'll need to make a shared library out of the code you compile on AIX. (The specific process of making a shared library is a a bit involved, but on AIX, you'll need to give ld at least the -bM:SRE switch and an exports file. You feed the output of that to makepef and shove a cfrg resource in the resource fork of the result.) Suffice it to say, this is not a trivial task. Though realistically, it is probably the best development environment for Power Macintosh right now. Especially if you have a really huge app, or are working in C++. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 Remember Y'all, in Arizona immigration lawyers are in season year 'round! +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Sat, 16 Apr 1994 01:31:01 GMT Organization: Adobe Systems Incorporated Phil Roth writes > In article <2olst3$9oi@crcnis1.unl.edu>, mgleason@cse.unl.edu (Mike Gleason) writes: > |> creiman@netcom.com (Charlie Reiman) writes: > |> > |> |Ken Prehoda writes: > |> |>I have access to an RS/6000 with the xlc compiler. My question is how > |> |>do I use this compiler to generate code for the mac. Could someone with > |> |>experience in this area please give me some pointers? > |> > |> |You can't, really. The xlc that apple is giving to developers is > |> |modified to support the pascal keyword (ignored), #pragma align=68k > |> |(very important), and pascal strings (also important). Also, their xlc > |> |generates instructions for the PowerPC which probably isn't an option > |> |on older versions of xlc. > |> > |> Too bad... one could write a preprocessor that could handle the 'pascal' > |> and pascal strings, then use that before the cpp for xlc. Can't get > |> around the #pragma align=68k or PowerPC generation, though. > > > The last version of xlc I installed on our research RS/6000 supposedly > has PowerPC code generation support ( using -qarch=ppc ). > The man page claims that it will > > "Produce an object that contains instructions that will > run on any of the 32-bit PowerPC hardware platforms." > > Also, one can specify an alignment option for aligning structs and unions. > The choices are 'power' for the POWER architecture, 'twobyte' for two > byte alignment, and 'packed' for one byte alignment. > How would this relate to the 'align=68k' pragma discussed above? "#pragma options align=mac68k" is a synonym for "#pragma options align=twobyte". Try using the mac68k syntax with the shipping 1.03 version of xlc and I bet it will work. By the way, I left out the "-qarch=ppc" switch in my previous message in this thread. You should give that to xlc to prevent it from generating POWER architecture only instructions. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 Remember Y'all, in Arizona immigration lawyers are in season year 'round! +++++++++++++++++++++++++++ >From d88-jwa@mumrik.nada.kth.se (Jon Wätte) Date: 16 Apr 1994 09:39:13 GMT Organization: The Royal Institute of Technology In <1994Apr15.101509.21634@adobe.com> zstern@adobe.com (Zalman Stern) writes: >You can link on the AIX box as well if you have the right libraries, which >can probably be snagged off Apple's SDK. You'll have to move the XCOFF >result over to a Mac and run makepef in MPW. Optionally, it may be easier to Actually, you CAN execute an XCOFF as well (I haven't tried but heard it from an engineer who should know) It's just that they're 3 times the size of a PEF... -- -- 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 creiman@netcom.com (Charlie Reiman) Date: Mon, 18 Apr 1994 02:53:13 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) d88-jwa@mumrik.nada.kth.se (Jon Wätte) writes: >In <1994Apr15.101509.21634@adobe.com> zstern@adobe.com (Zalman Stern) writes: >>You can link on the AIX box as well if you have the right libraries, which >>can probably be snagged off Apple's SDK. You'll have to move the XCOFF >>result over to a Mac and run makepef in MPW. Optionally, it may be easier to >Actually, you CAN execute an XCOFF as well (I haven't tried but heard >it from an engineer who should know) It's just that they're 3 times the >size of a PEF... 3??? Try 40 times larger. I have a 2 meg pef that I makepef from an xcoff that is 70-80megs. Yes, linking takes forever. -- "You can't cancel the project! We already made the T-shirts!" Charlie Reiman creiman@netcom.com +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Mon, 18 Apr 1994 04:16:26 GMT Organization: Adobe Systems Incorporated Charlie Reiman writes [XCOFF vs. PEF.] > 3??? Try 40 times larger. I have a 2 meg pef that I makepef from an xcoff > that is 70-80megs. > > Yes, linking takes forever. You build with full debug symbols right? XCOFF is a pig, but not that much of a pig. PEF doesn't contain any debug info of course. the .xSYM file for your XCOFF is probably measured in tens of megabytes though. Likewise, IBM linker is dramatically faster if you turn off debug info for the compiler. (Unfortunately, there is no switch to the linker to ignore debug info for all but a few object files.) On a pretty hefty RS/6000, I can link in 15 minutes with full symbols and 1 minute with no symbols. I leave in traceback tables (the moral equivalent of Macsbug names) and debug a lot of stuff that way. And at the end of the day, if I'm lucky I manage to club some small mammal on the way back to the cave so I can have dinner :-) -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 Remember Y'all, in Arizona immigration lawyers are in season year 'round! +++++++++++++++++++++++++++ >From maynard@elwing.otago.ac.nz (Maynard James Handley) Date: Wed, 20 Apr 1994 22:59:21 GMT Organization: University of Otago Apart from issues like 68K alignment and pascal strings, are there not fundamental problems at the "OS" level? For examples, doesn't AIX have conventions about using the first N registers to pass variables between functions. I don't know if MacOS on PowerPC has such conventions, but it expectects one of the registers always to point to the code fragment TOC thingie---would it not be very bad if xlc used said register for something else. Are these valid issues or not? I don't yet have a copy of IM: RISC system software, so please be gentle if I'm spouting nonsense. Maynard Handley +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Thu, 21 Apr 1994 11:22:55 +0800 Organization: Department of Computer Science, The University of Western Australia In article , maynard@elwing.otago.ac.nz (Maynard James Handley) wrote: >Apart from issues like 68K alignment and pascal strings, are there not >fundamental problems at the "OS" level? > >[lots of talk about calling conventions] My understanding is that Apple block-copied IBM's runtime architecture for their PowerMacs. [This is not a criticism, just an observation. The run-time architecture is kinda cool -- apart from the *extreme* silliness of allocating two GPRs for each FP parameter just to support prototype-less C calling!] -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Thu, 21 Apr 1994 05:53:08 GMT Organization: Adobe Systems Incorporated Maynard James Handley writes > Apart from issues like 68K alignment and pascal strings, are there not > fundamental problems at the "OS" level? > For examples, doesn't AIX have conventions about using the first N registers > to pass variables between functions. I don't know if MacOS on PowerPC has > such conventions, but it expectects one of the registers always to point > to the code fragment TOC thingie---would it not be very bad if xlc used > said register for something else. The runtime architecture you are refering to was developed by IBM and adopted basically without change by Apple. Binaries running on the RS/6000 have used r2 as a TOC pointer for more than four years now. (And that particular convention pretty much came from the IBM RT which shipped in '86.) The PowerPC code in the Power Macintosh ROMs is compiled with xlc. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 Remember Y'all, in Arizona immigration lawyers are in season year 'round! +++++++++++++++++++++++++++ >From R.Beloin@cornell.edu (Ron Beloin) Date: Thu, 21 Apr 1994 11:57:00 -0500 Organization: Boyce Thompson Inst. for Plant Research In article <1994Apr18.041626.14768@adobe.com>, zstern@adobe.com (Zalman Stern) wrote: > [XCOFF vs. PEF.] > [other stuff about XCOFF] Sorry for the basic question, but how does one link XCOFF format files from an RS6K in MPW? E.G., what version of Link do i need, what options or swithches are required. I already have the RS6K and E.T.O. Thanks. -- Ron Beloin (R.Beloin@cornell.edu) [who works, but doesn't speak, for the] Boyce Thompson Inst. Ithaca, NY +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Thu, 21 Apr 1994 23:31:46 GMT Organization: Adobe Systems Incorporated Ron Beloin writes > In article <1994Apr18.041626.14768@adobe.com>, zstern@adobe.com (Zalman > Stern) wrote: > > [XCOFF vs. PEF.] > > [other stuff about XCOFF] > > Sorry for the basic question, but how does one link XCOFF format > files from an RS6K in MPW? E.G., what version of Link do i need, what > options or swithches are required. I already have the RS6K and E.T.O. > Thanks. You need ppclink off the Macintosh on RISC SDK. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 Remember Y'all, in Arizona immigration lawyers are in season year 'round! +++++++++++++++++++++++++++ >From d88-jwa@mumrik.nada.kth.se (Jon Wätte) Date: 23 Apr 1994 10:40:51 GMT Organization: The Royal Institute of Technology In R.Beloin@cornell.edu (Ron Beloin) writes: >Sorry for the basic question, but how does one link XCOFF format >files from an RS6K in MPW? E.G., what version of Link do i need, what >options or swithches are required. I already have the RS6K and E.T.O. You need the Mac on RISC SDK CD which comes with PPCLink and MakePEF. It also comes with the right headers and libraries. Cheers, -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe -- "Never mistake a clear view for a short distance" -- Saffo +++++++++++++++++++++++++++ >From Dave Falkenburg Date: Thu, 28 Apr 1994 17:03:33 GMT Organization: Apple Computer, Inc. In article Maynard James Handley, maynard@elwing.otago.ac.nz writes: >For examples, doesn't AIX have conventions about using the first N registers >to pass variables between functions. I don't know if MacOS on PowerPC has >such conventions, but it expectects one of the registers always to point >to the code fragment TOC thingie---would it not be very bad if xlc used >said register for something else. The PowerMac runtime environment is dervied from the AIX runtime model-- we used special versions of xlc to build the native portions of the toolbox. -Dave Falkenburg -Apple Computer, Inc. --------------------------- End of C.S.M.P. Digest **********************