parker@rochester.UUCP (Clint Parker) (09/20/83)
From: Clint Parker <parker>
There has been several messages about ACTION! here lately and I felt that
some comments of my own were in order, so here they are.
First I would like to clear up some issues. The plan is to sell a copy of
the run-time library for about $30 for NON-commercial use. The $300 (which
is about right) would be the fee for commercial use. The run-time library
allows you to create stand-alone object files. Another message claimed that
you had to do "count ==+ 1" and that "count = count + 1" woudn't work. This
is simply NOT true, either statement will work.
As to the cartridge being "chock full of bugs and rough edges", I won't say
that it has no bugs, but I don't think it is that bad. Below is a list of
all the known bugs (I won't address the rough edges, although many of them
have been fixed as well), all of which have been fixed (although I'm not
sure OSS is shipping the new version yet). There might be more, but these
are the only one reported so far (I'm doing this from memory so I might
leave one out, but I don't think I will).
a) Division where the divisor is in the range of 128 to 255 doesn't
always generate the right answer. The chance of the answer being wrong
increases the closer you get to 255. FIX: OSS has a debugged division
routine which you can include at the beginning of your program to correct
the problem.
b) UNTIL statements with compound conditional expressions involving
AND don't work. FIX: Don't use AND in an UNTIL expression, if you need to
use an IF ... THEN EXIT FI before the OD to terminate the loop.
c) User defined TYPE field of type CARD or INT are not correctly addressed
by pointer variables unless they are the first field of the TYPE. FIX: Don't
use CARD or INT fields with record pointers (sorry folks).
d) Record (user defined TYPEs) variables and pointers don't work in
conditional expressions. FIX: Again, don't use them.
e) ReadBlock doesn't work with sizes greater than 255. FIX: Don't use
ReadBlock for big blocks of memory.
Now I don't want to hear any comments about the manual (me personally that is),
I was not the one who wrote it. Yes, I know that it has a lot of errors in it,
but most of them have been corrected in the manual OSS is now shipping. If you
know of any errors not listed here, please let OSS (or me) know so that they
can be fixed. Every error reported to OSS so far has been fixed and I am sure
that all future bugs will be handled as well.
As for the problem involving not being able to tell how much memory is left, I
tend to agree that it would be nice to have a command that tells you how much
memory is left, but there wasn't enough memory left (in the cartridge) to do
this. Oh well, you can roughly get an estimate of how much memory is left by
typing '>? $491^+$FFFE' (without the 's and >) in the monitor and looking at
the last number of the line printed. This is actually a better estimate of the
memory left since it is how much memory the compiler thinks it has (minus 2K
byte for the symbol table which is located just below HIMEM). There may be
more memory left since the Editor can fragment low memory during editing.
I am interested in hearing any comments (pro or con) about ACTION!.
Thank you,
- ClintBillHolland.es@PARC-MAXC.ARPA@sri-unix.UUCP (09/27/83)
What is ACTION ? is it like a BASIC COMPLIER> BILLHOLLAND.ES
sumit@rochester.UUCP (Sumit Bandyopadhyay) (10/01/83)
Hi there, Action! is probably one of the nicest thing that ever happened to Atari hackers. The system includes an editor, a compiler and a small monitor program. The whole thing fits in a 16k bank switched cartridge. You don't even need a disk drive to run the system. The language is like a small subset of C, but FAR better than things like SmallC etc. Action! generates real machine language code in one and a half pass! That's right, no assembler and stuff. Neither does it generate a series of function calls like in SmallC, most of the code generated is inline. Exceptions are things like division which the hardware does not support directly. But the best part of the story is that the compiler is incredably fast. If you are compiling from memory, for medium size programs you will hardly be able to time the compilation. The code that is generated is about 2 to 3 times larger and twice as slow as assembly code generated by an experienced programmer. Few of the differences with respect to some subsets of C: . The syntax is different . The language does not work on a stack.( which makes sense, because the 6502 gives you only 256 bytes of stack). Hence no recursion. . The language is statement oriented as opposed to expression oriented. . No semicolons(;) at all. . Statements are like IF <boolean> THEN .. ELSE .. FI WHILE <boolean> DO ... OD FOR .. DO ... OD etc. . There is EXIT from the innermost loop. . You can put in machine code inside Action! programs. . You have the ability to deal with hardware addresses from inside of your program. . You can include source files. Action! also comes with a substantial library of useful functions; which includes graphic routines and the like. The editor you get with the system is quite decent, and fast. The Action! system which includes the cartridge and the manual ( the only average thing in the package ) lists for about $99, but mail order places sale them for about $65. Sorry for the long letter. sumit@rochester