Re: compressing Applesoft

[Benoit0123 <bgilon@free.fr>]

gids.rs wrote:
> There are some pretty good utilities in the Nibble magazines for removing
> redundant information from a program to allow it to run a little faster. 
> After all, applesoft is known for its not so blazing speed.  One of my
> favorite past times is re-inventing the wheel.
> 
> There are utilities to remove REMarks, reduce variables to a single
> letter.
> combine multiple lines into one, etc.  These programs are about $400
> (1024)
> bytes in length, each, as entered from the magazine.
> 
> My reinvention will do the following:
> 
> it removes REMarks, it removes semicolons where not needed (does not
> remove
> from INPUT statement, between variables A;B;C or before a colon or at the
> end of a line), it removes extra letters of variables down to 2 letters,
> it
> removes variables after the NEXT token and converts its variables from
> NEXT
> I,J,K to NEXT:NEXT:NEXT  - which is supposed to execute faster, and all
> was
> done in less than $1B0 (432) bytes and is 4x faster than the single
> programs listed above.  May add the feature to combine lines later.  I
> dislike DATA statements but it would be neat to see an entire list of DATA
> statements combined into one.  Even though the line length would be way
> greater than 249, this compressed program would not be used for editing,
> just space savings and speed.
> 
> If I only knew 25 years ago what I know now.
> 
> Rob
>
IMHO some higher level analysis (either static or dynamic i.e. analysis
while program running) could also lead to:
a) declare most used variables first, as search for a variable address
(either simple or array) is pure sequential search in a "declared
first/looked for first" order.
b) insert an adhoc POKE for making GOTO and GOSUB run faster;
c) replace any integer simple variable reference within your program
expressions by a reference to a FP variable, and, in instructions to set its
value, insert a call to INT(..) embracing the whole expression, thus every
time such integer variable appears in an expression, Applesoft would not
call the routine to convert it to FP internally, thus speeding up
evaluation.
d) If the USR function vector is not used by your program already, then
point the vector tp a RTS location, this time the FP value returned will be
the existing FP value and expression such as: A(I,J) * A(I, J) replaced by
A(I, J) *  USR() will avoid a second evaluation for three sub expressions:
I, J and A(I,J). This is to be tested through.

BTW, items a) and d) are somewhat covered by the latest relaease of Perrsoft
(OSS project).
HTHATS,
Benoît
--
Growing old is mandatory
Growing up is optional...
But the other way round is as valid.... ;-)