From: pottier@clipper.ens.fr (Francois Pottier)
Subject: csmp-digest-v3-025, resend
Date: Tue, 10 May 94 17:15:09 MET DST
Hi,
Issue 25 of the digest contains some binhexed files, which reportedly
caused some dumb mailers to extract the binhex codes and delete the rest.
I have removed the faulty thread; here is a "clean" digest.
Francois
pottier@dmi.ens.fr
------
C.S.M.P. Digest Tue, 10 May 94 Volume 3 : Issue 25
Today's Topics:
CodeWarrior GOLD DR-2 - Can't seem to generate fast FP code
Determining if user is on a network
Sample Think C AE Code
drawing arrowheads
writing an INIT... a few questions
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 bcorrie@csr.UVic.CA (Brian Corrie)
Subject: CodeWarrior GOLD DR-2 - Can't seem to generate fast FP code
Date: 15 Apr 94 20:51:55 GMT
Organization: University of Victoria
G'day,
I just recently got my CodeWarrior Gold. I wrote a simple application that
does a bunch of floating point calculations (sin, cos, sqrt, *, / etc.)
to test the speed of my PowerMac 6100/60 compared to an RS6000 and SPARC
10 at work. Timings below:
RS6000 2.4 seconds
SPARC10 4.8 seconds
Quadra840AV 40 seconds
PowerMac 6100 53 seconds???????
Now obviously this code is running in emulation mode (at least I hope so
or I will be a bit bummed out 8-). The weird thing is that I CAN NOT get
this to change. I am running the PPC version of the compiler, I set the
preferences to what I think they should be to generate native PowerPC code,
use what I think are the right libraries, and lo and behold, it runs slow.
Now I am probably missing something obvious, and you are probably saying
RTFM, but really, I have spent the last two days trying to figure this out!
Reading the manual, talking to someone who has a bit more Mac expereince
than I do, etc. Still no luck. What am I doing wrong???? Any ideas?
Is there something obvious that I have to do. Did I install things
incorrectly? Is there a special library I need to use to take advantage
of the PPC floating point hardware? ARGGGHHHH. I want to say "look how
fast my machine is" but I can't at the moment!!!!!
Any and all pointers, even those exposing my stupidity, are welcome.
Cheers,
Brian
--
Brian Corrie (bcorrie@csr.uvic.ca)
Under the most rigorously controlled conditions of pressure, temperature,
volume, humidity and other variables, the organism will do as it damn well
pleases. Sounds like some of the code I have written...... 8-)
+++++++++++++++++++++++++++
>From usenet@lowry.eche.ualberta.ca (Brian Lowry)
Date: 15 Apr 1994 22:12:20 GMT
Organization: Chem Eng - Univ of Alberta
In article <bcorrie.766443115@tara>, bcorrie@csr.UVic.CA (Brian Corrie)
wrote:
> I just recently got my CodeWarrior Gold. I wrote a simple application that
> does a bunch of floating point calculations (sin, cos, sqrt, *, / etc.)
> to test the speed of my PowerMac 6100/60 compared to an RS6000 and SPARC
> 10 at work. Timings below:
>
> RS6000 2.4 seconds
> SPARC10 4.8 seconds
> Quadra840AV 40 seconds
> PowerMac 6100 53 seconds???????
Since sin, cos, and sqrt aren't supported by the PPC601, what sort of
speed did you expect? Obviously you're calling SANE routines while the IBM
is calling efficent PPC routines. You'd probably see a speed improvement
with even relatively inefficient sin/cos/sqrt algorithms.
--
Brian Lowry
+++++++++++++++++++++++++++
>From bcorrie@csr.UVic.CA (Brian Corrie)
Date: 16 Apr 94 00:20:22 GMT
Organization: University of Victoria
usenet@lowry.eche.ualberta.ca (Brian Lowry) writes:
>In article <bcorrie.766443115@tara>, bcorrie@csr.UVic.CA (Brian Corrie)
>wrote:
>> I just recently got my CodeWarrior Gold. I wrote a simple application that
>> does a bunch of floating point calculations (sin, cos, sqrt, *, / etc.)
>> to test the speed of my PowerMac 6100/60 compared to an RS6000 and SPARC
>> 10 at work. Timings below:
>>
>> RS6000 2.4 seconds
>> SPARC10 4.8 seconds
>> Quadra840AV 40 seconds
>> PowerMac 6100 53 seconds???????
> Since sin, cos, and sqrt aren't supported by the PPC601, what sort of
>speed did you expect? Obviously you're calling SANE routines while the IBM
>is calling efficent PPC routines. You'd probably see a speed improvement
>with even relatively inefficient sin/cos/sqrt algorithms.
Care to elaborate a bit on that? Like I said, I am not a Mac programmer
and don't know a lot about SANE, but it doesn't make much sense that
my PowerMac is SLOWER than a Quadra840 when the code on the PowerMac
is native PowerPC code. Surely the sin and cos functions are implemented
using the native PowerPC code and isn't being implemented as emmulated
020 code!?!?!?
How does one expect to take advantage of the floating point speed of the
PowerPC architecture if basic mathematical functions like sin, cos, and
sqrt are not implemented natively. Seems rather silly to me. Am I out to
lunch on this one???? Is their not a native implementation of SANE? I was
expecting to get an execution time of below ten seconds based on what I
have read about the PowerPC specs.
Any insights. Can someone set me straight, this doesn't make sense to me.
Brian (stressed about his slow PowerMac) Corrie
Brian
--
Brian Corrie (bcorrie@csr.uvic.ca)
Under the most rigorously controlled conditions of pressure, temperature,
volume, humidity and other variables, the organism will do as it damn well
pleases. Sounds like some of the code I have written...... 8-)
+++++++++++++++++++++++++++
>From bcorrie@csr.UVic.CA (Brian Corrie)
Date: 16 Apr 94 01:18:07 GMT
Organization: University of Victoria
Dave Falkenburg <falken@apple.com> writes:
>In article <usenet-150494160853@lowry.eche.ualberta.ca> Brian Lowry,
>usenet@lowry.eche.ualberta.ca writes:
Brian Corrie originally wrote:
>>> I just recently got my CodeWarrior Gold. I wrote a simple application that
>>> does a bunch of floating point calculations (sin, cos, sqrt, *, / etc.)
>>> to test the speed of my PowerMac 6100/60 compared to an RS6000 and SPARC
>>> 10 at work. Timings below:
>>>
>>> RS6000 2.4 seconds
>>> SPARC10 4.8 seconds
>>> Quadra840AV 40 seconds
>>> PowerMac 6100 53 seconds???????
>>
>> Since sin, cos, and sqrt aren't supported by the PPC601, what sort of
>>speed did you expect? Obviously you're calling SANE routines while the IBM
>>is calling efficent PPC routines. You'd probably see a speed improvement
>>with even relatively inefficient sin/cos/sqrt algorithms.
>>
>>--
>>
>>Brian Lowry
>Remember that MW DR/2 doesn't generate really optimal code (yet). You're not
>calling SANE, you are just executing non-optimzied code on a RISC machine.
I realize that the code optimization isn't the best, but surely running
native code on a PowerPC should run faster than a Quadra840 with a
68881?2. If not, I want my money back!!!! Seriously, if the sin, cos,
sqrt are running as native code and not being emulated as 020 through
SANE or some such bizarre twist, then why can't the PowerPC beat a
Quadra 840. Even if I turn off optimization and turn on debugging
and profiling on the SPARC10 I get a run time of 7.9 seconds. Still a
ton and a half less than 53. We are talking an order of magnitude
difference when I would expect them to be in the same ball park.
Almost all 3D graphics use sin, cos, and sqrt extensively. How can all
those native 3D programs claim massive speedups over high end Quadras
when I am getting worse performance!?! It just don't make sense mon,
I am still convinced that I am doing something ridiculously stoopid.
Please, someone just tell me what it is! 8-)
>If you compile on AIX with "-lm" and ship the code back over to your PowerMac
>you should see VERY nice performance improvements.
>Also: Were you using the Apple mathlib?
I was using the MathLib that comes with the CW DR/2 release, whatever
that is. It seems to me that I must be using the wrong library, but
its beyond me which one I should be using....
I will play some more with the compiler tonight and report further on
this "drama"
Cheers,
Brian
--
Brian Corrie (bcorrie@csr.uvic.ca)
Under the most rigorously controlled conditions of pressure, temperature,
volume, humidity and other variables, the organism will do as it damn well
pleases. Sounds like some of the code I have written...... 8-)
+++++++++++++++++++++++++++
>From Chuck Browne <chuck@molecule.physics.drexel.edu>
Date: Sat, 16 Apr 1994 02:37:14 GMT
Organization: Drexel Univ. Physics
In article <usenet-150494160853@lowry.eche.ualberta.ca> Brian Lowry,
usenet@lowry.eche.ualberta.ca writes:
> Since sin, cos, and sqrt aren't supported by the PPC601, what sort of
>speed did you expect? Obviously you're calling SANE routines while the
IBM
>is calling efficent PPC routines. You'd probably see a speed improvement
>with even relatively inefficient sin/cos/sqrt algorithms.
Well, in the MW manual, it says about SANE for the PowerMacs:
"SANE is dead."
Are you using the math library with <fp.h>? I believe that is what you
should be using. Not that I would really know, as I don't have a PowerMac
(although I will be able to test some calcs next week on one), but
since when has not knowing what you're talking about been a crime on
usenet? :-)
Anyway, I don't know if you're using the ANSI libs. They're probably
slower than the math library...
Chuck
+++++++++++++++++++++++++++
>From Dave Falkenburg <falken@apple.com>
Date: Fri, 15 Apr 1994 23:58:13 GMT
Organization: Apple Computer, Inc.
In article <usenet-150494160853@lowry.eche.ualberta.ca> Brian Lowry,
usenet@lowry.eche.ualberta.ca writes:
>> I just recently got my CodeWarrior Gold. I wrote a simple application
that
>> does a bunch of floating point calculations (sin, cos, sqrt, *, / etc.)
>> to test the speed of my PowerMac 6100/60 compared to an RS6000 and
SPARC
>> 10 at work. Timings below:
>>
>> RS6000 2.4 seconds
>> SPARC10 4.8 seconds
>> Quadra840AV 40 seconds
>> PowerMac 6100 53 seconds???????
>
> Since sin, cos, and sqrt aren't supported by the PPC601, what sort of
>speed did you expect? Obviously you're calling SANE routines while the
IBM
>is calling efficent PPC routines. You'd probably see a speed improvement
>with even relatively inefficient sin/cos/sqrt algorithms.
>
>--
>
>Brian Lowry
Remember that MW DR/2 doesn't generate really optimal code (yet). You're
not
calling SANE, you are just executing non-optimzied code on a RISC machine.
If you compile on AIX with "-lm" and ship the code back over to your
PowerMac
you should see VERY nice performance improvements.
Also: Were you using the Apple mathlib?
-Dave Falkenburg
-Apple Computer, Inc.
+++++++++++++++++++++++++++
>From rang@winternet.mpls.mn.us (Anton Rang)
Date: 16 Apr 1994 01:56:31 GMT
Organization: Minnesota Angsters
In article <bcorrie.766443115@tara> bcorrie@csr.UVic.CA (Brian Corrie) writes:
>I just recently got my CodeWarrior Gold. I wrote a simple application that
>does a bunch of floating point calculations (sin, cos, sqrt, *, / etc.)
>to test the speed of my PowerMac 6100/60 compared to an RS6000 and SPARC
>10 at work. Timings below:
Aha! You have discovered Apple's Incredibly Inefficient Trig
Functions. They're so bad that, as you discovered, the 840AV is
faster. The cure is to write your own, snarf the library from the
RS/6000 (probably legal issues involved), or curse Apple until they
fix it. (Hmm.)
Check the timing of add/multiply and you'll see it's way faster than
any 68000. So if Apple even used the same algorithms that the 68882
uses (or heck, even SANE) it would be faster. :(
--
Anton Rang (rang@winternet.mpls.mn.us)
+++++++++++++++++++++++++++
>From johnmce@world.std.com (John McEnerney)
Date: Sat, 16 Apr 1994 07:16:19 GMT
Organization: The World Public Access UNIX, Brookline, MA
usenet@lowry.eche.ualberta.ca (Brian Lowry) writes:
>In article <bcorrie.766443115@tara>, bcorrie@csr.UVic.CA (Brian Corrie)
>wrote:
>> I just recently got my CodeWarrior Gold. I wrote a simple application that
>> does a bunch of floating point calculations (sin, cos, sqrt, *, / etc.)
>> to test the speed of my PowerMac 6100/60 compared to an RS6000 and SPARC
>> 10 at work. Timings below:
>>
>> RS6000 2.4 seconds
>> SPARC10 4.8 seconds
>> Quadra840AV 40 seconds
>> PowerMac 6100 53 seconds???????
> Since sin, cos, and sqrt aren't supported by the PPC601, what sort of
>speed did you expect? Obviously you're calling SANE routines while the IBM
>is calling efficent PPC routines. You'd probably see a speed improvement
>with even relatively inefficient sin/cos/sqrt algorithms.
This should not be true. When using sin(), cos() etc. one normally links
against the MathLib shared library from Apple. These routines were
supposedly coded for high performance.
-- John McEnerney, Metrowerks PowerPC Product Architect
+++++++++++++++++++++++++++
>From jwbaxter@olympus.net (John W. Baxter)
Date: Fri, 15 Apr 1994 20:36:24 -0700
Organization: Internet for the Olympic Peninsula
In article <bcorrie.766459087@tara>, bcorrie@csr.UVic.CA (Brian Corrie)
wrote:
> I was using the MathLib that comes with the CW DR/2 release, whatever
> that is. It seems to me that I must be using the wrong library, but
> its beyond me which one I should be using....
That should be the right one (and should actually mean that you're running
the ROM-based fragment).
What data type are you using for your floating point? float and double are
good (supported, except for some operations, by the chip)...long double is
not (done in software). If you are using long double (and even more if you
are using one of the extended types left over from the old days), I'd
suggest you switch to double_t. When compiled for PPC, that gives you
double (64-bit); when compiled for 68K Mac, it gives you long double (80 or
96 bit depending upon FPU setting). On PPC compiles, long double is the
[somewhat strange] 128-bit format.
--
John Baxter Port Ludlow, WA, USA [West shore, Puget Sound]
jwbaxter@pt.olympus.net
+++++++++++++++++++++++++++
>From somogyi@macuser.ziff.com (Stephan Somogyi)
Date: Sat, 16 Apr 1994 17:24:31 GMT
Organization: MacUser Magazine US
In article <CoCC78.D3r@world.std.com>, johnmce@world.std.com (John
McEnerney) wrote:
> When using sin(), cos() etc. one normally links against the MathLib
> shared library from Apple. These routines were supposedly coded for
> high performance.
A fellow from Apple said in the PowerPC Talk area on AppleLink that they
are aware of MathLib's bad trig performance and are working on resolving
the problem. For the time being, the prudent thing to do seems to be to
get another trig implementation.
__________________________________________________________________________
Stephan Somogyi "Davidian Inside" MacUser
+++++++++++++++++++++++++++
>From squeegee@world.std.com (Stephen C. Gilardi)
Date: Sat, 16 Apr 1994 20:20:08 GMT
Organization: SQ Software via The World Public Access UNIX, Brookline, MA
oliver@psy.fsu.edu (Bill Oliver) writes:
>I've also been looking at the floating point performance of CodeWarrior
>C code on my Centris 660AV Mac. I've compiled a test program using the
>various ANSI881 libraries with what I believe are the appropriate
>compiler options. The program takes *twice* as long to exectute than
>the same program compiled on a NeXT Cube, which has the same CPU (25MHz
>68040).Obviously, I must be doing something wrong. Are there any
>example programs available (with projects) that illustrate how to get
>fast FP code from CW?
If you just include math.h, then all trig functions, logs, etc. will
be calculated using SANE. If you #define __FASTMATH__ and/or
__HYBRIDMATH__ before include math.h, then the 68881 will be used
directly for those functions (at the expense of the extra error
checking and control which you get with SANE).
However, I believe there is a bug in the DR/2 math.h which makes those
#defines not have the desired effect.
Here's a portion of the bug report I sent:
[I think math.h is wrong...]
Here's how I think the relevant portion of math.h should read:
#ifdef __FASTMATH__
#define log(x) _log(x)
#define log10(x) _log10(x)
#endif
#ifdef __HYBRIDMATH__
#define sin(x) _sin(x)
#define cos(x) _cos(x)
#define tan(x) _tan(x)
#define asin(x) _asin(x)
#define acos(x) _acos(x)
#define atan(x) _atan(x)
#define sinh(x) _sinh(x)
#define cosh(x) _cosh(x)
#define tanh(x) _tanh(x)
#define exp(x) _exp(x)
#define sqrt(x) _sqrt(x)
#define fabs(x) _fabs(x)
#define fmod(x,y) _fmod((x),(y))
#define ldexp(x,n) _ldexp((x),(n))
#endif
I believe that the underscores indicate direct calls to the 68881.
With it defined as I suggest, the MATH macros work as documented.
--Steve
+++++++++++++++++++++++++++
>From rang@winternet.mpls.mn.us (Anton Rang)
Date: 17 Apr 1994 02:39:15 GMT
Organization: Minnesota Angsters
In article <CoCC78.D3r@world.std.com> johnmce@world.std.com (John McEnerney) writes:
>This should not be true. When using sin(), cos() etc. one normally links
>against the MathLib shared library from Apple. These routines were
>supposedly coded for high performance.
Hmm. Well, they ought to be, but another poster earlier (on
c.s.powerpc) gave me a benchmark to run on the 8100/80, and it
indicated that sin/cos are *very* slow compared to almost any other
implementation. A few selected rows from the table he sent --
Machine MFLOPS FLOPS/sin()
- ----- ------ -----------
Cray-2 45.06 18.43
PowerMac 8100/80 (Apple SDK beta) 37.50 1223.88
IBM RS6000/550 22.22 25.89
PowerMac 8100/80 (Metrowerks 1.0a1) 14.28 464.98
IBM RS6000/320H 13.51 28.15
The MFLOPS is calculated in a tight loop where the multiply-add can be
used to advantage, thus the relatively high performance. The compiler
makes a considerable difference here due primarily to loop unrolling,
which allows better instruction scheduling, and the use of the
load-with-update instructions by the Apple SDK compiler.
FLOPS/sin() is the relative performance of a loop which calls sin()
instead of doing multiplication/addition. Note the incredibly slow
performance....
--
Anton Rang (rang@winternet.mpls.mn.us)
+++++++++++++++++++++++++++
>From Dave Falkenburg <falken@apple.com>
Date: Mon, 18 Apr 1994 21:08:56 GMT
Organization: Apple Computer, Inc.
In article <CoCC78.D3r@world.std.com> John McEnerney,
johnmce@world.std.com writes:
>This should not be true. When using sin(), cos() etc. one normally links
>against the MathLib shared library from Apple. These routines were
>supposedly coded for high performance.
>
>-- John McEnerney, Metrowerks PowerPC Product Architect
My bet is that they are coded to be highly accurate, so that when someone
decides to build a bridge or an airplane using a Mac it won't fail due to
a rounding error.
Lawyers are great, aren't they?
BTW: One of the NuCalc guys typed up a REALLY fast version of mathlib
that is less accurate, but MUCH faster. Think about table lookup and
interpolation. He probably wouldn't want you to design his next car with
it, however.
-Dave Falkenburg
-Apple Computer, Inc.
+++++++++++++++++++++++++++
>From bcorrie@csr.UVic.CA (Brian Corrie)
Date: 20 Apr 94 20:39:44 GMT
Organization: University of Victoria
ViviStar@ACM.org (Jonathan Hess) writes:
>In article <bcorrie.766459087@tara>
>bcorrie@csr.UVic.CA (Brian Corrie) writes:
>> Almost all 3D graphics use sin, cos, and sqrt extensively. How can all
>> those native 3D programs claim massive speedups over high end Quadras
>> when I am getting worse performance!?! It just don't make sense mon,
>> I am still convinced that I am doing something ridiculously stoopid.
>> Please, someone just tell me what it is! 8-)
>While it is besides the point of this thread I would tend to disagree
>with the statement that "almost all 3D graphics use sin, cos, and sqrt
>extensively." Successfully fast packages avoid sin, cos, and sqrt as
>much as possibly. You can rewrite the basic tranform and projection
>equations to where the 1 required trig operation can be computed and
>stored in a constant once per projection.
Hmm, I guess my previous post demonstrates that my
fingers do fly faster than my brain (which implies my brain ain't
to fast because I can't type!!! 8-). On thinking about it, I agree,
sin and cos are not used very often in graphics code. I was thinking
of shading calculations that can use trig functions, but on reflection
they rarely use sin/cos as there are usually more efficient ways
of doing the computation (on reflection, shading...hmmm, a bit of a pun...!)
>Ray tracers are another story since they have to do a lot more
>calculations with angles of incidence and things.
Even ray tracers can get away with using dot product, cross product etc.
and rarely use sin/cos. It is just convenient to think of them as sin/cos
as I did above.
Anyway, back to the thread of hacking down the slow sin/cos routines on
the PowerMacs. I still say that it is ridiculous for a Quadra 840 to
be faster than a PowerMac on native floating point sin/cos calculations.
Still no insights as to what I am doing wrong, if anything. Are sin/cos
really that slow on the PowerMacs???
Cheers,
Brian
--
Brian Corrie (bcorrie@csr.uvic.ca)
Under the most rigorously controlled conditions of pressure, temperature,
volume, humidity and other variables, the organism will do as it damn well
pleases. Sounds like some of the code I have written...... 8-)
>From eric.larson@f620.n2605.z1.fidonet.org (eric larson)
Subject: CodeWarrior GOLD DR-2 - Can't seem to generate fast FP code
Date: 20 Apr 94 18:52:00 -0500
Organization: FidoNet:* File Edit View Label Special ? D (1:2605/620)
> In article <CoCC78.D3r@world.std.com> John McEnerney,
>>This should not be true. When using sin(), cos() etc. one normally links
>>against the MathLib shared library from Apple. These routines were
>>supposedly coded for high performance.
> My bet is that they are coded to be highly accurate, so that when
> someone decides to build a bridge or an airplane using a Mac it won't
> fail due to a rounding error.
Butbutbut why would Seymour Cray ship a machine that produces lousy floating
point results? These things are generally used for simulations far more heavily
than an Mac ever is.
Meethinks this should be investigated carefully.
+++++++++++++++++++++++++++
>From rmcassid@uci.edu (Robert Cassidy)
Date: Thu, 21 Apr 1994 12:41:21 -0800
Organization: TLG Project
In article <bcorrie.766874384@tara>, bcorrie@csr.UVic.CA (Brian Corrie)
wrote:
[stuff deleted]
> Even ray tracers can get away with using dot product, cross product etc.
> and rarely use sin/cos. It is just convenient to think of them as sin/cos
> as I did above.
>
> Anyway, back to the thread of hacking down the slow sin/cos routines on
> the PowerMacs. I still say that it is ridiculous for a Quadra 840 to
> be faster than a PowerMac on native floating point sin/cos calculations.
> Still no insights as to what I am doing wrong, if anything. Are sin/cos
> really that slow on the PowerMacs???
Since sometimes you *have* to do a lot of sin/cos work I don't think these
functions should be ignored. I'm toying with the idea of writing a fp
library (probably mostly trig) that would calculate w.r.t. a determined
precision. I remember writing programs on the VAX at school that seemed
unbelievably slow at sin/cos. It turned out that I was getting far more
precision than I needed. I rewrote the routines and got something like a
10x speed improvement. Often you don't need a lot of precision
(particularly with graphics) so why do all of the work of calculating what
you don't use? If there is interest in this I may pursue it further (of
course I have to get a PM first! :-)
--
Robert Cassidy
TLG Project
UC Irvine
Let's hope 'Information SuperTollroad' isn't the catchphrase of the next
decade...
+++++++++++++++++++++++++++
>From AppleGG@lamg.com (Gordon Apple)
Date: 22 Apr 1994 12:16:21 -0800
Organization: (none)
Since sometimes you *have* to do a lot of sin/cos work I don't think these
functions should be ignored. I'm toying with the idea of writing a fp
library (probably mostly trig) that would calculate w.r.t. a determined
precision. I remember writing programs on the VAX at school that seemed
unbelievably slow at sin/cos. It turned out that I was getting far more
precision than I needed. I rewrote the routines and got something like a
10x speed improvement. Often you don't need a lot of precision
(particularly with graphics) so why do all of the work of calculating what
you don't use? If there is interest in this I may pursue it further (of
course I have to get a PM first! :-)
The fastest way to generate sin and cos is with a look-up table. If
you're doing statistical communications simulations, or doing a software
modem, the table size deoesn't have to be very large for your error noise to
be swamped by the input noise. You can build the table from SANE or whatever
else is handy when you need it. If you need more precision, use of the above
table in conjunction with the double-angle formula gives highly accurate
results with minimal computation. We have used these techniques for years in
simulations and in DSPs. They are extremely computationally efficient. In
fact, if you write it for a PowerPC processor, you could pipeline the
process, using both the integer and floating point units at the same time.
That sucker should scream with that type algorithm.
G. Gordon Apple, PhD
Advanced Communications Engineering, Inc.
Redondo Beach, CA
+++++++++++++++++++++++++++
>From usenet@lowry.eche.ualberta.ca (Brian Lowry)
Date: 24 Apr 1994 00:08:46 GMT
Organization: Chem Eng - Univ of Alberta
It really isn't so hard to code efficent sin/cos/sqrt routines. There
are complete reference books with excellent algorithms (for much more
difficult functions than sin or cos). If anyone wants simple sin, cos, and
sqrt routines which are on the order of optimal (in C, no doubt assembly
would be faster), then just send me e-mail.
--
Brian Lowry
---------------------------
>From mkelly@cs.uoregon.edu (Michael A. Kelly)
Subject: Determining if user is on a network
Date: 25 Apr 1994 15:26:26 -0700
Organization: High Risk Ventures
Hey,
Is there any way to determine if a machine is on a local network? I can
find out if AppleTalk is on, but that doesn't tell me if the machine is
part of a network.
Thanks,
Mike.
--
_____________________________________________________________________________
Michael A. Kelly President/CEO
mkelly@cs.uoregon.edu High Risk Ventures
_____________________________________________________________________________
+++++++++++++++++++++++++++
>From mxmora@unix.sri.com (Matt Mora)
Date: 26 Apr 1994 10:44:04 -0700
Organization: SRI International, Menlo Park, CA
In article <2phg2i$9lb@majestix.cs.uoregon.edu> mkelly@cs.uoregon.edu (Michael A. Kelly) writes:
>
>Hey,
>
>Is there any way to determine if a machine is on a local network? I can
>find out if AppleTalk is on, but that doesn't tell me if the machine is
>part of a network.
Here you go.
/*
Sample code to demonstrate use of the LAP Manager call to determine
the current connection type i.e LocalTalk, EtherTalk phase 1/2, or
TokenTalk phase 2.
Rich Kubota
DTS
*/
#include <Types.h>
#include <string.h>
#define LGetATalkInfo 0x09 /* Get AppleTalk info */
/* 'atlk' resource ID's of Apple supplied driver software. */
#define LTalk 0
#define ETalkPh1 2
#define TTalkPh2 5
#define ETalkPh2 10
#define LAPMgrPtr 0xB18
#define LAPMgrCall 2
#include "GetADEVType.h"
pascal long CallLAPMgr(short selector)
{
asm{
MOVE.W selector,D0 ; move selector parameter into D0
MOVE.L A2,-(A7) ; store A2 on stack
MOVEA.L LAPMgrPtr,A2 ; Set A2 to address of LAP Mgr.
JSR LAPMgrCall(A2) ; Call LAP Manager
MOVE.L D1,0x0A(A6) ; Place result onto stack
MOVE.L (A7)+,A2 ; Restore A2
UNLK A6 ; restore stack frame
MOVEA.L (A7)+,A0 ; put return address into A0
ADDQ.W #0x02,A7 ; clear off the parameter
JMP (A0) ; return to caller
RTS
}
}
void CheckNetType(char * resultStr)
{
long result;
char adevType;
char slot;
//Debugger();
result = CallLAPMgr(LGetATalkInfo);
adevType = result & 0x000000FF; /* atlk resource id is return in LSB */
slot = result>>24; /* card slot returned in MSB */
switch (adevType) {
case LTalk:
strcpy(resultStr,"LocalTalk");
break;
case ETalkPh1:
strcpy(resultStr,"EtherTalk phase 1");
break;
case ETalkPh2:
strcpy(resultStr,"EtherTalk phase 2");
break;
case TTalkPh2:
strcpy(resultStr,"TokenTalk");
break;
default:
strcpy(resultStr,"Unrecognized connection");
break;
}
}
Warning. I never could get this to work on all systems.
Xavier
--
___________________________________________________________
Matthew Xavier Mora Matt_Mora@sri.com
SRI International mxmora@unix.sri.com
333 Ravenswood Ave Menlo Park, CA. 94025
---------------------------
>From neath@brazil.psych.purdue.edu (Ian Neath)
Subject: Sample Think C AE Code
Date: Wed, 20 Apr 1994 13:18:15 GMT
Organization: Purdue University
As an amateur programmer trying to stay on the cutting edge
of yesterday's technology, I'm trying to implement AE and
custom AE into some apps. I can't find much sample C code,
though. Any suggestions for locations (already tried
sumex, etc.) greatly appreciated. (We rarely get alt.sources.
mac here)
--
Ian Neath | There are four kinds of people in this world:
neath@psych.purdue.edu | cretins, fools, morons and lunatics - U. Eco
+++++++++++++++++++++++++++
>From Deirdre Maloy <Deeny3@aol.com>
Date: Wed, 20 Apr 1994 18:24:07 GMT
Organization: Metro Information Services, Raleigh NC
I remember that I found precious little about SENDING custom apple
events. On the off chance this'll help, here's a sample sending code and
receiving code (which go in two different apps). Despite the debug code,
they do work -- one app sends another app the info about a file to
launch, waits for an acknowledgement from the receiving app, then renames
itself and quits. When the first app detects that the other app quit, it
eats it. I had to do this for complicated reasons relating to auto-update
version control experimentation. <g> All our applications are launched by
the program we call "Itty" which is a faceless app that acts as a
switchboard for apple events between our applications -- you can send an
apple event to the Itty for an application that's not launched. It will
then launch the app and forward the message when the app is ready to
receive. This set of events is just designed for one app to tell the Itty
to launch another app and when--though the when is controlled elsewhere.
_Deirdre
On receiving end:
#include "Launcher.h"
#include <Aliases.h>
extern Boolean highPriority;
extern launchRecord myLaunchInfo[MAX_SUBLAUNCHES]; // info on where
app is located
extern short currentLaunch;
extern Str255 myFile; // name of current document
pascal OSErr myHandleItty(AppleEvent *ittyEvent, AppleEvent *replyEvent,
long refCon)
{
OSErr myErr;
AEDesc myDesc;
long actualSize;
DescType actualType;
long count;
AEDescList myIttyList;
AEKeyword myKeyword;
DescType myType;
Str32 myString;
highPriority = TRUE;
myErr = AEGetParamPtr(ittyEvent, 'app ', 'fss ',
&myType, (Ptr) &myLaunchInfo[currentLaunch].appName,
(long) sizeof(FSSpec), &actualSize);
myErr = HGetVol(myString,&myLaunchInfo[currentLaunch].appName.vRefNum,
&myLaunchInfo[currentLaunch].appName.parID);
myErr = AEGetParamPtr(ittyEvent, 'doc ', 's255',
&myType, (Ptr) &myFile, (long) sizeof(Str255), &actualSize);
if (myErr != noErr)
myFile[0] = 0;
CopyPString("\pHowdy",myString);
myErr = AEPutParamPtr(replyEvent, keyErrorString, typeChar,
(Ptr)&myString[1], myString[0]);
SysBeep(3);
return (noErr);
}
#include "Teeny.h"
#include <EPPC.h>
#include <AppleEvents.h>
extern FSSpec myAppLoc; // info on where doc to open is located
extern Str255 myDocPath;
extern ProcessSerialNumber PSN;
extern Boolean gQuit;
void getIttyPSN(ProcessSerialNumber *ittyPSN, OSType ittySig);
pascal Boolean MyIdleFunction(EventRecord *event,
long *sleepTime, RgnHandle *mouseRgn);
void sendIttyAE(void)
{
// Here's all the garbage you will need.
OSType ittyType = 'I???', ittyMsg = 'l8tr';
AEAddressDesc ittyDesc;
AEDescList myIttyList;
AEDesc myApp, myDoc;
AppleEvent myAppleEvent, myAEreply;
short iErr;
ProcessSerialNumber ittyPSN;
EventRecord myEvent;
// create the address descriptor record.
iErr = AECreateDesc(typeApplSignature, (Ptr)&ittyType,
sizeof(ittyType), &ittyDesc);
// exit if there's an error
if (iErr != noErr)
goto Sayonara;
// For the IttyBitty, the Apple Event TYPE should be 'I???',
// which is also IttyBitty's signature. The Event ID should be one of
the following:
// 'imed' Launch this application IMMEDIATELY.
// 'delo' Delete file.
// 'l8tr' Launch this application when I quit.
// (no other events defined)
//
// in all cases, a parameter list is required
// 'app ' for application to launch (fsspec expected)
// 'doc ' for document to launch with app (Str255 expected)
// 'fss ' for any other fsspec
iErr = AECreateAppleEvent(ittyType, ittyMsg, &ittyDesc,
kAutoGenerateReturnID,
kAnyTransactionID, &myAppleEvent);
if (iErr != noErr)
goto Sayonara;
iErr = AEPutParamPtr(&myAppleEvent, 'app ', 'fss ', (Ptr) &myAppLoc,
(long) sizeof(FSSpec));
if (myDocPath[0] > 2)
iErr = AEPutParamPtr(&myAppleEvent, 'doc ', 's255', (Ptr) myDocPath,
(long) sizeof(Str255));
// We should be OK to send the apple event now.
iErr = AESend(&myAppleEvent, &myAEreply, kAEWaitReply+kAECanInteract,
kAEHighPriority, 720, &MyIdleFunction, 0L);
WaitNextEvent(0x2, &myEvent, 40L, 0);
if (iErr == noErr) SysBeep(3); // to let user know AppleEvent was sent
gQuit = TRUE; // our task is done, the AppleEvent was sent
Sayonara:
AEDisposeDesc(&ittyDesc);
AEDisposeDesc(&myAppleEvent);
AEDisposeDesc(&myAEreply);
}
// prototype your routine like this prior to calling it
// NOTE that it uses pascal calling conventions since it is called
// from the AESend routine
pascal Boolean MyIdleFunction(EventRecord *event,
long *sleepTime, RgnHandle *mouseRgn);
// Application global variable to keep track of cursor rgn
RgnHandle gCursorRgn;
pascal Boolean MyIdleFunction(EventRecord *event,
long *sleepTime, RgnHandle *mouseRgn)
{
char hiByte;
OSErr myErr;
switch ( event->what )
{
case updateEvt:
case activateEvt: // every idle function should handle
case app4Evt: // these kinds of events
SetFrontProcess(&PSN);
break;
case nullEvent:
// set the sleeptime and mouseRgn parameters
*mouseRgn = gCursorRgn;
*sleepTime = 10; // use the correct value for your app
SystemTask(); // the application's idle handling
SystemTask(); // the application's idle handling
SystemTask(); // the application's idle handling
break;
}
return FALSE;
}
In article <CoK7MF.9Lq@mozo.cc.purdue.edu> Ian Neath,
neath@brazil.psych.purdue.edu writes:
>As an amateur programmer trying to stay on the cutting edge
>of yesterday's technology, I'm trying to implement AE and
>custom AE into some apps. I can't find much sample C code,
>though. Any suggestions for locations (already tried
>sumex, etc.) greatly appreciated. (We rarely get alt.sources.
>mac here)
--
Deirdre Maloy, Metro Information Services, Raleigh NC
"My employer pays me for my opinions; you get them free."
+++++++++++++++++++++++++++
>From john40@aol.com (John40)
Date: 22 Apr 1994 19:25:02 -0400
Organization: America Online, Inc. (1-800-827-6364)
In article <CoK7MF.9Lq@mozo.cc.purdue.edu>, neath@brazil.psych.purdue.edu (Ian
Neath) writes:
>As an amateur programmer trying to stay on the cutting edge
>of yesterday's technology, I'm trying to implement AE and
>custom AE into some apps. I can't find much sample C code,
>though. Any suggestions for locations (already tried
>sumex, etc.) greatly appreciated. (We rarely get alt.sources.
>mac here)
Get yourself a copy of UserLand Frontier's SDK 3.0. It's packed with useful
Apple Events stuff. The code is even free to use in your own programs
(no royalty, and its source code can even by distributed if you don't change it
- this is
according to their documentation). You can get the SDK from BBSs such as
America Online
or by buying Frontier.
John Schlack
+++++++++++++++++++++++++++
>From eschen@molbio.cbs.umn.edu (Art Eschenlauer)
Date: Sun, 24 Apr 1994 18:04:22 GMT
Organization: University of Minnesota, Twin Cities
Today I noted in the MERIT Macintosh software archives at umich:
/mac/development/libraries/aebuilder1.1.cpt.hqx (134K)
A ThinkC 5.0 kit to help construct and call Apple Events.
Very thorough and helpful. [Description theirs, not mine.]
--
eschen@molbio.cbs.umn.edu (Art Eschenlauer,
U of M Agronomy and Plant Genetics Dept.)
---------------------------
>From dacton@beak.com (Dan Acton)
Subject: drawing arrowheads
Date: 25 Apr 1994 08:36:10 -0600
Organization: Beak Consultants Ltd.
Has anyone out there figured out how to draw nice arrowheads on the ends of
lines similar to MacDraw, SuperPaint, Canvas, etc.? I've written a routine
which uses QuickDraw arcs and some trigonometry and everyone says they look
terrible.
********************************************
Sent via BeakNet
Beak Consultants Limited, Electronic Mail Network
42 Arrow Road
Guelph, Ontario, CANADA
(519) 763-BEAK (voice)
(519) 763-2378 (FAX)
********************************************
+++++++++++++++++++++++++++
>From sw@network-analysis-ltd.co.uk (Sak Wathanasin)
Date: Tue, 26 Apr 94 00:12:12 GMT
Organization: Network Analysis Ltd
In article <1407844318.11694@beaknet1.beak.com> (comp.sys.mac.programmer), dacton@beak.com (Dan Acton) writes:
> Has anyone out there figured out how to draw nice arrowheads on the ends of
> lines similar to MacDraw, SuperPaint, Canvas, etc.? I've written a routine
> which uses QuickDraw arcs and some trigonometry and everyone says they look
> terrible.
Oh well, I might as well get my code pulled apart. It's not
particularly efficient, but I only have to draw these occasionally. All
suggestions for improvement gratefully received. This has been pulled
from a MacApp prog; just assume that everything has been declared
appropriately. The consts were worked out using a desk calculator...
The method computes a QD poly, and is called whenever the start/end
points change. When I have to refresh the view, I call
PaintPoly(fArrowHead) after I draw the connecting line.
Set tabstops=4 for proper alignment.
pascal void
TEPConnection::CalcArrows (void)
{
const extended kDeg2Rad = 0.01745329252; // for converting degrees to radians
const extended kArrowLength = 10.0; // length of arrowhead
const extended kArrowAngle = kDeg2Rad * 30.0; // angle arrow makes with line
short angle; // angle between connecting line & vertical axis
Rect r;
// bounding box of agent
Point apex = fEndPt; // point of the arrow
Point pt2, pt3; // corners of the arrow
r.left = fStartPt.h - 10;
r.top = fStartPt.v - 10;
r.right = fStartPt.h + 10;
r.bottom= fStartPt.v + 10; // concoct a square around the start pt
PtToAngle(&r, apex, &angle); // calc angle of connecting line
extended rangle = (extended)(90-angle) * kDeg2Rad;
// the angle in radians // the angle in radians
extended temp = rangle - kArrowAngle;
pt2.h = (short)((extended)apex.h - (kArrowLength * cos(temp)));
pt2.v = (short)((extended)apex.v + (kArrowLength * sin(temp)));
temp = rangle + kArrowAngle;
pt3.h = (short)((extended)apex.h - (kArrowLength * cos(temp)));
pt3.v = (short)((extended)apex.v + (kArrowLength * sin(temp)));
if (fArrowPoly != NULL) {
KillPoly(fArrowPoly); // get rid of prev arrow
fArrowPoly = NULL;
}
PolyHandle arrowPoly = OpenPoly();
FailNULL(arrowPoly);
MoveTo(apex.h, apex.v);
LineTo(pt2.h, pt2.v);
LineTo(pt3.h, pt3.v);
LineTo(apex.h, apex.v);
ClosePoly();
fArrowPoly = arrowPoly;
// reset the bounding box
// ... some code to compute the bounding box, which you probably don't need
}
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 jadams@eng.umd.edu (Josh Adams)
Subject: writing an INIT... a few questions
Date: 22 Apr 1994 16:14:32 GMT
Organization: Project GLUE, University of Maryland, College Park
Hi,
I am a somewhat new Mac programmer. I have written some apps, but now I want
to write an INIT (I think). I was wondering a few things:
1) Is there some info somewhere that documents how to do this and ant
background info I should have about things like memory and registers
and such?
2) If I want to patch a trap for all applications, but I want to have a
window constantly displaying stuff, should I have an init to patch the
trap(s) and then have it launch an app at startup, then send info from
the patched trap to my app with Apple Events? Would there be a better
way? I couldn't imagine that it would be good to have the init make
a window...
3) What does it mean to detach a resource? Would this affect me?
4) What registers do I have to care about?
5) Is there a way to access the small black line at the bottom of the
menu bar? Like if I drew something there, the menu would just erase
over it, right? Is there a way to change the line to be more than one
color? (Just wondering... I probably won't need to, but it is interesting
to know.
Thanks for all replies and info,
Stu
+++++++++++++++++++++++++++
>From Aaron Wohl <aw0g+@andrew.cmu.edu>
Date: Mon, 25 Apr 1994 07:18:46 -0400
Organization: Systems Group 97, Carnegie Mellon, Pittsburgh, PA
For the source code to three inits look in host akutaktak.andrew.cmu.edu
[128.2.35.1] /aw0g/*.hqx.
Excerpts from netnews.comp.sys.mac.programmer: 22-Apr-94 writing an
INIT... a few qu.. Josh Adams@eng.umd.edu (1094)
> 1) Is there some info somewhere that documents how to do this and ant
> background info I should have about things like memory and registers
> and such?
Not that I know of. I guess I should write a how to write an
INIT/DRVR/CDEV faq...
Excerpts from netnews.comp.sys.mac.programmer: 22-Apr-94 writing an
INIT... a few qu.. Josh Adams@eng.umd.edu (1094)
> 2) If I want to patch a trap for all applications, but I want to have a
> window constantly displaying stuff,
The patch code needs to live in the system heap (otherwise multifinder
will swap the patch out when it switches applications). The patch
should probably post it's information to a device driver. The
application should read it from the driver. I don't know enough about
apple events to know what problems there would be in using them. I
suspect that there would be difficulties in getting the port for apple
events to not be closed when the applicaiton that was running when it
was opened quit.
Excerpts from netnews.comp.sys.mac.programmer: 22-Apr-94 writing an
INIT... a few qu.. Josh Adams@eng.umd.edu (1094)
> 3) What does it mean to detach a resource? Would this affect me?
A code resource (the code for an INIT) is still attached to the resource
map for the init file. If you don't detach it (with DetachResource)
the code block will be reused when the mac os cleans up after your init
starts and it goes on to the next init. Rather than detach the init
code I prefer to have the init install anouther code resource. That way
the installation part of the init code is freeed as it should be.
Excerpts from netnews.comp.sys.mac.programmer: 22-Apr-94 writing an
INIT... a few qu.. Josh Adams@eng.umd.edu (1094)
> 4) What registers do I have to care about?
For an init in general you don't have to worry about it. Except if you
are using think c (which I recommend) you need to set up the A4
register. See the init code in the softkiss driver for a good example
of dealing with this.
---------------------------
End of C.S.M.P. Digest
**********************