Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!paperboy!hsdndev!dartvax!eleazar.dartmouth.edu!npw
From: npw@eleazar.dartmouth.edu (Nicholas Wilt)
Newsgroups: comp.arch
Subject: Re: Loop instructions
Message-ID: <1991Apr22.163522.16786@dartvax.dartmouth.edu>
Date: 22 Apr 91 16:35:22 GMT
References: <1991Apr16.152438.3445@waikato.ac.nz> <12739@pt.cs.cmu.edu> <1991Apr21.210031.16749@leland.Stanford.EDU>
Sender: news@dartvax.dartmouth.edu (The News Manager)
Organization: Dartmouth College, Hanover, NH
Lines: 24

In article <1991Apr21.210031.16749@leland.Stanford.EDU> dhinds@elaine18.Stanford.EDU (David Hinds) writes:
>>Compiler writers dislike this instruction, but not because of the
>>test semantics. The killer is that the count is 16 bits, on a machine
>>where variables and expressions are naturally 32 bits. This means
>>that the compiler can only use the instruction when it possesses
>>range information. 
>>
>    I'm not familiar with the 68000 instruction set, but couldn't this
>instruction be adapted to 32-bit counts by just splitting the count into
>upper and lower half-words and using a nested pair of 16-bit loops?  This
>would have minimal overhead - a few instructions in loop setup - but would
>have essentially the same performance as the 16 bit count for long loops.

Unless the loop counts were very large (more range information the compiler 
would need), this would not really be worth the trouble.  DBcc isn't _that_
much faster.  Also, the extra register required might be better utilized 
elsewhere.

>
> -David Hinds
>  dhinds@cb-iris.stanford.edu

--Nick
  npw@eleazar.dartmouth.edu