nelson@pro-europa.cts.com (Nelson Minar) (05/27/89)
att!tellab5!toth@ucbvax.berkeley.edu (Joseph G. Toth Jr.)?? proposed a Psystem concept to develop on the // I have to really disagree with that concept - P-Systems are horrible. They are very slow, require a P-system on disk, and are more of a patch for somethign that should be done in native code. Afterall, the reason we dont use basic is that we dont WANT to use an interpreted (P-code like) system. However, it does seem like P-code is the easiest stuff to develop on a //. I guess the question is, what is the future for a system that REQUIRES P-code to run higher level languages? Finally, isnt a toolbox in many ways a p-code system? nelson@pro-europa.cts.com cogito ergo non sum ...!crash!pnet01!pro-nsfmat!pro-europa!nelson
rthille@ics.uci.edu (Robert Thille) (05/28/89)
I think that P-systems would be a good idea for the non-IIgs IIs, since it is the easiest way to develop on a II, and such a similar system exists. If Apple were supporting Apple pascal, the best thing to do would be to port the p-code interpreter to prodos, port the pascal compiler, write a C and fortran? compiler, all running under ProDos. Then someone could write a p-code to 6502 compiler/assembler. It would basically seperate the front and the back end of the compilers, making it easier to modify each one. The p-code compiler could generate code for 6502, 65c02, 65802, 65816, allowing programs to take better advantage of the system they are running on. Now if we could get apple to just support non-IIgs IIs!!! :-) Robert Thille P.S. Look in APDAlog, and see that only 2(?) products specifically for non-IIgs IIs, from apple, are current, and supported.
SEWALL@UCONNVM.BITNET (Murph Sewall) (05/29/89)
>I think that P-systems would be a good idea for the non-IIgs IIs, since >it is the easiest way to develop on a II, and such a similar system exists. When I bought my //e (1983) I also bought a (then brandy new) program named the Incredible Jack (the name had good marketing value anyway) which (I found out later) was developed under the p-system (with encouragement from Apple). It would have been a nice piece of software if it wasn't so SLLLLOOOOoooowwww. Later, I bought an early version of ThinkTank (even better idea but also incredibly SLLLLLOOOOoooooowwww). The ThinkTank IS pretty good on an older Apple 2 with a hard disk and an accelerator (Transwarp, ZipChip, Rocket Chip, etc.). The makers of the Incredible Jack went bankrupt and ThinkTank got bought by someone else (after succeeding on the IBM-PC and the Mac). In short, I'm not impressed by p-system software. Murph Sewall Vaporware? ---> [Gary Larson returns 1/1/90] Prof. of Marketing Sewall@UConnVM.BITNET Business School sewall%uconnvm.bitnet@mitvma.mit.edu [INTERNET] U of Connecticut {psuvax1 or mcvax }!UCONNVM.BITNET!SEWALL [UUCP] (203) 486-5246 [FAX] (203) 486-2489 [PHONE] 41 49N 72 15W [ICBM] -+- I don't speak for my employer, though I frequently wish that I could (subject to change without notice; void where prohibited)
dlyons@Apple.COM (David Lyons) (05/31/89)
In article <8905271756.AA29116@crash.cts.com> pnet01!pro-nsfmat!pro-europa!nelson@nosc.mil writes: [...] >Finally, isnt a toolbox in many ways a p-code system? Nope. At least not any more than a subroutine library is. BTW, I don't object to "lumping" P-code systems in with interpreted BASICs. While Applesoft BASIC does do more run-time stuff (searching for lines by number when you GOTO them and searching for variable entries in a table, for example) than the UCSD P-system does, it doesn't *have* to be that way. There's no reason an interpreted BASIC couldn't have the RUN command go through and pre-compute the location of teach line & the address of each variable & store it into the code. And there's no reason a P-code Pascal couldn't do slow searches for variables if it really wanted to. --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
toth@tellab5.tellabs.CHI.IL.US (Joseph G. Toth Jr.) (05/31/89)
In article <31982@apple.Apple.COM>, dlyons@Apple.COM (David Lyons) writes: > In article <8905271756.AA29116@crash.cts.com> pnet01!pro-nsfmat!pro-europa!nelson@nosc.mil writes: > [...] > > BTW, I don't object to "lumping" P-code systems in with interpreted BASICs. > While Applesoft BASIC does do more run-time stuff (searching for lines by > number when you GOTO them and searching for variable entries in a table, > for example) than the UCSD P-system does, it doesn't *have* to be that way. > There's no reason an interpreted BASIC couldn't have the RUN command go through > and pre-compute the location of teach line & the address of each variable & > store it into the code. And there's no reason a P-code Pascal couldn't do > slow searches for variables if it really wanted to. > Maybe you can lump them together, but I can't!!! The UCSD P-Code specifications require these methods of variable reference and function entry/jump(goto) operations (good programming practice that allows reasonable execution speed). The BASIC programming practices (extensible arrays, indeterminate string length, etc) almost required the implementation of linked-lists / tables for variable storage. The ability to stop execution, modify variable usage (create an array entry not previously used), and continue execution screws up any idea of pre computed addresses. To be able to pre-compute addresses, BASIC would no longer be PURELY interpretive (programs must be pre-processed BOFORE each run, and always run from the first line, this would require the rewrite of the Apple Kermit builde routines, maybe not a bad idea after all), and there would have to be a method of defining string lengths for storage (A$ can be 1 char, 10 char ??char in length). It is apparent that you despise Applesoft BASIC and P-Code systems. While I despise the BASIC, the reason I don't care for Apple PASCAL and the hyperC that was posted on the net is that they run under their own custom DOS, and the reason that I still have no reason to learn FORTH is that Mad Apple Forth is that darned Utility disk (DD, get it to run with those utilities stored under ProDOS and you make a good language implementation GREAT). The REAL PROBLEM wit the Apple //e //c line is still that; A: there are few real High Level languages that run under ProDOS. B: those that exist each has a major limitation at some point. C: some are poor compilers (Aztec "C", or is it 'C'). D: there is no method of linking ouptut from any compiler/assembler with output from another. Is the ProDOS HyperC still being investigated. Release of that compiler might make the standard // line usable for a general programmer. If ProDOS HyperC is never going to be available, Apple (Claris??) should really consider porting the Apple Pascal to a ProDOS environment. -- ------------------------------------------------+--------------------- 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
tribby@hpindda.HP.COM (David Tribby) (05/31/89)
dlyons@Apple.COM (David Lyons) writes... > > BTW, I don't object to "lumping" P-code systems in with interpreted BASICs. > ... And there's no reason a P-code Pascal couldn't do > slow searches for variables if it really wanted to. > > --Dave Lyons, Apple Computer, Inc. | DAL Systems I hate to disagree with one of my favorite Apple experts, but the big difference between interpreted BASIC and the P-system is the amount of "digesting" done before execution of the program. With BASIC, the exact structure of the source program must be maintained because the user may modify it. Very little is done, except tokenization of key words. With P-code Pascal, the source code is actually compiled. During execution there is no need to search for variables since they will be at fixed locations. Yes, the P-code must be interpreted, but it is much closer to machine code than BASIC tokens. The P-code system spends a lot of time compiling and linking so that it can be more efficient in execution than a purely interpreted language. --Dave Tribby - - - - - ARPA: tribby%hpda@hplabs.HP.COM UUCP: hplabs!hpda!tribby
dlyons@Apple.COM (David Lyons) (06/01/89)
In article <1370@tellab5.tellabs.CHI.IL.US> toth@tellab5.tellabs.CHI.IL.US (Joseph G. Toth Jr.) writes: >Maybe you can lump them together, but I can't!!! I'm not calling the UCSD P-system and Applesoft the same thing; they aren't. I said that in general I don't see a fundamental difference between a P-code system and an interpreted BASIC. Where *is* the difference? >The BASIC programming practices (extensible arrays, indeterminate string >length, etc) almost required the implementation of linked-lists / tables >for variable storage. The ability to stop execution, modify variable >usage (create an array entry not previously used), and continue execution >screws up any idea of pre computed addresses. Applesoft arrays can't change size during program execution (not without machine code routines added on to do the work, anyway). Dynamic allocation of string space is a separate issue from the method of execution (there's nothing preventing the existence of something just like Applesoft except with statically-allocated fixed-length strings). > To be able to pre-compute >addresses, BASIC would no longer be PURELY interpretive (programs must be >pre-processed BOFORE each run, and always run from the first line, [...] Applesoft is *already* not *purely* interpreted. Reserved words are tokenized, and there are forward links to the next line that are kept up to date as the program is edited. The pre-processing would be a transparent step--something that the RUN command would do before beginning execution. There's no reason you'd have to execute from the first line. >It is apparent that you despise Applesoft BASIC and P-Code systems. Is it?? I haven't made myself at all clear, then. I don't despise them at all. Interpreters of any sort are neat. Usually it means sacrificing *some* speed (not necessarily very much) and gaining a lot of compactness in the code. The trick is to make sure most execution time is spent *doing* something instead of figuring out what to do next. If the instructions in the pseudo- language are powerful, the speed penalty may not be that large. (Just like using the toolbox on the GS: In many cases it doesn't make a noticable difference whether you write an application in a high level language or in assembly language, since the majority of the exeuction time will be spent *executing* toolbox calls anyway, rather than executing your own code.) >------------------------------------------------+--------------------- >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 --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.