home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / next / programm / 7296 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  1.6 KB
  1. Path: sparky!uunet!rosie!NeXT.com
  2. From: sam_s@NeXT.com (Sam Streeper)
  3. Newsgroups: comp.sys.next.programmer
  4. Subject: Re: The solution to FatBinaries.
  5. Message-ID: <5905@rosie.NeXT.COM>
  6. Date: 19 Nov 92 02:06:50 GMT
  7. References: <83163@ut-emx.uucp>
  8. Sender: news@NeXT.COM
  9. Reply-To: sam_s@NeXT.com
  10. Lines: 24
  11.  
  12. ifbb657@cc.utexas.edu (Douglas Floyd) writes:
  13. > OK, NeXT is using FatBinaries to do machine code for each processor.
  14. > My solution: (user compiled p-code)
  15.  
  16. While there is a lot of merit to your idea, I suspect the resultant code  
  17. wouldn't be nearly as efficient as you imagine.  Optimization is very important  
  18. to the overall speed of a machine/program, which is why you often see 2-3x  
  19. speed difference between different compilers.  Optimization is much easier to  
  20. perform when you can analyze source level constructs, and to retain these  
  21. constructs, the p-code would have to drag along a lot of the structure of the  
  22. original source, which would be unacceptible.
  23.  
  24. Your point gives me an interesting idea.  Soon we'll see RISC processors with  
  25. loadable microcode that allow them to emulate intel or motorola CISC  
  26. instruction sets.  It would be cool if part of a context switch switched the  
  27. microcode and let the CPU execute 040 and 386 tasks side by side.  Sure it  
  28. would be a nightmare from a systems software standpoint, but such subtle  
  29. vicissitudes notwithstanding... (sorry for the excessive alliteration also)
  30.  
  31. -sam
  32.  
  33. --
  34. Opinions expressed herein are not those of my employer.  They're not even
  35. mine.  They're probably wrong besides.  How did they get in here, anyway?
  36.