Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pacbell!att!tellab5!toth
From: toth@tellab5.tellabs.CHI.IL.US (Joseph G. Toth Jr.)
Newsgroups: comp.sys.apple
Subject: Re: Languages for an Apple //e - //c (was P-Code Systems)
Summary: Don't pick my nits (you missed my point)
	 and (before I get flamed) I know it doesnt happen in assembly code
Keywords: P-Code System vs Native Code Compilers
Message-ID: <1388@tellab5.tellabs.CHI.IL.US>
Date: 7 Jun 89 14:24:23 GMT
References: <1373@tellab5.tellabs.CHI.IL.US> <2693@ssc-vax.UUCP>
Organization: Tellabs, Inc. Lisle, IL
Lines: 61

In article <2693@ssc-vax.UUCP>, coy@ssc-vax.UUCP (Stephen B Coy) writes:
> In article <1373@tellab5.tellabs.CHI.IL.US>, toth@tellab5.tellabs.CHI.IL.US (Joseph G. Toth Jr.) writes:
> > All this additional code is added (in many cases, even
> > if it is not needed - A guy I work with bought Aztec 'C' anf compiled
> > a program with a single procedure that did 'printf ( "Hi" );', this one
> > stament program compiled to approximately a 4K byte program - no disk I/O
> > or any other functions).
> 
> printf() is a BIG function.  Try the same code on another system and
> look at the size.  My guess is that 4K will all of a sudden seem tiny.
> 
> Stephen Coy

This rebutal to my point about the size of the 'printf()' function is
taken out of context from the general concept of the postings.  Maybe
I didn't go into detail about all of the complexities of the 'printf()'
function making my reference to additional code that is not needed, but
I had no intention of stating that in the grand scheme of the compilers
that the size was not necessary.  (This could be used as a great 
argument for the use of assembly instead of any compiler, and is
absoltely valid in any piece of code as simple as that in the example).

In order to allow for a single function that performs many different
operations (string expansion, data conversion, etc.), the code that
must be generated in an executable is inherintly large, even if much
of the code is never executed.

The jist of my posting was intended to point out to those who were
stating that P-Code Systems are worse than Native Code Compilers due
to the inherintly large (they're not THAT big) P-Code interpreters
that the size of code generated by an available Native Code Compiler
contains inherint inefficiency in the code generated for simple
operations, and that the distinction between P-Code Systems and
Native Code is less than many would think.

To use more 'C' code examples:
  Native code;
     printf(), fprintf(), and sprintf(), would each include their own
     copy of the code segments that perform conversions, etc.
     This duplicated code creates larger executables.
  P-Code system;
    The same three functions end up using the same conversion routines,
    etc., allowing for a savings in code space due to lack of redundancy.

Another point for P-Code Systems;

  The size of the executable file on disk IS very small.  You can
  generate MANY programs, and still use up minimal space on a disk.
  This is primarily due to the fact that the physical executable
  code is resident in the P-Code System file, which is stored on
  the disk once.

  The size of the executable file on disk of a Native Code program
  will bw MUCH larger.  This is true for EVERY executable that is
  generated since each executable must contain all code for every
  function used.  This size can really add up.

-- 
------------------------------------------------+---------------------
Maybe I shouldn't have done it, sarcasm is so   | Joseph G. Toth Jr.
seldom understood.  Don't FLAME on me, please.  | uunet!tellab5!toth