Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!umn-d-ub!nic.MR.NET!umn-cs!meccts!prw
From: prw@meccts.MECC.MN.ORG (Paul Wenker)
Newsgroups: comp.sys.apple
Subject: Re: following programming guidelines
Message-ID: <3902@meccts.MECC.MN.ORG>
Date: 21 Mar 89 14:56:36 GMT
References: <8903201645.aa09462@SMOKE.BRL.MIL>
Reply-To: prw@meccts.UUCP (Paul Wenker)
Organization: MECC Technical Services, St. Paul, MN
Lines: 53

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