fostel@ncsu.UUCP (09/22/83)
Yes, the P-system IS slow. Someone suggested that the old saw about
90% of the time in 10% of the code was applicable here. False. The
P-system is orders of magnitude slow. My 68000 based P-system can do
only about 10K cycles of a "i=i+1;" loop body in a second. You are
not going to get around that without circumventing the P-system. There
are also architectural problems regarding the address space: 16-bit.
The usual trick of writing some portion in ASM code is very awkward,
since while you can call ASM from Pascal, the result is substantially
larger code (p-code IS small) which is a real problem in 64K, and
severe design constraints. You have to write Lots of asm code, not
just a crucial loop to save 50%. You can not re-enter the P-system
from the ASM code except by returning so you can not use any of the
units for utility purposes within non-critical portion of slow loops ...
But the key point is that it is SOOOO slow that massive ASM code is
required to avoid any weak links in the performance.
----GaryFostel----CSvax:Pucc-H:ags@pur-ee.UUCP (09/24/83)
So the P-system is "orders of magnitude" slow because it can only do 10K cycles of i=i+1 per second? As I recall, this discussion started when someone claimed that the Atari had a better operating system than the Apple, and quoted statements in Atari BASIC and Applesoft BASIC to prove it. I think a microcomputer operating system need not be considered bad merely because it does only 10K loop iterations per second. For the record, I never said that P-code wasn't slow. It is, however, considerably faster than BASIC, besides being MUCH easier to work with. What I said was that since Apple Pascal has a resident assembler, the system is fast enough for applications for which the 6502 is fast enough. I stand by that statement. I am typing this article on an Apple which is running my communications program, which I wrote in Pascal and assembly language. P-code is not nearly fast enough to keep up at 1200 baud, but the program manages by using interrupts and by having the critical routines run at machine speed. I do not consider this to be a particularly large coding effort at the assembly language level. I am still adding things to the package, but most of what I am doing now is in Pascal, since it does not need to be particularly fast. I don't think this program is atypical. Size doesn't worry me, either, since the system supports segmentation and therefore does not require that the entire program fit in 64K (or even 128K). Dave Seaman Pucc-H:ags