Article View: comp.sys.next.programmer
Article #1822Re: The solution to FatBinaries.
From: Sam Streeper
Date: Thu, 19 Nov 1992 02:06
Date: Thu, 19 Nov 1992 02:06
24 lines
1626 bytes
1626 bytes
ifbb657@cc.utexas.edu (Douglas Floyd) writes: > OK, NeXT is using FatBinaries to do machine code for each processor. > My solution: (user compiled p-code) While there is a lot of merit to your idea, I suspect the resultant code wouldn't be nearly as efficient as you imagine. Optimization is very important to the overall speed of a machine/program, which is why you often see 2-3x speed difference between different compilers. Optimization is much easier to perform when you can analyze source level constructs, and to retain these constructs, the p-code would have to drag along a lot of the structure of the original source, which would be unacceptible. Your point gives me an interesting idea. Soon we'll see RISC processors with loadable microcode that allow them to emulate intel or motorola CISC instruction sets. It would be cool if part of a context switch switched the microcode and let the CPU execute 040 and 386 tasks side by side. Sure it would be a nightmare from a systems software standpoint, but such subtle vicissitudes notwithstanding... (sorry for the excessive alliteration also) -sam -- Opinions expressed herein are not those of my employer. They're not even mine. They're probably wrong besides. How did they get in here, anyway?
Technical Details
Message-ID:
<5905@rosie.NeXT.COM>Path:
arc1-ca.pugleaf.net!sparky!uunet!rosie!NeXT.comReferences:
<83163@ut-emx.uucp>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!rosie!NeXT.com From: sam_s@NeXT.com (Sam Streeper) Newsgroups: comp.sys.next.programmer Subject: Re: The solution to FatBinaries. Message-ID: <5905@rosie.NeXT.COM> Date: 19 Nov 92 02:06:50 GMT References: <83163@ut-emx.uucp> Sender: news@NeXT.COM Reply-To: sam_s@NeXT.com Lines: 24