PDP8 / ETOS
Rick Murphy
rick at rickmurphy.net
Mon Oct 19 18:41:40 CDT 2015
At 07:07 AM 10/19/2015, Johnny Billquist wrote:
>By the way, could you describe how you managed to squeeze some memory
>from ADVENT? And if the first free location is 70000, then it sounds
>like it would be possible to run in 28K.
The primary way to cut memory usage was recoding the main function
(ADVENTURE is one huge Fortran module) to use more compact code. The
"compiler" is a really dumb code generator on the back end of a parser,
and emits a lot of redundant instructions and poor code sequences. For
example, "J = J + 1" gets output as something like
FLDA J
FADD #LIT+xxxx (where the reference is to a literal with
floating point value 1)
FSTA J
You can do that with two instructions:
FLDA ONE
FADDM J
Putting common literals on the base page also makes the instruction
stream shorter.
Or, redundant loads like
IF (DTOTAL .EQ. 0) GOTO 2000
IF (DTOTAL .EQ. 1) GOTO 74
Would emit
FLDA DTOTAL
JEQ #2000
FLDA DTOTAL
FSUB #LIT+xxxx
JEQ #75
That second FLDA can be dropped.
Also, for small literals, the code
K = 52
would compile to
FLDA #LIT+xxxx
FSTA K
Replacing that with
LDX 64,0 / put 52 (64 octal) into index register 0
XTA 0
FSTA K
That's smaller, since you don't store a full float literal for 52 (3
words), and the LDX/XTA is more compact.
Lots and lots of fun like that. What an space optimizer would do if
there was one. :)
I don't know how close this is to falling below the 28K boundary, but
it's just barely made the 70000 limit. It's entirely possible that you
could get ADVENT to run on a 28K system if you only used resident
drivers (SYS, for example..) but that would require changes to the
USR.RA code to configure it to expect only 28K. Basically, I'm out of
ideas for continuing bumming of space and didn't think 28K versus 32K
was all that big a deal. (i.e. I don't think there's many machines at
the 28K limit. Now if it was close to working on 16K it would be worth
another major pass.)
-Rick
More information about the cctech
mailing list