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:[EMAIL PROTECTED]
Sent: Mon Nov 13 18:32:53 2006
To: David A. Wheeler
Cc: sc-l@securecoding.org
Subject:Re: [SC-L] p-code was created for PLATFORM PORTABILITY
David A. Wheeler wrote:
On 11/9/06, Crispin Cowan [EMAIL PROTECTED] 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@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.
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
