From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-024 Date: Sat, 7 May 94 13:07:29 MET DST C.S.M.P. Digest Sat, 07 May 94 Volume 3 : Issue 24 Today's Topics: Anyone have routine for random numbers? Async CD-ROM Drivers? Comparing 2 LongDateTime's Copying graphics the fast way (in assembler) Favorite C++ Book? Native PPC Interrupt Control? SetDialogDefaultItem in a modal dialog Symantec has an FTP site! pascal and c libraries 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 truo8166@silver.SJSU.EDU (Thai Binh Truong) Subject: Anyone have routine for random numbers? Date: 21 Apr 94 20:47:04 GMT Organization: San Jose State University - Math/CS Dept. I'm looking for a routine that will generate normally distributed random numbers. If anyone know of any other routines that comes close to it, please post. Thanks in advance. -Thai +++++++++++++++++++++++++++ >From Jim Conner Date: 22 Apr 1994 16:00:20 GMT Organization: Cornell University Subject: Anyone have routine for random numbers? From: Thai Binh Truong, truo8166@silver.SJSU.EDU Date: 21 Apr 94 20:47:04 GMT In article Thai Binh Truong, truo8166@silver.SJSU.EDU writes: >I'm looking for a routine that will generate >normally distributed random numbers. If anyone >know of any other routines that comes close to >it, please post. Thanks in advance. > >-Thai > Try looking in Numerical Recipes in Pascal (or C or Fortran, take your pick). Each book in this set has several routines for generating uniform deviates as well as other types of distributions. The routine for normally distributed random numbers looks like this (in Pascal): { Global stuff... } GasdevIset: integer; GasdevGset: real; begin GasdevIset := 0; { Returns a normally distributed deviate with zero mean and unit variance, } { using UniDev as the source of uniform deviates. } function gasdev: extended; var fac, r, v1, v2: extended; begin if GasdevIset = 0 then begin repeat v1 := 2.0 * UniDev - 1.0; v2 := 2.0 * UniDev - 1.0; r := sqr(v1) + sqr(v2); until (r < 1.0) and (r > 0.0); fac := sqrt(-2.0 * ln(r) / r); GasdevGset := v1 * fac; gasdev := v2 * fac; GasdevIset := 1 end else begin GasdevIset := 0; gasdev := GasdevGset; end end; See Numerical Recipes for more details. Jim Conner +++++++++++++++++++++++++++ >From AppleGG@lamg.com (Gordon Apple) Date: 22 Apr 1994 11:55:56 -0800 Organization: (none) I'm looking for a routine that will generate normally distributed random numbers. If anyone know of any other routines that comes close to it, please post. Thanks in advance. I don't have the exact algorithms handy, but here are a couple of suggestions (assuming you already have a good uniformly distributed random number generator): If you are just doing things like usual statistics, then the simplest way is to generate a series of uniformly distributed variables and average them. Even small series like 16 or so will give you very good results. If you're working far out on the tail (5 or 10 standard deviations), such as is often the case when working statistical communications problems, you need something better. One of the best methods we found for our simulations was to take a pair of uniformly distributed random variables and use them to generate a pair of Gaussion rvs. To do this, you need to use an exponential to map one variable into a Rayleigh amplitude distribution. Use the other to generate a random angle from 0 to 2 * Pi. Use sin and cos to get the two (independent) Gaussians. Works great. I've used it for years. G. Gordon Apple, PhD Advanced ommunications Engineering, Inc. Redondo Beach, CA +++++++++++++++++++++++++++ >From afcjlloyd@aol.com (AFC JLloyd) Date: 22 Apr 1994 19:52:06 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <505016286.7954988@lamgnet.lamg.com>, AppleGG@lamg.com (Gordon Apple) writes: >>> If you're working far out on the tail (5 or 10 standard deviations), such as is often the case when working statistical communications problems, you need something better. One of the best methods we found for our simulations was to take a pair of uniformly distributed random variables and use them to generate a pair of Gaussion rvs. To do this, you need to use an exponential to map one variable into a Rayleigh amplitude distribution. Use the other to generate a random angle from 0 to 2 * Pi. Use sin and cos to get the two (independent) Gaussians. Works great. I've used it for years. <<< Code to implement this technique can be found in "Numerical Recipes in C". The code given manages to avoid calling sin() and cos(), but it does require a log() and a sqrt() (and a float divide). Here's the basic code: do { v1 = 2.0*ran() - 1.0; v2 = 2.0*ran() - 1.0; r = v1*v1 + v2*v2; } while (r >= 1.0); fac = sqrt(-2.0*log(r)/r); ran() is a function returning a uniform deviate in the range 0.0 .. 1.0. After computing the above, you can now get two independent normal deviates by returning v1*fac and v2*fac. The deviates have zero mean and unit variance. Jim Lloyd afcjlloyd@aol.com --------------------------- >From siegel@netcom.com (Rich Siegel) Subject: Async CD-ROM Drivers? Date: Wed, 13 Apr 1994 21:46:18 GMT Organization: Bare Bones Software (This is a philosophical question. If you can't spell "philosophy", you're excused. :-]) A number of us, having nothing better to do, were idly wondering about the pros and cons of the new SCSI Manager. One of its benefits is the ability to disconnect and reconnect (provided the device supports it), which leads directly to the ability for a driver to support async I/O operations. This obviously works well for high-speed SCSI devices and copying. You can also perform some SCSI operations such as a format asynchronously at the application level (drivers rarely, if ever, need to format a disk); the app can issue the format, disconnect, and then handle UA and reconnect. However, my colleagues and I can't pin down and specific technical benefits, besides the pure sex appeal, for supporting async I/O in a CD-ROM driver. Are we missing something? Can someone, or several someones, enumerate the specific benefits for supporting async SCSI operation for CD-ROM drives? For the benefit of all, please post to this newsgroup. R. -- Rich Siegel % siegel@netcom.com % Principal, Bare Bones Software --> For information about BBEdit, finger bbedit@world.std.com <-- "...yeah, I inhaled, and then I drank the bong water. So what're you gonna do about it?" - Dennis Miller, on Bill Clinton +++++++++++++++++++++++++++ >From resnick@cogsci.uiuc.edu (Pete Resnick) Date: Thu, 14 Apr 1994 00:25:43 -0500 Organization: University of Illinois at Urbana-Champaign In article , siegel@netcom.com (Rich Siegel) wrote: >(This is a philosophical question. If you can't spell "philosophy", >you're excused. :-]) I think I can spell it pretty well. >This obviously works well for high-speed SCSI devices and copying. Why does anyone care about async I/O on a high-speed device other than pure sex appeal? On a high-speed device, I/O should happen so quickly that calling it async should have no effect to your program. >However, my colleagues and I can't pin down and specific technical >benefits, besides the pure sex appeal, for supporting async I/O in a >CD-ROM driver. > >Are we missing something? Can someone, or several someones, enumerate >the specific benefits for supporting async SCSI operation for CD-ROM >drives? The best reason for any async I/O on any device is multitasking. It drives me absolutely bananas that FSRead is written synchronously, because to read 1 Meg at a time, people call: buffPtr = NewPtr(1000000); count = 1000000; FSRead(refNum, &count, buffPtr); This is ESPECIALLY horrible on a slow device, and worst over the network (consider going over a 9600 bps ARA link). Why can't people do it right and say: paramBlock->ioParam.ioCompletion = nil; paramBlock->ioParam.ioRefNum = refNum; paramBlock->ioParam.ioBuffer = NewPtr(1000000); paramBlock->ioParam.ioReqCount = 1000000; PBReadAsync(paramBlock); while(paramBlock->ioParam.ioResult > noErr) HandleEvents(); So, the reason that a CD-ROM drive should have async I/O is exactly because the damn things are slow. In all honesty, I don't see that there is any other reason to have async I/O except to allow you to call your event loop during I/O operations. Everything else is secondary. Personally, I wish that FSRead called _Read asynchronously and provided a filterProc which could continue to receive events while the damn read was going on. I am driven almost to tears every time I try to get anything done while doing copies in the Finder (which, contrary to its documentation, can't do a background copy to save its life) from a slow device because my machine either comes to a complete screeching halt or behaves so poorly that I can't get anything done (like typing a news article). CD-ROM's should have async I/O before any device which is faster. pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet: resnick@cogsci.uiuc.edu +++++++++++++++++++++++++++ >From zobkiw@datawatch.com (joe zobkiw) Date: Thu, 14 Apr 1994 13:20:42 GMT Organization: Datawatch Corporation In article , resnick@cogsci.uiuc.edu (Pete Resnick) wrote: > > CD-ROM's should have async I/O before any device which is faster. > Don't forget floppy disks...believe it or not...some people still use them! :) ___________________________________________________________ _/_/_/_/ Joe Zobkiw ,,, _/ Senior Software Engineer - - _/ Datawatch Corporation L _/_/_/_/ zobkiw@datawatch.com - +++++++++++++++++++++++++++ >From rmcassid@uci.edu (Robert Cassidy) Date: Thu, 14 Apr 1994 10:23:20 -0700 Organization: TLG Project In article , siegel@netcom.com (Rich Siegel) wrote: > > (This is a philosophical question. If you can't spell "philosophy", > you're excused. :-]) > > A number of us, having nothing better to do, were idly wondering about > the pros and cons of the new SCSI Manager. One of its benefits is the > ability to disconnect and reconnect (provided the device supports it), > which leads directly to the ability for a driver to support async I/O > operations. > > This obviously works well for high-speed SCSI devices and copying. > You can also perform some SCSI operations such as a format > asynchronously at the application level (drivers rarely, if ever, need > to format a disk); the app can issue the format, disconnect, and then > handle UA and reconnect. > > However, my colleagues and I can't pin down and specific technical > benefits, besides the pure sex appeal, for supporting async I/O in a > CD-ROM driver. > > Are we missing something? Can someone, or several someones, enumerate > the specific benefits for supporting async SCSI operation for CD-ROM > drives? > > For the benefit of all, please post to this newsgroup. Well, here's a prime example. I work in a place where we take ancient Greek writings (all of 'em) and encode them on CD-ROM. We sent our our first CD about 8 years ago - we were one of the first. The CD contains about 500MB of data, and only about 20MB of indices :-( As the first CD's were going out a decision was made to create a machine dedicated to searching through our CD looking for particular instances of words. The machine was based on an 8MHz 68000 but at 8MHz it was just fast enough to search data at the same rate that it came in (asynchronously) from the CD-ROM drive (150K/sec). The whole process takes about 50 minutes. Most users of our CD are Mac users (~50% worldwide). My Q800 with a 300CD can search the CD in exactly the same amount of time as the 68000 above because there is no asynchrounous. I've determined that if I rewrote the Mac search programs (And I just might) that I would have the following results: For a full search (500MB) running time processing time PM6100 async ~30min <5min PM6100 sync ~35min ~35min The running time (when the program starts to when the program quits) doesn't change much - but the processing time (how much I can't give back to the system) drops drastically. So in 30 minutes (a lot of time in my opinion) the user can recover 25 of it for other things and probably won't even know the background task is running. Just for measure. We have an HP1000 that most of our work is done on. It takes about 6 hours for a full search with no other users on the system. A PM8100 working asynchronously from HD could do it in under 5 min. -- Robert Cassidy TLG Project UC Irvine Let's hope 'Information SuperTollroad' isn't the catchphrase of the next decade... +++++++++++++++++++++++++++ >From rang@winternet.mpls.mn.us (Anton Rang) Date: 15 Apr 1994 00:13:30 GMT Organization: Minnesota Angsters In article zobkiw@datawatch.com (joe zobkiw) writes: >In article , >resnick@cogsci.uiuc.edu (Pete Resnick) wrote: >> >> CD-ROM's should have async I/O before any device which is faster. >> > >Don't forget floppy disks...believe it or not...some people still use them! >:) But they've had asynchronous I/O since the very first Macs! (Believe it or not....) -- Anton Rang (rang@winternet.mpls.mn.us) +++++++++++++++++++++++++++ >From Steve Bryan Date: Sun, 17 Apr 1994 16:47:49 GMT Organization: Sexton Software In article joe zobkiw, zobkiw@datawatch.com writes: >Don't forget floppy disks...believe it or not...some people still use them! I was under the impression that the driver for the floppy drive was (and has been) asynchronous. The fact that it disables interrupts causing mouse movement to become eratic diminishes the possible benefit of being asynchronous. Steve Bryan InterNet: sbryan@maroon.tc.umn.edu Sexton Software CompuServe: 76545,527 Minneapolis, MN Fax: (612) 929-1799 +++++++++++++++++++++++++++ >From Brad Koehn Date: 18 Apr 1994 02:32:37 GMT Organization: University of Wisconsin In article joe zobkiw, zobkiw@datawatch.com writes: >> >> CD-ROM's should have async I/O before any device which is faster. >> > >Don't forget floppy disks...believe it or not...some people still use them! >:) Floppy I/O is asynchronous, check out a copy of Disk Charmer. It lets you format floppies in the background. It's pretty chunky on my Duo, but it works perfectly on a PPC. _________________________________________________________________________ Brad Koehn Data Transformations, Inc. koehn@macc.wisc.edu +++++++++++++++++++++++++++ >From bell@apple.com (Mike Bell) Date: Wed, 20 Apr 1994 17:34:46 GMT Organization: Apple Computer, Inc. In article , siegel@netcom.com (Rich Siegel) writes: > Newsgroups: comp.sys.mac.programmer > Path: gallant.apple.com!apple.com!taligent!ames!hookup!swrinde!ihnp4. > ucsd.edu!library.ucla.edu!news.ucdavis.edu!csus.edu!netcom.com!siegel > From: siegel@netcom.com (Rich Siegel) > Subject: Async CD-ROM Drivers? > Message-ID: > Organization: Bare Bones Software > Date: Wed, 13 Apr 1994 21:46:18 GMT > Lines: 33 > > > (This is a philosophical question. If you can't spell "philosophy", you' > re excused. :-]) > > A number of us, having nothing better to do, were idly wondering about > the pros and cons of the new SCSI Manager. One of its benefits is the > ability to disconnect and reconnect (provided the device supports it), > which leads directly to the ability for a driver to support async I/O > operations. > > This obviously works well for high-speed SCSI devices and copying. > You can also perform some SCSI operations such as a format > asynchronously at the application level (drivers rarely, if ever, need > to format a disk); the app can issue the format, disconnect, and then > handle UA and reconnect. > > However, my colleagues and I can't pin down and specific technical > benefits, besides the pure sex appeal, for supporting async I/O in a > CD-ROM driver. > > Are we missing something? Can someone, or several someones, enumerate > the specific benefits for supporting async SCSI operation for CD-ROM > drives? > > For the benefit of all, please post to this newsgroup. > > R. > > -- > Rich Siegel % siegel@netcom.com % Principal, Bare Bones Software > --> For information about BBEdit, finger bbedit@world.std.com <-- > > "...yeah, I inhaled, and then I drank the bong water. So what're > you gonna do about it?" - Dennis Miller, on Bill Clinton > Having async I/O in a CD ROM driver is very useful. It allows you to do something with the data that you just read while simultaneously reading another chunk off of the SLOW CD ROM drive. So, if a program is smart enough to use multiple async reads from disc, effective throughput is greatly increased by the async driver. -Mike **************************************************************************** Mike Bell email: bell@apple.com Rock and Roll Project 2 Infinite Loop MS: 302-3SB Cupertino, CA 95014 +++++++++++++++++++++++++++ >From jens_alfke@powertalk.apple.com (Jens Alfke) Date: 21 Apr 94 01:03:58 GMT Organization: Apple Computer Pete Resnick, resnick@cogsci.uiuc.edu writes: > Why does anyone care about async I/O on a high-speed device other than > pure sex appeal? On a high-speed device, I/O should happen so quickly that > calling it async should have no effect to your program. By those standards I guess a RAM disk might qualify as "high speed" but not anything else! My hard disk has a 14ms access time, and think of how much the 25MHz 040 in my now-lowly Quadra 700 could get done during those 350,000 clock cycles. I was under the impression that the CD-ROM driver already did async I/O. Doesn't QuickTime decode and render one frame while it's reading the next one from the disk? > I am driven almost to tears every time I try to get anything done while > doing copies in the Finder (which, contrary to its documentation, can't do > a background copy to save its life) from a slow device because my machine > either comes to a complete screeching halt or behaves so poorly that I > can't get anything done (like typing a news article). You need the "ALLRight" utilities from MSA software. It has a background copying feature (which used to be a standalone utility called COPYright) that makes copies a breeze. Finder copies are forwarded to a small app that runs in the background. It does all its I/O asynchronously, with little CPU hogging even when copying to/from a floppy, a slow file server, or over ARA. It'll do multiple copies at a time, too. The other utilities in the package are not too original (a Helium clone, a very weak SuperBoomerang clone, a BeHierarchic clone, etc.) and have some serious bugs, but the copy utility is worth the price of the package. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From resnick@cogsci.uiuc.edu (Pete Resnick) Date: Wed, 20 Apr 1994 21:47:49 -0500 Organization: University of Illinois at Urbana-Champaign In article <1994Apr21.010358.20490@gallant.apple.com>, jens_alfke@powertalk.apple.com (Jens Alfke) wrote: >Pete Resnick, resnick@cogsci.uiuc.edu writes: >> Why does anyone care about async I/O on a high-speed device other than >> pure sex appeal? On a high-speed device, I/O should happen so quickly that >> calling it async should have no effect to your program. > >By those standards I guess a RAM disk might qualify as "high speed" but not >anything else! My hard disk has a 14ms access time, and think of how much the >25MHz 040 in my now-lowly Quadra 700 could get done during those 350,000 >clock cycles. I agree completely. I was just playing with what Rich Siegel said. Every external device should support asynchronous I/O because every external device is going to be really slow. >> I am driven almost to tears every time I try to get anything done while >> doing copies in the Finder (which, contrary to its documentation, can't do >> a background copy to save its life) from a slow device because my machine >> either comes to a complete screeching halt or behaves so poorly that I >> can't get anything done (like typing a news article). > >You need the "ALLRight" utilities from MSA software. It has a background >copying feature (which used to be a standalone utility called COPYright) that >makes copies a breeze. Finder copies are forwarded to a small app that runs >in the background. It does all its I/O asynchronously, with little CPU >hogging even when copying to/from a floppy, a slow file server, or over ARA. >It'll do multiple copies at a time, too. But why can't the Finder do this?? Why is it that I need yet another patch trapping, memory using (no matter how small) extra utility that does something that could be done infinitely more easily in the Finder, which should have done it in the first place? The code to write this into the Finder itself is trivial. This is just a case of sloppy programming that needs to be fixed, not extra functionality that a third-party program should be solving. pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet: resnick@cogsci.uiuc.edu +++++++++++++++++++++++++++ >From rmcassid@uci.edu (Robert Cassidy) Date: Thu, 21 Apr 1994 12:19:25 -0800 Organization: TLG Project In article , resnick@cogsci.uiuc.edu (Pete Resnick) wrote: [stuff deleted] > >> I am driven almost to tears every time I try to get anything done while > >> doing copies in the Finder (which, contrary to its documentation, can't do > >> a background copy to save its life) from a slow device because my machine > >> either comes to a complete screeching halt or behaves so poorly that I > >> can't get anything done (like typing a news article). > > > >You need the "ALLRight" utilities from MSA software. It has a background > >copying feature (which used to be a standalone utility called COPYright) that > >makes copies a breeze. Finder copies are forwarded to a small app that runs > >in the background. It does all its I/O asynchronously, with little CPU > >hogging even when copying to/from a floppy, a slow file server, or over ARA. > >It'll do multiple copies at a time, too. Well, not to be an ass or anything but COPYright and Copydoubler don't always (do they ever) do asynchronous I/O. Those programs work on my Color Classic and it doesn't support asynch I/O to SCSI. They do their magic just in stolen cycles (it's much slower in the background than in the forground) and actually do their work synchronously (at least on non 040 machines). I know it's picking nits but it is an async discussion... > But why can't the Finder do this?? Why is it that I need yet another patch > trapping, memory using (no matter how small) extra utility that does > something that could be done infinitely more easily in the Finder, which > should have done it in the first place? The code to write this into the > Finder itself is trivial. This is just a case of sloppy programming that > needs to be fixed, not extra functionality that a third-party program > should be solving. Apple has been avoiding this situation in its more recent software (Powertalk at least) in that Powertalk runs as an appe instead of some big hunk of the system. That way it takes cycles just like any app. I think the biggest thing the Mac needs at this time is a threaded OS - spin the copying off on a thread - formatting floppies - launching apps - etc. etc. Apple has done really well in some things and poorly in others, Powertalk is *wonderful* in this regard, PrintMonitor is good, but the finder stuff _rots_. Isn't Apple working on a rewrite of the Finder, though? I thought I heard rumors of that for 7.8 or something (I don't think it is planned for 7.5) -- Robert Cassidy TLG Project UC Irvine Let's hope 'Information SuperTollroad' isn't the catchphrase of the next decade... +++++++++++++++++++++++++++ >From rang@winternet.mpls.mn.us (Anton Rang) Date: 21 Apr 1994 05:54:04 GMT Organization: Minnesota Angsters In article <9404200934.AA46914@Sort-of-a-900.Apple.com> bell@apple.com (Mike Bell) writes: > Having async I/O in a CD ROM driver is very useful. It allows you to do >something with the data that you just read while simultaneously reading >another chunk off of the SLOW CD ROM drive. So, if a program is smart enough >to use multiple async reads from disc, effective throughput is greatly >increased by the async driver. In particular, newer QuickTime versions (from 1.5 or 1.6, I forget which) take advantage of this to overlap i/o and decompression.... -- Anton Rang (rang@winternet.mpls.mn.us) --------------------------- >From srussell@reed.edu (Steven J. Russell) Subject: Comparing 2 LongDateTime's Date: 19 Apr 1994 21:08:02 GMT Organization: Reed College, Portland, Oregon I have a routine that compares two LongDateTime variables and tells me if the first one is before the second one. Unfortunately, it converts the LongDateTime types to LongDateRec types via LongSecs2Date and then compares the old date format values, branching out at the appropriate moment. What I would like to do is skip the conversion to LongDateRec's and then compare the LongDateTime variables that are passed in. Inside Mac: Text says that the LongDateTime is a 64-bit signed representation of the number of seconds since Jan 1, 1904. So, I check the high-bit of both and compare the high-order and low-order longs. Seems to work most of the time. However, I get LongDateTime values that are negative using this scheme (high-order bit set) sometimes even though the date is, for instance, 18 April 1994! Does anybody have code to compare LongDateTime's directly without conversion? BTW, I am doing this for a speed optimization, sincemy program compares dates and times frequently. Thanks, Steven Russell srussell@reed.edu +++++++++++++++++++++++++++ >From resnick@cogsci.uiuc.edu (Pete Resnick) Date: Wed, 20 Apr 1994 00:28:41 -0500 Organization: University of Illinois at Urbana-Champaign In article <2p1h7i$kk9@scratchy.reed.edu>, srussell@reed.edu (Steven J. Russell) wrote: >What I would like to do is skip the conversion to LongDateRec's and then >compare the LongDateTime variables that are passed in. This should be pretty easy. In Script.h is a typedef for LongDateCvt, which gives you the high and low long of each. Here's a routine that returns 1 if the first is greater, -1 if the first is less than, and 0 if the first is equal to the second: short CompareLongDate(LongDateTime *time1, LongDateTime *time2) { LongDateCvt temp1, temp2; short returnVal; temp1.c = *time1; temp2.c = *time2; if(temp1.hl.lHigh > temp2.hl.lHigh) { returnVal = 1; } else if(temp1.hl.lHigh < temp2.hl.lHigh) { returnVal = -1; } else { if(temp1.hl.lLow > temp2.hl.lLow) { returnVal = 1; } else if(temp1.hl.lLow < temp2.hl.lLow) { returnVal = -1; } else { returnVal = 0; } if(temp1.hl.lHigh < 0) { returnVal = -returnVal; } } return returnVal; } Will that do it? pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet: resnick@cogsci.uiuc.edu +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Thu, 21 Apr 1994 11:50:56 +0800 Organization: NCRPDA, Curtin University >What I would like to do is skip the conversion to LongDateRec's and then >compare the LongDateTime variables that are passed in. Inside Mac: Text >says that the LongDateTime is a 64-bit signed representation of the number >of seconds since Jan 1, 1904. So, I check the high-bit of both and compare >the high-order and low-order longs. Seems to work most of the time. However, >I get LongDateTime values that are negative using this scheme (high-order bit >set) sometimes even though the date is, for instance, 18 April 1994! Well, LongDateTime is an 64-bit signed number. But it's very unlikely that it fills more than 48 bits, right? So why not take the bottom 24 bits and the next 24 bits (and ignore the top 16 bits), and compare the top two first, and then the bottom two. This only requires the date to be after 19040101, and before 2^48 seconds after that (8 million years I think :-). type LongLongInt=record hi:longInt; lo:longInt; end; var c1,c2:LongDateTime; l1,l2:LongLongInt; begin l1:=LongLongInt(c1); l1.hi:=BAND(BSL(l1.hi,8),$00FFFF00)+BAND(BSR(l1.lo,16),$000000FF); l1.lo:=BAND(l1.lo,$00FFFFFF); ditto for l2 if l1.hi=l2.hi then return l1.lo Ph: +61 9 368 2055 +++++++++++++++++++++++++++ >From sparent@mv.us.adobe.com (Sean Parent) Date: Thu, 21 Apr 1994 21:17:50 GMT Organization: Adobe Systems Incorporated Since LongDateTime is declared as a comp why not just use ">" - should at least work in MPW C and Pascal. Sean In article , peter.lewis@info.curtin.edu.au (Peter N Lewis) wrote: > > >What I would like to do is skip the conversion to LongDateRec's and then > >compare the LongDateTime variables that are passed in. Inside Mac: Text > >says that the LongDateTime is a 64-bit signed representation of the number > >of seconds since Jan 1, 1904. So, I check the high-bit of both and compare > >the high-order and low-order longs. Seems to work most of the time. However, > >I get LongDateTime values that are negative using this scheme (high-order bit > >set) sometimes even though the date is, for instance, 18 April 1994! > > Well, LongDateTime is an 64-bit signed number. But it's very unlikely > that it fills more than 48 bits, right? So why not take the bottom 24 > bits and the next 24 bits (and ignore the top 16 bits), and compare the > top two first, and then the bottom two. This only requires the date to be > after 19040101, and before 2^48 seconds after that (8 million years I > think :-). > > type LongLongInt=record > hi:longInt; > lo:longInt; > end; > > var > c1,c2:LongDateTime; > l1,l2:LongLongInt; > begin > l1:=LongLongInt(c1); > l1.hi:=BAND(BSL(l1.hi,8),$00FFFF00)+BAND(BSR(l1.lo,16),$000000FF); > l1.lo:=BAND(l1.lo,$00FFFFFF); > ditto for l2 > if l1.hi=l2.hi then > return l1.lo else > return l1.hi end-if > end; > > Something like that anyway, > Peter. > _______________________________________________________________________ > Peter N Lewis Ph: +61 9 368 2055 -- Sean Parent +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Sat, 23 Apr 1994 12:24:01 +0800 Organization: NCRPDA, Curtin University In article , sparent@mv.us.adobe.com (Sean Parent) wrote: >Since LongDateTime is declared as a comp why not just use ">" - should at >least work in MPW C and Pascal. True - but it does it (at least in THINK Pascal) by calling zillions of _Pack4 (SANE) traps. By the look of it, it converts the comp to an 80-bit floating point number and then compares it. Not exactly efficient. I just did a quick test on my LC3, and the SANE code for x Ph: +61 9 368 2055 --------------------------- >From alex@metcalf.demon.co.uk (Alex Metcalf) Subject: Copying graphics the fast way (in assembler) Date: Sat, 23 Apr 1994 18:38:29 GMT Organization: Demon Internet My (cheap) version of CopyBits, in assembler - ------------------------------------------ After I mentioned in a previous note that I had written a custom copy routine, I got flooded with messages asking if I could post it for others to see or use. So, here it is! This code is taken directly from my new arcade game, to be released in the next couple of months. I know it may be possible to make the code faster, but it works fast enough for me. With this and similar routines in my game, I get an increase of up to 500% over CopyBits and CopyMask. This is mainly because I do far less checking than CopyBits does. Also note that (I assume unlike CopyBits) this code may actually draw to the screen when the electron beam is half way down the screen. So, the top half of your graphic may appear slightly after the bottom half. You need to read up on the Vertical Retrace manager and SlotVInstall if you want to "sync" your animation with the electron beam of the screen. The code copies a rectangle from an offscreen graphics world onto the screen. The following assumptions are made: o You're in 32-bit addressing mode o The monitor is in 8-bit (256 colours/grays); 1 byte per pixel o The cursor is hidden o The source and destination rectangles are the same size o The rectangles don't go off the screen or off the GWorld o The rectangles are in coordinates which are local to the screen (i.e. top left of screen is 0,0) There are four globals used: o gWorldPixMapBase is the pix map base address of the graphics world. You use GetGWorldPixMap to get the pix map, and then you use GetPixBaseAddr to get the base address. o gScreenPixMapBase is the pix map base address of the screen. You get the pix map from the GDHandle of the screen you're using. Then you use GetPixBaseAddr. If you're using the main monitor, you can get the GDHandle for that monitor by using GetMainDevice (). o gWorldRowByteCount is the rowBytes for the graphics world. You get it like this: gWorldRowByteCount = (0x7FFF & (**tWorldPixMap).rowBytes); o gScreenRowByteCount is the rowBytes for the screen. You get it like this: gScreenRowByteCount = (0x7FFF & (**tScreenPixMap).rowBytes); I hope the code is useful to someone: you might try using the code, but it's much better if you read through and understand what's happening, and then use parts of it in your own game, animation app, or whatever. If you don't know how to read assembler, an excellent start is this book: How to Write Macintosh Software by Scott Knaster Published by Addison Wesley ISBN 0-201-60805-7 Have fun! Alex Metcalf alex@metcalf.demon.co.uk void RectCopy (Rect tSourceRect, Rect tDestRect) { asm { movem.l a0-a1/d0-d7, -(sp); move.l gWorldPixMapBase, D0; move.w tSourceRect.top, D1; ext.l D1; mulu.l gWorldRowByteCount, D1; add.l D1, D0; move.w tSourceRect.left, D1; ext.l D1; add.l D1, D0; move.l D0, A0; // A0 is the source move.l gScreenPixMapBase, D0; move.w tDestRect.top, D1; ext.l D1; mulu.l gScreenRowByteCount, D1; add.l D1, D0; move.w tDestRect.left, D1; ext.l D1; add.l D1, D0; move.l D0, A1; // A1 is the destination move.w tSourceRect.right, D6; move.w tSourceRect.left, D0; sub.w D0, D6; ext.l D6; // D6 is the width of rect to copy move.l gWorldRowByteCount, D2; sub.l D6, D2; // D2 is the source row offset move.l gScreenRowByteCount, D3; sub.l D6, D3; // D3 is the destination row offset move.w tSourceRect.bottom, D4; move.w tSourceRect.top, D0; sub.w D0, D4; ext.l D4; subq.l #1, D4; // D6 is number of rows to copy moveq.l #4, D5; tst.l D4; ble.s @6; move.l D6, D0; divs.l D5, D0; move.l D5, D7; mulu.l D0, D7; move.l D6, D1; sub.l D7, D1; subq.l #1, D0; subq.l #1, D1; move.l D0, D6; move.l D1, D7; @1; tst.l D0; blt.s @3; @2; move.l (a0)+, (a1)+; dbra d0,@2; @3; tst.l D1; blt.s @5; @4; move.b (a0)+, (a1)+; dbra d1,@4; @5; adda.l D2, A0; adda.l D3, A1; move.l D6, D0; move.l D7, D1; dbra d4,@1; @6; movem.l (sp)+, a0-a1/d0-d7; } } -- 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 am serious... Fax (UK): (0570) 45636 and don't call Fax (US / Canada): 011 44 570 45636 me Shirley." --------------------------- >From jake@dxal13.cern.ch (Bob Jacobsen) Subject: Favorite C++ Book? Date: Wed, 13 Apr 1994 21:50:36 GMT Organization: CERN, the European Organization for Nuclear Research What books do people recommend for C++ on the Mac? Two suggestions have been: 1) Learn C++ on the Macintosh, Dave Mark (1993). Comes with Thin C++ and a cheap (how much?) upgrade offer. 2) Symantec C++ Programming for the Macintosh, Neil Rhodes and Julie McKeehan Neither of these is available at a local bookstore - if you had to order it from the US and wait a month, which would you pick? Bob Jacobsen, jake@afal01.cern.ch +++++++++++++++++++++++++++ >From jaeger@kunikpok.icus.com (Jaeger) Date: Thu, 14 Apr 94 11:36:11 CDT Organization: Kunikpok Kennels and Komputers (Pet Project) jake@dxal13.cern.ch (Bob Jacobsen) writes: > What books do people recommend for C++ on the Mac? > > Two suggestions have been: > > 1) Learn C++ on the Macintosh, Dave Mark (1993). Comes with Thin C++ and a > cheap (how much?) upgrade offer. > > 2) Symantec C++ Programming for the Macintosh, Neil Rhodes and Julie > McKeehan > > Neither of these is available at a local bookstore - if you had to order it > from the US and wait a month, which would you pick? > > Bob Jacobsen, jake@afal01.cern.ch Hi Bob, I can't tell you which one to get but I have the Rhodes and McKeehan book so I can tell you something about it. The book is in three parts: The Symantec environment (120pp), Intro to C++ (200pp), Using TCL (180pp). There are also several appendices, source listings and a disk with all the source from the book. The authors say that the book is a practical approach not a comprehensive approach. Believe them. In my opinion the first section is a waste of space. It repeats the information given in the Symantec manuals. It is perhaps better than the material in the actual manuals :-/ but I think the space could have better been used to increase the size of sections two and three. The Intro to C++ section isn't that bad. It gives you a lot of redundant information about how to use SC++ as does the first section. It tells you how to use the class browser for instance (gee that's a toughie). It has a long discussion of the global optimizer. Apparently the authors wrote the book with a prerelease version of SC++6.0. They go through excruciating detail (dissasembled code) to explain how the global optimizer works and of course they show all the places where it doesn't (didn't?) work. IMHO most of this is useless. The actual intro to C++' is useful and I learned some things from it. It should have been longer and more complete. For example the discussion of multiple inheritance is about 1.5 pages. The discussion of segmentation of your project in the first section is about 2 pages. Which do you think is more important? The third section has six chapters with code examples in each. I would say that these are informative. There are some useful tips about using TCL and using C++ in these chapters. However, this book doesn't cover some of the more advanced features of C++ like templates and friends (and probably others that I've never heard of). I suppose that my problem was that I wanted an in-depth book about C++ that emphasized the Mac, and such a book doesn't exist. There are a couple of annoying things about the book. All the TCL documentation uses the terms 'instance variable' and 'method'. The book uses the terms 'member variable' and 'member function' and never mentions that these are the same thing. Also, the book uses an icon of a 5.25 floppy next to many of the source code examples. I wonder if the authors' 'Macs' use these :-/ Basically I don't think the book is worth US$40. Also it's obsolete now that SC++7 and TCL 2.0 are out. Look for the sequel. Brian Stern }:-{)} Jaeger@fquest.com +++++++++++++++++++++++++++ >From fixer@faxcsl.dcrt.nih.gov (Chris Gonna' Find Ray Charles Tate) Date: Fri, 15 Apr 1994 14:29:11 GMT Organization: DCRT, NIH, Bethesda, MD In addition to learning C++, I'm going to assume you want to learn how to program in an object-oriented manner. This is not trivial; it involves learning a new way of approaching programming, and of thinking about things. I recommend the book "Developing Object-Oriented Software on the Macintosh," by Goldstein and Alger. It's part of the Macintosh Inside-Out series from Addison-Wesley, though I don't have its ISBN number handy. I *do* know that it's Addison-Wesley #57065, list price $24.95. It's an excellent discussion of the theoretical foundations of why object-oriented software development is good, why it's hard to learn, and what you can do about it. The book also presents a (IMHO good) methodology and notation for developing OO software. - ------------------------------------------------------------- Christopher Tate | "So he dropped the heart - MSD, Inc. | the floor's clean." fixer@faxcsl.dcrt.nih.gov | - Sidney Harris +++++++++++++++++++++++++++ >From John Brewer Date: Sat, 16 Apr 1994 16:41:49 GMT Organization: Wolfram Research, Inc. In article Bob Jacobsen, jake@dxal13.cern.ch writes: >What books do people recommend for C++ on the Mac? I'd recommend some general C++ books to start out with. Once you've mastered the syntax and the key concepts of the language, then you can branch out into platform-specific things like GUI frameworks. Trying to do everything at once will result in information overload. If I were teaching a C++ class right now, I'd have the following books be required reading: Lippman, Stanley _The C++ Primer_ (If you don't know C) OR Pohl, Ira(?) _C++ for C Programmers_ (If you do know C) Budd, Timothy _An Introduction to Object Oriented Programming_ The following would be recommended supplemental reading: Meyers, Scott _Effective C++_ You'll probably also want to pick up one or both of the following for reference: Stroustrup, Bjarne _The C++ Programming Language_ Ellis & Stroustrup _The Annotated C++ Reference Manual_ The reason I recommend either Lippman or Pohl is that, while Lippman is probably the better book, it assumes you have no knowledge of C. Since Ihave over a decade of experience with C, I resent being told what a "break" statement is again. I also find that when I try to skip over the stuff I already know, I invariably skip some new stuff by mistake. Pohl assumes you know C, and therefore only covers the differences. I appreciate this approach. Budd is a general book on object-oriented programming. It deals with primarily with general concepts, not syntax, and has examples in C++, Objective C, Object Pascal, and Smalltalk. It introduces the concepts of classes and inheritance, as well as responsibility-driven design and CRC cards. Meyers is the best _second_ book on C++ that I know of. It contains a lot of general tips for writing better code. The introduction alone explained copy constructors better than some entire books. I don't recommend Stroustrup as an introduction to C++, as it is way too terse, but you really need it and/or the ARM as a language reference. Good luck! John Brewer Wolfram Research, Inc. (but speaking for myself) +++++++++++++++++++++++++++ >From nick@pitt.edu ( nick.c ) Date: 20 Apr 94 01:48:56 GMT Organization: (none) In Article , jake@dxal13.cern.ch (Bob Jacobsen) wrote: >What books do people recommend for C++ on the Mac? > >Two suggestions have been: > >1) Learn C++ on the Macintosh, Dave Mark (1993). Comes with Thin C++ and a >cheap (how much?) upgrade offer. Dave's book is good (I have it), but is kind of a "vol 2" to his _Learn_C_on_the_Macintosh_, I think it would be hard to learn from unless you'd read "vol 1". If you're already an ace at C - you'll probably get a lot out of it. I found an interesting book called _Symantec_C++_for_the_Macintosh:_ the_Basics_, by John May and Judy Whittle. It trys to explain C++ without refering to C, and is very specific to the Symantec environment. Unlike the two books you mentioned, this one is stand alone (kind of impressive when you think of what it's trying cover). It's not as detailed as having a seperate book on C, on your environment, and on C++ - but it's very convenient to have most of that info in one cover, and have it all with respect to Symantec's environment. -- nick _/ _/ _/ _/_/_/ _/ _/ Sea Shells to C shells, Waikiki to _/_/ _/ _/ _/ _/ _/_/_/ the Internet, a wave, is a wave... _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/ _/ CompSrv: 71232,766 I-Net: Nick@pitt.edu +++++++++++++++++++++++++++ >From wang_dj@dev.gdb.org (David J. Wang) Date: Thu, 21 Apr 1994 00:24:07 GMT Organization: Genome Database nick.c (nick@pitt.edu) wrote: >In Article , jake@dxal13.cern.ch (Bob >Jacobsen) wrote: >>What books do people recommend for C++ on the Mac? >> >>Two suggestions have been: >> >>1) Learn C++ on the Macintosh, Dave Mark (1993). Comes with Thin C++ and a >>cheap (how much?) upgrade offer. > Dave's book is good (I have it), but is kind of a "vol 2" to his > _Learn_C_on_the_Macintosh_, I think it would be hard to learn from > unless you'd read "vol 1". If you're already an ace at C - you'll > probably get a lot out of it. I have a different opinion about this -- I Learn C on the Macintosh -- and found it to be inadequate in dealing with both C as well as the Macintosh. There is a minimal amount of information dealing with the macintosh (I now have Macintosh C Programming Vol. and wouldn't know what to do without iit -- although I wish I didn't have to pay $30 for the source on disk), and a barely adequate amount of info. dealing with C. I looked through Learn C++... today, and it appeared to be the same situation. I hear from others around here that the Pohl book is very good however, and I own C by Dissection (Pohl, Kelley). -- ************************************************************************* David J. Wang #include wang_dj@gdb.org (410)614-0393 wang_dj@server.cs.jhu.edu Biology@The Johns Hopkins University Baltimore, Maryland 21210 ************************************************************************/ +++++++++++++++++++++++++++ >From bootstrap1@aol.com (Bootstrap1) Date: 23 Apr 1994 22:56:02 -0400 Organization: America Online, Inc. (1-800-827-6364) In Article , jake@dxal13.cern.ch (Bob Jacobsen) wrote: > What books do people recommend for C++ on the Mac? I bought Stroustrup's The C++ Programming Language a few years ago and really didn't care for it. I've looked for a really good book on the subject ever since and last year came across Bruce Eckel's C++ Inside & Out. For me, it hit the nail on the head; it was easy to read, gave good examples, and, best of all, gave insight on the workings of the language behind the scenes, something a lot of C++ books neglect. --------------------------- >From jberry@teleport.com (James D. Berry) Subject: Native PPC Interrupt Control? Date: Thu, 14 Apr 1994 14:57:47 -0700 Organization: Consultant Is there interface level support for disabling interrupts on the PowerMac? I know that application code runs at User Level, but haven't tried hitting the EE bit in the MSR (which I would presume would cause an exception that might or might not get properly emulated). Is this the only level of support? Or is there some hook into the nanokernel to set the interrupt level? This is required to enforce mutual exclusion (since we don't yet have good kernel level support--I want V1/NuKernel!) and I don't want to enter the emulator just to modify the interrupt level. -- James Berry jberry@teleport.com +++++++++++++++++++++++++++ >From creiman@netcom.com (Charlie Reiman) Date: Fri, 15 Apr 1994 07:07:27 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) jberry@teleport.com (James D. Berry) writes: >Is there interface level support for disabling interrupts on the PowerMac? >I know that application code runs at User Level, but haven't tried hitting >the EE bit in the MSR (which I would presume would cause an exception that >might or might not get properly emulated). Is this the only level of >support? Or is there some hook into the nanokernel to set the interrupt >level? >This is required to enforce mutual exclusion (since we don't yet have good >kernel level support--I want V1/NuKernel!) and I don't want to enter the >emulator just to modify the interrupt level. I can't say for sure about disabling interrupts, but I have been attacked by user mode limits on my PPC hacking. If all you need is simple mutex stuff, get a 601 manual and look in the back for the code examples covering mutuexes (mutexi? or is that a breakfast cereal...) Or just look up information on load/store with reservation. -- "You can't cancel the project! We already made the T-shirts!" Charlie Reiman creiman@netcom.com +++++++++++++++++++++++++++ >From rang@winternet.mpls.mn.us (Anton Rang) Date: 16 Apr 1994 00:02:23 GMT Organization: Minnesota Angsters In article creiman@netcom.com (Charlie Reiman) writes: >If all you need is simple mutex stuff, get a 601 manual and look in >the back for the code examples covering mutuexes (mutexi? or is that >a breakfast cereal...) Or just look up information on load/store >with reservation. That works great if you have two competing user-level threads. If you're trying to synchronize against interrupt-level routines (like an I/O completion routine, driver, VBL task), you can't easily use a mutex because there's no convenient way to ask the system to schedule the running task for a later time. Of course, you can always implement your own process scheduler and run everything through it (I did this once for a Nubus card driver back when I was young and foolish). But it's very difficult to make sure that every case is properly handled, and it shouldn't be that much work.... -- Anton Rang (rang@winternet.mpls.mn.us) +++++++++++++++++++++++++++ >From rang@winternet.mpls.mn.us (Anton Rang) Date: 15 Apr 1994 00:23:58 GMT Organization: Minnesota Angsters In article jberry@teleport.com (James D. Berry) writes: >Is there interface level support for disabling interrupts on the PowerMac? There is absolutely no documented way to do this, and I'm very leery of digging into the nanokernel to do it. I've had several engineers from Apple tell me that I shouldn't even think about it. No word yet on whether this will be added at some point, though I've heard that the group working on porting the Appletalk protocol stack has requested such a capability. I understand *why* they don't want people messing with interrupts (especially with Geoport support and such), but at the same time, it's a major bottleneck in the driver-level work I'm doing. >This is required to enforce mutual exclusion (since we don't yet have good >kernel level support--I want V1/NuKernel!) and I don't want to enter the >emulator just to modify the interrupt level. And if you enter the emulator, it only modifies the emulator's interrupt level. You can still get low-level interrupts, though I believe that currently all system-call-back interrupts (e.g. VBL tasks, Time Manager, etc.) go through the emulator and thus obey the restriction. I need mutual exclusion for a memory pool (darn Memory Manager won't run at interrupt time :-), and an allocation/free pair which takes 4us in PPC code takes nearly 100us if I switch into and out of emulation for it. Really sucks. Anyone from Apple listening to our pleas? (Anyone with the $$$ to be an Apple Partner who might have clout enough to let us call the nanokernel for this until NuKernel is out?) -- Anton Rang (rang@winternet.mpls.mn.us) >From Eric Anderson Subject: Native PPC Interrupt Control? Date: Tue, 19 Apr 1994 03:06:46 GMT Organization: Apple Computer Re: Native PPC Interrupt Control? Yes, folks here at Apple are listening to your pleas. In fact, if you look at the native Thread Manager, you will note the lack of preemptive threads - this is because the native interrupt runtime model is not exported outside the kernel. Yes, we need to wait for the new kernel before we get such native niceties as native interrupt handling (in some form(s)) to provide better I/O and tasking services both inside Apple and from our developer community. Eric Anderson Mac OS Apple Computer, Inc. +++++++++++++++++++++++++++ >From benh@fdn.org (Benjamin Herrenschmidt) Date: Tue, 19 Apr 94 23:01:05 +0100 Organization: (none) > >In article (comp.sys.mac.programmer), rang@winternet.mpls.mn.us (Anton Rang) writes: > >In article jberry@teleport.com (James D. Berry) writes: >>Is there interface level support for disabling interrupts on the PowerMac? > > There is absolutely no documented way to do this, and I'm very leery >of digging into the nanokernel to do it. I've had several engineers >from Apple tell me that I shouldn't even think about it. No word yet >on whether this will be added at some point, though I've heard that >the group working on porting the Appletalk protocol stack has >requested such a capability. > > I understand *why* they don't want people messing with interrupts >(especially with Geoport support and such), but at the same time, it's >a major bottleneck in the driver-level work I'm doing. > >>This is required to enforce mutual exclusion (since we don't yet have good >>kernel level support--I want V1/NuKernel!) and I don't want to enter the >>emulator just to modify the interrupt level. > > And if you enter the emulator, it only modifies the emulator's >interrupt level. You can still get low-level interrupts, though I >believe that currently all system-call-back interrupts (e.g. VBL >tasks, Time Manager, etc.) go through the emulator and thus obey the >restriction. > > I need mutual exclusion for a memory pool (darn Memory Manager won't >run at interrupt time :-), and an allocation/free pair which takes 4us >in PPC code takes nearly 100us if I switch into and out of emulation >for it. Really sucks. > > Anyone from Apple listening to our pleas? (Anyone with the $$$ to be >an Apple Partner who might have clout enough to let us call the >nanokernel for this until NuKernel is out?) >-- >Anton Rang (rang@winternet.mpls.mn.us) I completely agree with you ! as a Nubus card driver designer and a low level developper (i work on drivers, interrupts, network software etc...), a way to mask interrupts is VERY important. It is the only way to do some tasks at interrupt level. Another VERY important thing is to be able to do atomic read-test-modify like the TAS instruction of the 68K to do semaphores. They are REQUIRED to work with "resources" shared between several processors. (main processor and a DSP for example). It would be a VERY BAD thing from apple to remove the ability of having uninterruptible pieces of code and atomic semaphores. I hope Apple will soon release a technote with everything we MUST know about these. (remeber that not all macintoshes support the TAS instruction which is really a pain when you have to build an interface between the mac and another processor, on a PDS card for example). Hey, Apple ! do you listen to us ? will you do it ? BenH. +++++++++++++++++++++++++++ >From mrustad@aol.com (MRustad) Date: 23 Apr 1994 01:05:05 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <01050105.tk4phy@tatooine.fdn.org>, benh@fdn.org (Benjamin Herrenschmidt) writes: >I hope Apple will soon release a technote with everything we MUST >know about these. (remeber that not all macintoshes support the TAS >instruction which is really a pain when you have to build an interface >between the mac and another processor, on a PDS card for example). Ben, TAS is not all that important. I did the multiprocessor interlocking for A/ROSE and could not use TAS at all anywhere (even for single processor locks) due to nasty bus error conditions that could arise with the 68000 coprocessors. In previous positions I worked on CDC Cybers that had a bunch of processors in the box and nothing remotely like a TAS. There are lots of neat tricks that really work better than TAS anyway. Of course, you can continue to use the emulator, which does TAS for you, if it is that important to you (but my stuff will run faster than yours!). -Mark Rustad, mdr@apple.com --------------------------- >From walkerm@acf2.nyu.edu (Michael A. Walker) Subject: SetDialogDefaultItem in a modal dialog Date: Wed, 20 Apr 1994 09:15:01 -0500 Organization: New York University Hi. Please forgive this question if it's a FAQ. I'm trying to use SetDialogDefaultItem for a modal dialog and I'm having some problems (well, one problem--it's not working ;-). Within my routine that displays the dialog, I call SetDialogDefaultItem as I'm suppose to do. The problem comes in when I call ModalDialog using my own dialog filter which is used to control a read-only scrolling text region. Somehow, the call to SetDialogDefaultItem is reversed or ignored since I added the dialog filter. Here is a snippet of the code: void ShowAbout(void) { DialogPtr dialog; Boolean dialogDone = false; short itemHit, itemType; /* deleted stuff */ dialog = GetNewDialog(kAboutResID, nil, kMoveToFront); SetDialogDefaultItem(dialog, ok); SetDialogTracksCursor(dialog, true); /* deleted stuff */ ShowWindow(dialog); SetPort(dialog); GetDItem(dialog, ok, &itemType, &okItemHandle, &itemRect); /* you guessed it, more deleted stuff */ while (! dialogDone) { ModalDialog(AboutDlgFilter, &itemHit); switch (itemHit) { case ok: dialogDone = true; break; } } DisposDialog(dialog); } Is there something else I have to do? Thanks in advance. -- Michael A. Walker New York University walkerm@acf2.nyu.edu ==============================================------------------------8-; main() {int x,y,k;char *b=" .:,;!/>)|&IH%*#@";double cr,ci,zr,zi,temp,cx,cy; for(y=30;puts(""),cy=y*0.1-1.5,y-->=0;){for(x=0;cx=x*0.04-2,zr=0,zi=0,x++<75;) {for(cr=cx,ci=cy,k=0;temp=zr*zr-zi*zi+cr,zi=2*zr*zi+ci,zr=temp,k<112;k++) if(zr*zr+zi*zi>10)break;printf("%c",b[k%16]);}}} /* try this on for size!! */ +++++++++++++++++++++++++++ >From Kevin.R.Boyce@gsfc.nasa.gov (Kevin R. Boyce) Date: Wed, 20 Apr 1994 12:46:05 -0400 Organization: NASA/GSFC In article , walkerm@acf2.nyu.edu (Michael A. Walker) wrote: > Hi. Please forgive this question if it's a FAQ. I'm trying to use > SetDialogDefaultItem for a modal dialog and I'm having some > problems (well, one problem--it's not working ;-). Within my > routine that displays the dialog, I call SetDialogDefaultItem > as I'm suppose to do. The problem comes in when I call > ModalDialog using my own dialog filter which is used to control > a read-only scrolling text region. Somehow, the call to > SetDialogDefaultItem is reversed or ignored since I added the > dialog filter. You didn't include your dialog filter, but I bet it doesn't call the standard filter proc. Here's one that doesn't handle any dialog events, but correctly passes update events on to other windows (this is taken almost verbatim from the "Pending Update Perils" technote): pascal Boolean BasicDlogFilter( DialogPtr currentDialog, EventRecord *theEventIn, short *theDialogItem) { OSErr myErr; ModalFilterProcPtr standardProc; Boolean returnVal = false; WindowPtr temp; if( (theEventIn->what == updateEvt) && (theEventIn->message != (long)currentDialog) ) { returnVal = DoUpdate(theEventIn); /* go to my update routine */ } else { GetPort(&temp); SetPort(currentDialog); myErr = GetStdFilterProc((ProcPtr)&standardProc); if(!myErr) returnVal = standardProc( currentDialog, theEventIn, theDialogItem ); SetPort(temp); } return(returnVal); } (Apologies if the formatting is screwed up. Boy I wish NewsWatcher handled tabs correctly. Time to take another look at the source...) -- Kevin Kevin.R.Boyce@x500.gsfc.nasa.gov You can blow out a candle, but you can't blow out a fire. Once the flame begin to catch, the wind will blow it higher. --Peter Gabriel, 1980 (_Biko_) +++++++++++++++++++++++++++ >From Stephan Bublava Date: 21 Apr 1994 06:08:54 GMT Organization: Vienna University of Technology In article Michael A. Walker, walkerm@acf2.nyu.edu writes: >Hi. Please forgive this question if it's a FAQ. I'm trying to use >SetDialogDefaultItem for a modal dialog and I'm having some >problems (well, one problem--it's not working ;-). >[snip] >Somehow, the call to SetDialogDefaultItem is reversed or ignored >since I added the dialog filter. You must call the default filter from your modal dialog filter. How to to this is described in the TechNote that describes the new Dialog Manager routines. Stephan -- Stephan Bublava stephan@iguwnext.tuwien.ac.at --------------------------- >From baileyc@gmg.com (Christopher R. Bailey) Subject: Symantec has an FTP site! Date: 22 Apr 1994 15:34:28 GMT Organization: DejaView Software, Inc. Maybe most of you already know this, but I didn't and I've never seen anything about it. I was sick of waiting for the CPlusLib update from Symantec for 7.0. So I called them, and the guy told me to ftp to their site: devtools.symantec.com Sure enough it was there, along with all the other updates. Now, why couldn't Symantec post on here telling us about that? I realize they may not want their ftp machine getting loaded up, but if they don't, then they should have posted it to Sumex (as if we can get in there). I wasted a phone call, as well as I've probably now started that totally lame limited 90 days of support crap that they've started. What a joke! (Hmm, it seems Symantec bashing is now a required part of every post on these groups :) -- ________________________________________________________ Christopher Bailey Work: baileyc@dejaview.com Software Engineer Home: baileyc@beetle.com DejaView Software Inc. http://bigmac.gmg.com/ --------------------------- >From Ben J Fry Subject: pascal and c libraries Date: Tue, 19 Apr 1994 21:31:59 -0400 Organization: Freshman, Design, Carnegie Mellon, Pittsburgh, PA is there any way to write a function in think pascal and have it available for use in a think c project? how would this be done, and how would you do the opposite, compiling something in c and calling it from pascal? thanks in advance... ben bf2c+@andrew.cmu.edu +++++++++++++++++++++++++++ >From ingemar@lysator.liu.se (Ingemar Ragnemalm) Date: 22 Apr 1994 09:24:52 GMT Organization: (none) Ben J Fry writes: >is there any way to write a function in think pascal and have it >available for use in a think c project? how would this be done, and how >would you do the opposite, compiling something in c and calling it from >pascal? Both are quite possible. I've even had projects where I write a lib mostly in Pascal, but calling a C-lib (for the inline assembler). Then I make a library of it, so my C-using friend can use it. That means that the code has three layers, C-Pascal-C! Using C from Pascal is simple. The C functions must be declared "Pascal". You build a library and write an interface file. Using Pascal from C takes a bit more, mostly due to limitations in the Think compilers, and very poor documentation. (May I say "bugs"?) You build a library from the Pascal code and convert it with oConv. BUT something is wrong with how either Think Pascal sets the function names or how oConv converts them, so capitalization might get wrong. You can fix that by checking the ".v" box, edit the .v file to he correct capitalization in the cases where you get problems, and then oConv again, still with ".v" checked. BUT your Pascal library might rely on some of Think Pascal's built-in functions, usually LMUL and LDIV. The fix I've been recommended, and that I am using, is to include uRuntime.lib in the Pascal library. This works just great with Think C 5. (Note that Symantec's support people seem to know nothing about how to do this.) BUT Think C version 6 has a bug in its linker! If you include uRuntime.lib, you get a link error telling you that a function isn't defined - a function that is in the ROM's since 1984! (MaxApplZone if I remember right.) This can be fixed by opening the library and remove a segemnt that is named %_TOOLBOX (or something like that). BUT that is only possible using Think C 5! If you don't have Think C 5, you'll have to ask someone who has it to do it. I guess we could convert uRuntime.lib to a C library and remove it, and post... BUT is that legal, or is it breaking some copyright that Symantec has? If you have Think C 5, it isn't a big problem. The whole problems should be simpler with CodeWarrior. Can anyone confirm that? -- - - Ingemar Ragnemalm, PhD Image processing, Mac shareware games E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se --------------------------- End of C.S.M.P. Digest **********************