Commit c53cc1d9 authored by Robert Sprowson's avatar Robert Sprowson
Browse files

Annotate Squish

In the process of unrelated archiving an unsquished copy of Squish from 1989 was unearthed, allowing many of the variable names to be made meaningful after the sources were lost. Also created a document detailing operation from a large block comment.
Tested by comparing the output with Squish 1.15 from several heavyweight uses, eg. Alarm HForm Chars.

Version 1.16. Tagged as 'Squish-1_16'
parent dae3a50e
/* (1.15)
/* (1.16)
*
* This file is automatically maintained by srccommit, do not edit manually.
* Last processed by srccommit version: 1.1.
*
*/
#define Module_MajorVersion_CMHG 1.15
#define Module_MajorVersion_CMHG 1.16
#define Module_MinorVersion_CMHG
#define Module_Date_CMHG 02 Apr 2013
#define Module_Date_CMHG 28 Mar 2019
#define Module_MajorVersion "1.15"
#define Module_Version 115
#define Module_MajorVersion "1.16"
#define Module_Version 116
#define Module_MinorVersion ""
#define Module_Date "02 Apr 2013"
#define Module_Date "28 Mar 2019"
#define Module_ApplicationDate "02-Apr-13"
#define Module_ApplicationDate "28-Mar-19"
#define Module_ComponentName "Squish"
#define Module_ComponentPath "castle/RiscOS/Tools/Sources/Squish"
#define Module_ComponentPath "apache/RiscOS/Tools/Sources/Squish"
#define Module_FullVersion "1.15"
#define Module_HelpVersion "1.15 (02 Apr 2013)"
#define Module_LibraryVersionInfo "1:15"
#define Module_FullVersion "1.16"
#define Module_HelpVersion "1.16 (28 Mar 2019)"
#define Module_LibraryVersionInfo "1:16"
This diff is collapsed.
BASIC V program cruncher © Mike Harrison 1989
Apologies for the messy nature of this code - it was done in a hurry!
This program has been put into the public domain in the hope that someone
with the time and inclination will be inspired to do a decent machine
code version of it!
This utility crunches a BASIC program by shortening variables, stripping
out REMs and assembler comments, and concatenating lines
This has 3 benefits :
1) It takes less memory - the saving can be over 50% with big programs
using long var names (e.g. wimp applications)
2) It improves performance
3) It makes the program very difficult to read!
Variable crunching is highly optimised. The strategy is as follows:
For each of real,int,string,real array,string array,int array,FN,PROC:
1) leave all single letter vars alone - this is due to the assumption that
the program uses single letters for a reason - speed, or CALL parameters.
2) allocate unused single letter variables to the most commonly used
variables.
3) allocate 2 letter names to any remaining variables. Whilst generating
2 letter names, the first letter changes fastest, for optimum runtime
speed when BASIC is looking up the name.
If there aren't enough 2 letter pairs, TOUGH! (This will only happen if
the program has more than about 3,500 variables of one type!)
Decimal,Hex and Binary constants are converted to decimal, unless hex
would be shorter (e.g. &FFFFF is shorter than 1048575)
You may notice that the program can build a list of all numerics used -
this was intended to be used to allocate variables as constants for
frequently used numbers. This has not (yet) been implemented, as savings
would be small.
Line concatenation errs on the side of caution, and sometimes doesn't
join joinable lines. This has little effect on the cunched size
LIMITATIONS :
strange variations on the DIM address% space% construct may not work
e.g. DIM a%!24 b%
will get the position of the required space wrong
It is possible that mnemonics in lower or mixed case may cause
problems in certain circumstances, so stick to upper case
This cruncher will NOT cope with :
numeric constants with E notation (1E3,6E-4 etc.)
* commands immediately after THEN or ELSE - use a colon
e.g. IF fred ELSE :*thingy
References to line numbers (GOTO,GOSUB,RESTORE etc.)
These can usually be avoided, as ON ERRORs can be done as follows:
PROCinitialstuff
ON ERROR PROCmoan :REM will drop through to main loop
REPEAT
<main>
UNTIL <done>
RESTORE can be done by :
RESTORE +0 :REM restores to data on next line (cruncher won't join)
DATA 1,2,3,4
As most of this program is hacked up in BASIC, it is SLOW, often
taking a few minutes. This shouldn't be a problem, as programs only
need to be crunched when fully debugged etc.
Some speed can be gained by using a crunched version of the cruncher,
and using RAM Basic (or *RMFaster Basic in RiscOs)
Notes :
Crunched programs may be impossible to edit, as lines may detokenise to
longer than 256 bytes, and lack of spaces will confuse the tokeniser.
If a program uses libraries, these must be merged with the main code
(e.g. using APPEND), crunched, and then split back into the library
files. Otherwise, the variable/PROC names won't correspond!
Clever tricks using EVAL on variable names and READing data which
contains variable names obviously won't work!
There are almost certainly some obscure things that I didn't think of,
which won't crunch properly - sorry!
The technicolour listing of the crunched program is for diagnostic
purposes to identify any problems of miscrunching.
Tokens are in red, replaced variables in yellow, numerics in blue
and everything else in white.
Note thet you may see some spurious trailing colons, which won't be
in the crunched program image, and assembler mnemonics containing tokens
(MOVEq ORr AND EOR) won't be displayed correctly onscreen, but the saved
code will be OK
In case of problems, the list of name translations for each type can
be printed using PROCshowlist(xxxptr%) after the cruncher has finished,
where xxx is one of : real int string inta reala stringa proc fn
garbage in program can cause problems - e.g. comments between proc
definitions. Ensure REMs are present. This can cause wierd errors
like Bad Hex, Bad binary if there are & or % in garbage.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment