Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!okstate!minich
From: minich@a.cs.okstate.edu (MINICH ROBERT JOHN)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Reforming Mac Programming (longish, ~60 lines)
Message-ID: <5492@okstate.UUCP>
Date: 26 Mar 90 20:50:52 GMT
References: <13828@eagle.wesleyan.edu>
Organization: Oklahoma State Univ., Stillwater
Lines: 118

From article <13828@eagle.wesleyan.edu>, by bparsia@eagle.wesleyan.edu:
> Someone mentioned in another post in another group (the post part of the "why
> can't Apple ][ users accept the mac" thread) that the bewildering variety of
> Macintoshs has lead to an unacceptable set of conditions one must check and
> take into account when programming. Color QuickDraw is one example of such a
> condition. I was wondering what could be done to simplfy programming the Mac
> for everyone except the ROM and system programmers (sorry, someone has to
> suffer). Some things (like CQD) have to be taken care of by the appl.
> programmer (if you are writing a color paint package, you'd better make the
> color calls), but other conditions should be transparant, as far as possible,
> to the "end" programmer.
> 
> For example, numeric coprocessors. THINK Pascal (along with most other 
> packages I hope) has a 68881 compile option which generates optimized code 
> for the coprocessor if you check it off. Now, why doesn't Apple just set up a 
> standard numeric enviroment (i.e. SANE), included in the system or the ROM, 
> written in blazingly fast and clever assembly language, and tailored to each 
> machine. Thus the SANE in the SE ROM would just use the 68K to do the work, 

  Ah, a nice sentiment, but there's one prob! To a certain extent, the
SANE on a 6888x machine does use the math chip. (Could be a bit more,
bue Apple's software is just barely more ccurate on some transcendental
routines.) The reason why this will never be as good as the FP options
on the compilers is that you have the overhead of a procedure call for
each operation yo perform. Imagine writing a bunch of one line functions
like double my_add( double a, double b) {...}   for all the basic FP
math you do. I think if you run thisthrough a profiler, you'll find way
way too much time spent on calling routines rather than crunching
numbers. This is what SANE does now, so you can probably guess that any
app using FP math on the heavy side is probably going to be better off
calling the chip directly. Otherwise, your app _alread_ will use the
math chip for SANE routines! 
  The other prob with transparent FP chip use is that the formats for
SANE and the 6888x are of different sizes, and you have to do byte
crunching to transfer them back and forth. That's more overhead on the
routines, since everyone will expect the SANE format results! 
  This is certainly best left to the compiler to use the direct FP calls
and figure out who needs what beforehand, avoiding all the ugly delays
with format swapping and routine calling. Orders of magnitude
difference! If you want the easiest way out, compile your app in two
versions, one with FP, one without. If you have only a few routines that
will REALLY benefit from the boost, compile a version of them with FP
calls to the chip and one without. Convert the values where necessary
and at runtime, use whatever is appropriate. (Simply said, a bit more
work in the code, though.)

> Now, take the idea a step further. What if Apple implemented a MacApp type
> class library and stuck *it* in the ROMS, optimized (of course) for the
> particular machine. Thus the MacApp II in the II ROMs could take advantage of
> the nifty '020 features, the MacApp IIci in the IIci ROMs could take advantage
> of *its* nifty features (burst mode something or other, etc.), the the MacApp
> IIfx in the IIfx ROMs could take advantage of its nifty features--features which
> now (I believe) are up to the individual programmers to figure out and use.
> 
> The advantage: Consistently high quality code, tailored to the special features
> of each machine. Guarranteed optimal performance. 
> 
> More pros: If you put it on fast ROMs, the processor wouldn't need as large a
> cache or as clever progamming to reach zero wait states.
> The end programmer binaries would be quite small in many cases (except
> where the programmer did extensive alteration of the classes, but even then,
> programs would mainly be a series of calls to the ROM). Better code
> compatibility--as long as you keep the interface basically the same, the
> progams will run). Along with that, a greater degree of hardware independance.
> More application consisitency--if the human interface is in the ROMs, and will
> both lower one's application size and improve (in most cases) performance *and*
> insure (almost) complete compatibility with now and future machines, people
> will use it.
> 
> Cons: A hell of a lot of work for apple, but it would generate good software
> and sell machines.
> 
 
  I will shoot my foot if Apple does what you ask here. I'll then turn
and shoot you! If you're going to put it in ROM, either it better not
change anytime soon or the ROM changes better be easy and quick. (And
cheap 8-|) Something like MacApp is not perfect and error free and never 
will be.  Putting it in ROM will force you to write to that old version, 
stuck in time. What do you do when the new MacApp ROMS come out? Do you
write to the new version or the old, sans the new features? Imagine
having to tell a customer that your program runs only with the new ROMs,
so they have to go out and upgrade. No doubt Apple will have a nice fee
for this changeout. 
  No, what you've hit on that could be a much more useful and elegant
idea is that of _sharing_ common code, like MacApp. If you look over
some PC type shoulders, you'll see that this is one of the features of
OS/2. When you're program starts up (maybe even while it's running), you
can open a library and use it's routines. You don't have to compile them
all into your program! The benefits are real handy, too. You drop the
size of your programs (overall) by sharing code. Not just source code,
but the executables. You can use libraries provided by, say, Apple to do
nifty things without the obliqueness of some sort of trap dispatch style
implementation. (Not to mention that not everyone get's to use these
reserved routines! ;-) ) This is pretty similar to something like cdevs
and XCMDs et al. But with that sort of linking, you do all the work of
something than an OS should do. I guess maybe we'll see this in Sys 8.0?
PLEASE, Apple? (I want protected memory before that, tho. I want it NOW,
but I think we need it ASAP...too many Macs crash when someone does
somthing stupid in their INIT or app and takes out a whole system.
That'll be just great with virtual memory and bunches of apps running
with huge documents. It would only take 5 minutes to reboot after
that...of course, you may miss all that data you were working with...
but i digress.)
  So, Apple. Please send dynamic linking our way. I really don't think
it can be all _that_ difficult. All the compilers can link. Why not the
OS? 

Back to the original post....
> I think there are more advantages, but this post is long enough.
> Bijan J. Parsia 

  Well, this post is too long.... But I think I've managed to cover all
your points!

Robert Minich
minich@a.cs.okstate.edu

Has you Mac crashed this week? today? in the last hour? 5 minutes ago? As I....