Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!pacbell!att!tellab5!toth
From: toth@tellab5.tellabs.CHI.IL.US (Joseph G. Toth Jr.)
Newsgroups: comp.sys.apple
Subject: Re: Computer languages on the various Apple Corp computers
Summary: Why not a common P-Code system under ProDOS???
Message-ID: <1364@tellab5.tellabs.CHI.IL.US>
Date: 25 May 89 20:32:27 GMT
References: <2075@umbc3.UMBC.EDU> <10211@claris.com>
Organization: Tellabs, Inc. Lisle, IL
Lines: 67

I don't want to get into the relative merits of different processors
and operating systems, as the arguments against native code generation
have been going on for some time and all seem to agree that the 6502,
65c02 and the 65816 aren't the easiest processers to handle.

The major question in my mind involves the ability to program in a
high level language (eg, Pascal, Fortran, "C", Forth, etc) on an Apple //.

Why can't a P.SYSTEM be generated that operates like BASIC.SYSTEM be generated.
P-Code interpreters are fairly small, and can operate nicely on the 6502
processor (even with all its limitations). Apple Pascal is a P-Code environment
where the major obstacle is its non ProDOS disk I/O architecture.

It would use ProDOS as its operating environment (Disk I/O).
It could be launched with an added parameter of the program to run
  (the same as in BASIC.SYSTEM) or every program could execute a peice of
  startup code that loads the P.SYSTEM then passes control to the system
  with a pointer to the start of the P-Code executable.
The P.SYSTEM would terminate itself when the P-Code executable reaches
  a termination point by executing the standard QUIT code.

Once a usable P.SYSTEM is developed (Apple Pascal could be used as a basis
  for determining the minimum functionality required), any number of compilers
  could be generated that generate P-Code executables (or even intermediates
  if you want to be able to link things together, probably preferable).
  The thoughts are breathtaking;
     PASM.SYSTEM  - A P-Code Assembler
     PPAS.SYSTEM  - A Pascal Compiler
     PC.SYSTEM    - A "C" code compiler
     PFORT.SYSTEM - A Fortran Compiler
     <almost any other language you care to name>
  Each of which would accept a filename which is the name of a standard TXT
  file to be used in the compile, and output the linkable as a different
  filetype (POB - P-Code object, maybe)
  in the same

     PLINK.SYSTEM - A linker that takes the output from any of the above
		    and generates an executable (filetype PEX - P-code
		    executable, maybe).

It seems to me that since there are already is a P-Code interpreter and
a Pascal compiler that generates P-Code (and Fortran from what I hear)
that run on an Apple //, that they (Claris ???) could adapt the existing 
packages to fit the above scenario.

A system like this I could see paying for.

I once before complained about Mad Apple Forth, and made the statement that
it was an interpreter.  My main problem with using MAF was that once in the
interpreter, it used a non-ProDOS disk for internal operations (its utilities),
not that it was an interpreter.  It just seems to be a bit much to be required
to insert a specific disk in Drive 6 Slot 2 before being able to run an
application (no ifs, and or buts - you need to insert that disk ro run) when
I could fit everything on a single mass storage device if it was truly ProDOS.

The same complaints hold true for Apple Pascal (and the freeware hyper_C)
except that they are even worse in that you can't simply QUIT back to ProDOS,
you have to re-boot (open-apple/control/reset, I hate seeing people turn the
power off/on to do a re-boot).

I guess that these are just pipe-dreams, much the same as hoping that
the ProDOS based hyper_C is made freeware.

-- 
------------------------------------------------+---------------------
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