rlcarr@athena.mit.edu (Richard L. Carreiro) (11/07/90)
I sent mail to the Maple people asking them what's up, and here's the reply: Date: Tue, 6 Nov 90 12:47:01 GMT From: Joyce Brennan <jbrennan@daisy.waterloo.edu> To: rlcarr@ATHENA.MIT.EDU Subject: Re: Maple for Amiga Cc: jbrennan@daisy.waterloo.edu > From rlcarr@ATHENA.MIT.EDU Mon Nov 5 18:39 EST 1990 > From: rlcarr@ATHENA.MIT.EDU > To: wmsi@daisy > Subject: Maple for Amiga > > Hello, > > I would like to know what the status of Maple for the Amiga is. > Specifically, > a) is 4.4 being ported to the Amiga? > b) if so, any estimated time of completion? We have a programmer who is currently working on porting Maple V, our newest software release, to the Amiga. This version of Maple features 3-D graphics and several other user interface enhancements. Maple V is expected to be released on the Amiga platform in the first quarter of 1991. Here is the latest report from our technical department: The kernel of Maple is finished. The projected user interface would be very similar to the X Maple. In fact, our idea is to copy the X Maple features into the Amiga machine. This will be finalized once I receive and read through all the manuals. For the graphics part, we will have both POSTSCRIPT and the IFF format. > c) if so, will 4.4 have any support for the 68881/2 math coprocessor? In an effort to accommodate the needs of all Amiga users, this new version will probably not support the math coprocessor (since many Amiga machines are not equipped with this coprocessor). -----end of reply---- This last bit I really disagree with. Considering the purpose of Maple, and its price relative to Amiga software in general, I really, really doubt people with non-accelerated machines are going to be the people who would be that interested Maple. I'd be willing to bet that of the people who would be interested in buying Maple V, that most would have 68881 or 68882 coprocessors. Casually throwing away a factor of 10 speedup annoys me. Heck, I assume they're doing double precision math in their code, so why not use the CBM math libraries - then those with the chips get the advantage, and it'll still work on those without the chips. And on Amigas without accelerator cards, things'll be slow enough that the overhead of mathieeedoub*.library probably won't matter. It's too bad - I've seen Maple 4.4 on Suns, and it's REALLY nice. I'm willing to spend the $400+ for Maple V on the Amiga, but I can't justify it if the program will not take advantage of a major part of my machine - a part which is designed to do high-precision math quickly. Am I outta line feeling this way? Comments folks? -- Rich Carreiro The "War on Drugs" ARPA: rlcarr@athena.mit.edu is merely a smokescreen for UUCP: ...!mit-eddie!mit-athena!rlcarr The War on the Constitution BITNET: rlcarr@athena.mit.edu JITTLOV FOREVER!
a143@mindlink.UUCP (Ed Meyer) (11/07/90)
> rlcarr@athena.mit.edu writes: > > Msg-ID: <1990Nov6.191819.13114@athena.mit.edu> > Posted: 6 Nov 90 19:18:19 GMT > > Org. : the mind of Mike Jittlov > Person: Richard L. Carreiro > > I sent mail to the Maple people asking them what's up, and here's the > reply: > [ ... ] > > [ ... reply ... ] > We have a programmer who is currently working on porting Maple V, our > newest software release, to the Amiga. This version of Maple features > 3-D graphics and several other user interface enhancements. Maple V > is expected to be released on the Amiga platform in the first quarter > of 1991. > [ ... ] > In an effort to accommodate the needs of all Amiga users, this new > version will probably not support the math coprocessor (since many > Amiga machines are not equipped with this coprocessor). > > -----end of reply---- > > This last bit I really disagree with. Considering the purpose of [ ... ] > Am I outta line feeling this way? Comments folks? > > -- > Rich Carreiro The "War on Drugs" > ARPA: rlcarr@athena.mit.edu is merely a smokescreen for > UUCP: ...!mit-eddie!mit-athena!rlcarr The War on the Constitution > BITNET: rlcarr@athena.mit.edu JITTLOV FOREVER! Rich, for what it's worth, I agree that the creators of Maple should be able to, with very little effort, accommodate the coprocessor (6888x). At the very least, they can make two versions: one for system with coprocessor and one without. It's might be easier to make a version that installs with a choice or installs "automagically." To see the such talented people, who can create Maple, saying they are not going to support the coprocessor is almost inconceivable. But, they have that right.
don@brahms.udel.edu (Donald R Lloyd) (11/09/90)
I seem to remember hearing that under 2.0 the floating point libraries
would be able to detect the presence of an 881/882 and use it if it's there.
(Or is this one specific fp library?). If this is true, and 2.0 actually
starts shipping soon, Maple will have 881 support whether they like it or not.
I agree that it sounds just plain stupid to produce a mathematical
program with no FPU support. I've never done any FP work on a system with
a coprocessor, but isn't it just a matter of changing a #include or an
openlibrary() call somewhere?
--
Gibberish Soon to be Amiga 3000 owner/fanatic! (I hope)
is spoken Contact don@brahms.udel.edu for more information.
here. DISCLAIMER: It's all YOUR fault.zerkle@iris.ucdavis.edu (Dan Zerkle) (11/10/90)
In article <15580@brahms.udel.edu> don@brahms.udel.edu (Donald R Lloyd) writes: > > I seem to remember hearing that under 2.0 the floating point libraries >would be able to detect the presence of an 881/882 and use it if it's there. >(Or is this one specific fp library?). If this is true, and 2.0 actually >starts shipping soon, Maple will have 881 support whether they like it or not. 2.0 has nothing to do with it. See below. > I agree that it sounds just plain stupid to produce a mathematical >program with no FPU support. I've never done any FP work on a system with >a coprocessor, but isn't it just a matter of changing a #include or an >openlibrary() call somewhere? No, that's not it. The 68881 and 68882 have their own special instruction set. When you have one of these math chips, you can mix these special instructions in with the regular 680x0 instructions in your machine language. That way, the 680x0 instructions get executed by your CPU, and your 6888x instructions get executed by your FPU. If you don't have an FPU, you have to emulate the floating point instructions in software. This works, but is not nearly as fast. A certain graphics program I wrote runs about 10 times faster (no exaggeration) when I use the 68882. In other words, getting math chip support is very important to those folks who own one and who do a large amount of number crunching. When you write a program, there are two basic places executable code comes from. The first place is from code you write/compile/assemble yourself. The second place is from libraries that you link in. If you want the code you compile yourself to have 6888x instructions in it, instead of simply emulating the instructions, you need to tell your compiler to generate code for it. In Aztec C, this is done by putting a little "-f8" flag on the command line. This is important if the code you write yourself does a lot of math. If you want your libraries to use the chip, you have to use the proper libraries in the link stage. Using these libraries is important if you do a lot of math through function calls, such as the trig functions. There are numerous libraries included with the compiler (taking up numerous disk blocks). These are the important ones I found with Aztec C: m.lib : Standard math library, without coprocessor support. m8.lib : Manx's math library, using the 6888x. I can't use this one, due to a vicious bug in the scanf() found there. ma.lib : Amiga IEEE double precision math library. It's not documented, but several people have told me that this one detects the presence or absence of a math chip at runtime and behaves accordingly at. This would mean that this library uses larger executables and is a little slower than directly using either of the above libraries. Since Maple is written in C, all the programmers would really have to do is compile two different versions using two different compile and link commands. They could use the Amiga IEEE libraries, and thereby have a version that would take advantage of the math support when using library calls, but still run on all machines. Hope this helps (TM). Dan Zerkle zerkle@iris.ucdavis.edu (916) 754-0240 Amiga... Because life is too short for boring computers.
sjorr@lion.uwaterloo.ca (Stephen Orr) (11/11/90)
In article <7960@ucdavis.ucdavis.edu> zerkle@iris.ucdavis.edu (Dan Zerkle) writes: >No, that's not it. The 68881 and 68882 have their own special >instruction set. When you have one of these math chips, you can mix >these special instructions in with the regular 680x0 instructions in >your machine language. That way, the 680x0 instructions get executed >by your CPU, and your 6888x instructions get executed by your FPU. Remember that the software emulating math libraries, from 1.3 onward will detect a math co-processor, and re-direct requests through them. While this isn't as fast as inline code, it is more machine independant. However, this doesn't solve the Maple problem, because Maple have their own custom math libraries. >If you don't have an FPU, you have to emulate the floating point >instructions in software. This works, but is not nearly as fast. A >certain graphics program I wrote runs about 10 times faster (no >exaggeration) when I use the 68882. In other words, getting math chip >support is very important to those folks who own one and who do a >large amount of number crunching. And here we come to the whole point of it. It turns out that Maple, despite being an advanced math package, does VERY LITTLE actual number crunching. Maple deals with just about everything symbolically, and only does fp substitutions as the last step. According to a friend of mine who is on the Maple team here at Waterloo, the only place that a math co-pro is really going to affect the speed is in the 3-D graphics stuff, and he's going to talk to them about that part. Stephen Orr
stefanb@cip-s02.informatik.rwth-aachen.de (Stefan Becker) (11/12/90)
don@brahms.udel.edu (Donald R Lloyd) writes: > I seem to remember hearing that under 2.0 the floating point libraries >would be able to detect the presence of an 881/882 and use it if it's there. >(Or is this one specific fp library?). If this is true, and 2.0 actually >starts shipping soon, Maple will have 881 support whether they like it or not. A Mapel programmer told me that it doesn't use ANY floating point numbers. All math is done with fractions of two integer numbers. Stefan Mail : Stefan Becker, Holsteinstrasse 9, W-5100 Aachen /// Only Phone : +49-241-505705 FIDO: 2:242/7.6 Germany /// Amiga makes Domain: stefanb@cip-s02.informatik.rwth-aachen.de \\\/// it possible.. Bang : ..mcvax!unido!rwthinf!cip-s02!stefanb \XX/ -->A3000/25<--
giguere@csg.uwaterloo.ca (Eric Giguere) (11/14/90)
In article <stefanb.658363453@cip-s02> stefanb@cip-s02.informatik.rwth-aachen.de (Stefan Becker) writes: >A Maple programmer told me that it doesn't use ANY floating point numbers. All >math is done with fractions of two integer numbers. Well, in most cases yes... Maple is above all a SYMBOLIC math package. but there are NUMERIC functions available and they use floating point... anyhow, here's some info for you: Good news for Maple fans... this evening we (the University of Waterloo Amiga Users' Group) had a demo of the Maple V for the Amiga. This is not a beta or a product, it was just a demo of the current status of the project. Anyhow, the Maple kernel is definitely ported, as was mentioned before. You could do all the usual stuff from the simple command line interface. We were also shown a prototype for a smarter interface with a history window, etc. If you've seen the X Windows version of Maple V then it's pretty close to that interface... The interesting part of the demo were the graphics and plotting features. A standalone program is responsible for that -- it will be communicating with the kernel through IPC. This all runs under 2.0 so they were using gadtools for development (seems they found some bugs in gadtools though). He showed us a graph with hidden surfaces being viewed in different positions and so on. It was all pretty neat. A lot of work remains to be done, though, mostly on the user interface and graphics portions. A full ARexx port is going to be added... requirements are Workbench 2.0, 2 megs of RAM and about 20 megs of disk space. No one knows what the price will be. Neat stuff... -- Eric Giguere giguere@csg.UWaterloo.CA Quoth the raven: "Eat my shorts!" --- Poe & Groening