p-code was created for PLATFORM PORTABILITY

[gem at cigital.com (Gary McGraw)]

I am all for the "mistake" of type safety and reference monitors.   All we need to do is build a real machine that runs 
byte code and/or clr instead of interpreting it.  I agree that jit'ing os a kludge...

I await the scheme-os which bill joy and I figure may emerge from africa sometime in the next decade.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com


 -----Original Message-----
From:   Crispin Cowan [mailto:crispin at novell.com]
Sent:   Mon Nov 13 18:32:53 2006
To:     David A. Wheeler
Cc:     sc-l at securecoding.org
Subject:        Re: [SC-L] p-code was created for PLATFORM PORTABILITY

David A. Wheeler wrote:
> On 11/9/06, Crispin Cowan <crispin at novell.com> wrote:
>   
> > > Prior to Java, resorting to compiling to byte code (e.g. P-code back in
> > > the Pascal days) was considered a lame kludge because the language
> > > developers couldn't be bothered to write a real compiler.
> > >       
> I believe that is completely and totally false.
> If you want to claim p-code itself was lame, fine.
> But let's keep the history accurate.
>
> The UCSD p-system was created in the late 1970's SPECIFICALLY for
> PORTABILITY of executable code: You could ship p-code to any
> machine, and it would run.
That is not inconsistent with my claim. The "P-code is a kludge to get
around writing a real compiler" is multiplied by the diversity of
architectures. Writing a native code generator is a cost you pay for
every supported architecture. So in more detail, P-code is a
performance-compromising kludge to avoid having to write a *lot* of real
code generators.

One major change between then and now is consolidation of CPUs. Then,
there really was a very broad diversity of CPU architectures (IBM
mainframe, IBM  AS/400, DEC VAX, PDP, DEC10, DEC20, Data General,
Apollo, HP, Xerox Sigma, x86, 68000, NS32K, etc. etc.) and they all more
or less mattered. It is *very* different today: the list of CPU
architectures that matter is much shorter (x86, x86-64, SPARC, POWER,
Itanium): only 4 instead of a baker's dozen, and of those 4, a single
one (x86) is a huge majority of the market.

Pascal was a student language, not often used for commercial
development, so money for Pascal development was scarce. In contrast,
real languages for commercial purposes (PL/1, COBOL, FORTRAN, C) all
used native code generators. P-code was precisely a
performance-compromising kludge to allow Pascal to be portable with less
development effort.

Of course, there was one big exception: Turbo Pascal. Arguably the most
popular Pascal implementation ever. And it used a native code generator.

The need for portability, and the cost of portability (how many
platforms you really have to port to) has dropped dramatically. Bytecode
should be going away, the the architectural mistake of Java and C#/.Net
are going to preserve it for some time to come :(

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------