home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / lisp / mcl / 1262 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  1.2 KB
  1. Path: sparky!uunet!gatech!darwin.sura.net!mips!apple!cambridge.apple.com!bill@cambridge.apple.com
  2. From: bill@cambridge.apple.com (Bill St. Clair)
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: Re: Short float arrays
  5. Message-ID: <9208172200.AA09365@cambridge.apple.com>
  6. Date: 17 Aug 92 23:03:27 GMT
  7. Sender: info-mcl-request@cambridge.apple.com
  8. Lines: 14
  9. Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
  10. Full-Name: Bill St. Clair
  11. Original-To: Jim Hurd <71501.1347@CompuServe.COM>
  12. Original-Cc: info-mcl
  13.  
  14. >>Not necessary. Since SHORT-FLOAT's are immediate objects, storing
  15. >>them in an array with an element-type of T is as good as anything.
  16. >
  17. >Wouldn't arrays of short-floats eliminate some masking of the tag bits?
  18.  
  19. If MCL's compiler did floating point optimizations (which it doesn't), then
  20. a SHORT-FLOAT array element type would be useful. Your declaration of the
  21. array's type would sometimes allow the compiler to generate better code.
  22.  
  23. Since the compiler doesn't optimize floating point computations,
  24. a SHORT-FLOAT array element type would actually slow things down.
  25. It would require AREF to translate from array storage format to
  26. immediate short-float format rather than just returning the bits
  27. as they're stored in the array.
  28.