home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / arch / 9236 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  1.3 KB

  1. Path: sparky!uunet!sun-barr!decwrl!deccrl!news.crl.dec.com!news!nntpd.lkg.dec.com!sousa.ltn.dec.com!sites
  2. From: sites@sousa.ltn.dec.com (Dick Sites)
  3. Newsgroups: comp.arch
  4. Subject: Re: 32 => 64 Transition
  5. Message-ID: <1695@sousa.ltn.dec.com>
  6. Date: 4 Sep 92 18:38:22 GMT
  7. References: <l8u555INN5q6@spim.mips.com> <1992Aug11.125326.16719@email.tuwien.ac.at> <MARC.92Aug24100239@marc.watson.ibm.com>
  8. Sender: newsa@sousa.ltn.dec.com
  9. Reply-To: sites@sousa.ltn.dec.com (Dick Sites)
  10. Organization: Digital Equipment Corporation, Littleton MA
  11. Lines: 9
  12.  
  13.  
  14. Marc writes:
  15. >> Either the compiler always clears the high order bits of short values
  16. >> in registers (the performance hit) or produces inconsistent results.
  17.  
  18. For a canonical sign-extended 32-bit value in a 64-bit register (to avoid a separate set of 32-bit branches, among other things), change "clears" to "foreces to all-0/all-1 on 32-bit overflow". This is in fact a tight timing path, but not the final cycle time limiter in the Alpha 21064 chip. So, with some design care, there need not be either a performance hit or inconsistent results. For this to work, 32-bit operations must check for 32-bit overflow, not 64-bit overflow. Hi, Marc. 
  19. --
  20.     Dick Sites, who does not speak for Digital, but knows a little about
  21.     Alpha. :-)    sites@tallis.enet.dec.com
  22.