Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP Path: utzoo!linus!philabs!seismo!rlgvax!cvl!umcp-cs!feldman From: feldman@umcp-cs.UUCP Newsgroups: net.micro.apple Subject: Apple Pascal: What I think Message-ID: <3656@umcp-cs.UUCP> Date: Mon, 7-Nov-83 21:57:50 EST Article-I.D.: umcp-cs.3656 Posted: Mon Nov 7 21:57:50 1983 Date-Received: Wed, 9-Nov-83 01:10:14 EST Organization: Univ. of Maryland, Computer Science Dept. Lines: 99 I have had my Apple ][+ for about four years, and for the last three I have used Apple Pascal (AP). AP is by far the nicest OS available on the Apple, however that is not to say that it doesn't have its problems. AP is Apple's version of the UCSD p-machine, A software simulated computer that runs p-code. Supplied with AP is the Pascal language and a development environment which includes a screen editor, a file handler, an assembler (6502 for the Apple), a linker, and a variety of library routines and utility programs. Considering that the only alternative until recently to AP was Apple's DOS 3.3 (DOS), a pitiful excuse for anything (let alone an OS), AP was by far the choice for software development. Here are the pros and cons of AP as I see them. The Pascal language (compiler) as supplied with AP is very powerful. Except for the lack of a dispose function, the Pascal has all of the features found on mainframe implementations. I have on occasion written programs in AP and phoned them in to Maryland's Univac 1100/80 (dinosaur) having them run with little or no changes. AP has real file handling as opposed to DOS's ctrl-D garbage. Units, which are very much like Ada packages, are supported. Linking of externally compiled/assembled routines is supported. What else could you want in a language ?-). The problems voiced in the net about compiler error #253 (Procedure too long) is overstated. If a procedure is generating more than 600 words of code, it should be more than one procedure. AP is not the only Pascal that gives a procedure too long error. Pascal/VS running on Maryland's IBM 4341's also does this (not at 600 words though). Many students taking introductory computer courses here have run into this error when they tryed to place all of there code (about 50 writelns) into the main program. The editor supplied with AP is a full screen editor. While it doesn't have a lot of the nice features found in other editors, such as macros and programmable tabs, it sure beats Applesoft's esc-sequences. The only other problem I have with the editor is its size limitation. The maximum amount of text it can edit is about 20k. The editor and the compiler work nicely together. If the compiler catches an error in your program you can have it put you in the editor write where it caught the mistake. This works most of the time, except when you start using a lot of include files. The file handler is called the filer. It is used for copying, deleting, and renaming files as well as setting the date, setting default volume names, etc., and it has wild cards. The file structure used in AP uses contiguous blocks on the diskette. This means that the disk must be K(runched whenever free space is in lots o' little patches. People have complained about this. They have asked why must AP do this when DOS doesn't. The answer is speed. Haven't you ever wondered why AP I/O is Soooo much faster than DOS I/O? The "BASICS" disk provided with DOS and AP for loading the language card with the basic not in ROM uses AP format. That's why it can load the language card so quickly. The assembler provided with AP is very nice. It supports macros and everything (golly gee). My only problem with it is that it assembles 6502 code. More on this later. For the $295 it costs (I believe that's the cost for just the software), it ain't bad. It does require 64k of RAM, and if you don't want to go crazy, you should have two disk drives. My problems with the system follow. It's slow. Sloooooooow. 6502 (8 bit brain damaged micro processor) running at a measley 1Mhertz + a software simulated machine on it = slooooooooooooooow. The other big problem I always run into is EXEC ERROR #4 (stack overflow). The only answer to this is to segment and swap procedures. This leads to (you're not going to believe this) slower execution time. I really hate waiting 20 minutes to get a stack overflow right before getting the output. These problems really aren't with AP. They're with the semi-evolved brain damaged device we jokingly call a computer: The Apple ][ :-(. Other things which bother people in AP include its menu driven "shell", its lack of I/O redirection, and the Apple's lack of interrupts. Part of AP's slowness comes from its type ahead buffer. Since the Apple's keyboard is not interrupt driven, AP must poll the keyboard between executing p-code instructions. This lack of keyboard interrupt also means that the soft break (default ctrl-@) won't alway's stop a program. There are many other little annoyances, such as the fact that swapon; in chainstuff doesn't work until another program is chained to, but they are too numerous and technical to write a general article on. As far as micros go, I'd like to have a computer with a 68000, a meg or so of memory, a few megs of disk space, and a Un*x/Un*x like OS. But until then I'll keep my brain damaged Apple, and keep running Apple Pascal :-). -- mark feldman UUCP : {seismo,allegra,brl-bmd}!umcp-cs!feldman CSNet: feldman@umcp-cs Arpa : feldman.umcp-cs@CSNet-relay