home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.amiga.programmer
- Path: sparky!uunet!mcsun!news.funet.fi!funic!nntp.hut.fi!nntp!jraja
- From: jraja@vipunen.hut.fi (Jarno Tapio Rajahalme)
- Subject: Re: Improved ByteRun algorithm for programmers.
- In-Reply-To: breese@monet.imada.ou.dk's message of Mon, 14 Dec 1992 16:07:49 GMT
- Message-ID: <JRAJA.92Dec15225646@vipunen.hut.fi>
- Sender: usenet@nntp.hut.fi (Usenet pseudouser id)
- Nntp-Posting-Host: vipunen.hut.fi
- Organization: Helsinki University of Technology, Finland
- References: <JRAJA.92Dec13191720@vipunen.hut.fi> <1992Dec14.160749.21777@imada.ou.dk>
- Date: 15 Dec 92 22:56:46
- Lines: 25
-
- In article <1992Dec14.160749.21777@imada.ou.dk> breese@monet.imada.ou.dk (Bjoern Reese) writes:
-
- In article <JRAJA.92Dec13191720@vipunen.hut.fi> jraja@vipunen.hut.fi (Jarno
- Tapio Rajahalme) writes:
- > In article <1992Dec8.122757.27543@doug.cae.wisc.edu> pochanay@cae.wisc.edu
- (Adisak Pochanayon) writes:
- >
- >> upb_copyit
- >> bclr.b d2,d0 ; Clear bit seven in d0
- >
- > Wouldn't standard neg.b be faster than bclr.b ?
-
- Yes it would, but unfortunately it wouldn't give the same result.
- neg.b does a 2-complementary negation while bclr.b just clears a
- single bit.
-
- I just thougth if it would be possible to avoid using d2 (for
- _marginal_ speed increase :-), but using neg leads to an unbalanced
- algorithm, since the end value would be -128 (instead of zero, could
- be detected after neg with bmi), but as stated the branch with
- negative codes would be lenghtened by one instruction (while the other
- branch would be shorter). Driving some statistics would tell if this
- would be slower or faster.
-
- Jarno
-