🚀 go-pugleaf

In article <83163@ut-emx.uucp>  writes:
> 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.

Yep, that's my long term project, except that I am using a Modula-2 like  
language ...
--
Robert Frank                         tel. + (061) 321 99 67                 
Institut fuer Informatik             fax  + (061) 321 99 15                 
University of Basel, Switzerland                                            
Mittlere Strasse 142      rfc822: frank@ifi.unibas.ch (NeXT mail accepted)  
CH-4056 Basel          X400: S=frank;OU=ifi;O=unibas;P=switch;A=arcom;C=ch
                   ( if all fails try frank@urz.unibas.ch )

In article <83163@ut-emx.uucp>  writes:
> 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.

Perhaps the intermediate code generated by gnu-cc (used on NeXTs) could be
used...it is general enough for use with all the machines gcc runs on...
However, I don't know enough about the issues (or about gcc intermediate
code) at this point to know for sure.

I do suspect that software developers will not easily go for "NeXT code" as a
distribution medium, however.  For one thing, "NeXT code" would -probably- be
(by its very nature) very open.  This is excellent for debugging and
development, but few developers (except perhaps gnu) want to give something
that close to source code away.

That issue does have solutions, though.  For example, if the language is more
like the gcc intermediate code (which is relatively low level) and all
symbols not needed for run-time-linking (rld_* functions) can be stripped or
represented in some encoded format, this is less of an issue.

Already, developers have to go to relatively great lengths to protect things
like licensing code from prying eyes.  Standardized approaches to hiding
information are prime targets for hackers, since the rewards reaped are that
much bigger.  Making something like NeXT code work--both from a technical and
a marketing standpoint--will not be so easy.

Andrew Athan
Objective Technologies, Inc.

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?