AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (03/21/89)
>Date: Sun, 19 Mar 89 05:38:51 GMT >From: David Douthitt > <astroatc!nicmad!madnix!rat%speedy.wisc.edu@BRL.MIL> >Subject: Re: Following Programming Guidelins > [...] >| Taking silly shortcuts & other shortsightedness is not only bad for >| _future_ compatibility: it's also bad for _present_ compatibility >| with other applications and utilities. > >I would maintain that following ALL guidelines is not necessarily >a good thing. I have been appalled by the low quality of ROM code >for quite a while. ROM calls are routinely circumvented to improve >speed and simplify programming. Perhaps all we need is someone to >rewrite the ROMs. That is not an accurate picture of the quality of ROM code. Please point out particular things that you are appalled by. >I would agree however, that in a tight-[k?]nit system such as GS/OS and >the Macintosh MFS compatibility guidelines are mandatory. Yet, under >Pro[DOS] and Pro[DOS]-16, I would maintain that the ROMs are worth >avoiding - so write to the 80-column screen directly, write to the >ACIA directly - read the keyboard directly - most average programmers >can improve on these somehow, someway. (ProDOS 16 is obsolete except for use with AppleShare file servers. Assuming that GS/OS will become AppleShare compatible in a reasonable time frame, there's no reason to think about P16.) The world is full of trade-offs, of course. There will always be cases where the system-provided resources do not meet your needs (possibly because the system provides something more general than what you need, and you can get by with something less powerful but faster), when you'll have to do things your own way. But _most_ of the time, _guaranteed_ ways to do things exist, and they should be used. If you _must_ write to the serial chip directly to get the speed you need, fine. But try it the other way first--if memory serves, TIC uses the firmware on the GS and is able to keep up at high speeds (9600 or 19200--don't remember which). If you have to go out on your own, do it with care. Look for alternative guaranteed approaches before throwing the rules out the window. (For example, if you need to draw faster than QuickDraw can, you can start up QuickDraw anyway and ask it for a table of the starting addresses of all the scan lines.) >======== David Douthitt :::: Madison, WI :::: The Stainless Steel Rat ======== >FidoNet: 1:121/2 ::::: WittiNet: "Curiouser and curiouser, said Alice." :::::: >UseNet: ...{rutgers|ucbvax|harvard}!uwvax!astroatc!nicmad!madnix!rat >ArpaNet: madnix!rat@cs.wisc.edu {decvax|att}! --David A. Lyons bitnet: awcttypa@uiamvs DAL Systems CompuServe: 72177,3233 P.O. Box 287 GEnie mail: D.LYONS2 North Liberty, IA 52317 AppleLinkPE: Dave Lyons
prw@meccts.MECC.MN.ORG (Paul Wenker) (03/21/89)
In article <8903201645.aa09462@SMOKE.BRL.MIL> AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") writes: >>Date: Sun, 19 Mar 89 05:38:51 GMT >>From: David Douthitt >> <astroatc!nicmad!madnix!rat%speedy.wisc.edu@BRL.MIL> >>Subject: Re: Following Programming Guidelins > >>[...] >>I would maintain that following ALL guidelines is not necessarily >>a good thing. I have been appalled by the low quality of ROM code >>for quite a while. ROM calls are routinely circumvented to improve >>speed and simplify programming. Perhaps all we need is someone to >>rewrite the ROMs. > >That is not an accurate picture of the quality of ROM code. Please >point out particular things that you are appalled by. I would have to agree with Dave #1 on this point. From what I've seen of the ROM code, the quality (i.e. efficiency) ranges from very good to very bad. Here are just a couple of things that I noticed when looking through the text bottleneck routines... 1) Using BRL's to locations that are less than 128 bytes away. A BRA is 1 byte shorter and 1 cycle faster. 2) Using BRL's period. A JMP instruction is 1 cycle faster. 3) Code like this... fe/6556: lda 38 fe/6558: asl a fe/6559: tax fe/655a: jmp (655d,x) fe/655d: dw 6563,6571,6571 fe/6563: (code chunk #1) ... fe/6571: (code chunk #2) A more efficient way would be... fe/6556: lda 38 fe/6558: bne 6568 fe/655a: (code chunk #1) ... fe/6568: (code chunk #2) This saves 9 bytes and 7-8 cycles. Having these kinds of inefficiencies in interface code is one thing, but when they are in the bottleneck routines I think that definitly fits into the appalling category. --- Paul Wenker UUCP: prw@mecc.mn.org MECC, Advanced Development AppleLink: MECC.TECH