home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ukma!wupost!zaphod.mps.ohio-state.edu!cs.utexas.edu!ut-emx!cc.utexas.edu
- From: ifbb657@cc.utexas.edu (Douglas Floyd)
- Newsgroups: comp.sys.next.programmer
- Subject: The solution to FatBinaries.
- Message-ID: <83163@ut-emx.uucp>
- Date: 6 Nov 92 22:18:37 GMT
- Sender: news@ut-emx.uucp
- Lines: 46
-
- OK, NeXT is using FatBinaries to do machine code for each processor.
- The bad thing about this is when NeXTStep runs on other processors,
- binaries must be compiled and included with the release. P-Code is
- too S----L----O----W, and interpreting binaries is slllloooowwww also.
-
- My solution:
-
- NeXT code
-
- Here is how it works:
-
- 1: Programmer codes his "killer app"
- 2: C-compiler compiles the code into NeXTCode which is machine
- independant, similar to Microsoft's P-code.
- 3: When program gets to the user, the user uses an installer/
- "compiler" to convert the NeXTCode to native machine code for
- his processor.
-
- Pros:
-
- o Only one binary needed, no FatBinaries or ObeseBinaries
- o Runs LOTS faster than P-code or interpreted code
- o Easy to do
-
- Cons:
-
- Maybe some inefficency, but _very_ little.
-
- Notes:
-
- A special debugger can be produced to modify NeXTCode at the source
- for optomization
-
- Patches to NeXTcode for different processors can be stored with the code
-
- NeXT will have something no other computer has dreamed of offering :-)
-
- COMMENTS ARE WELCOME- I would like to work on this as a discussion.
-
- PS: If NeXT is listening, and this helps, I am looking for a NeXT for
- my use to program some stuff :-).
- --
- ******* ifbb657@ccwf.cc.utexas.edu (Douglas R. Floyd) ******
- Disclaimer: I speak for myself.
-
- Please, no NeXTMail at this time.
-