[comp.lang.scheme.c] pmax can have Heap_In_Low_Memory

max@Neon.Stanford.EDU (Max Hailperin) (09/02/89)

Although the pmax (DecStation 3100) and other MIPS-based machines by
default don't have Heap_In_Low_Memory, it is possible to correct that
by including the -Wl,-D,800000 loader flag.  This results in approximately
a 7 percent reduction in code size and a 6 percent reduction in execution
times (in a very rough preliminary measurement; your milage will vary).

This can be done for both scheme 6.1.2, assuming you add a pmax configuration
(it doesn't come with one), and for 7.0.0, modifying the supplied pmax
configuration.  [MIT Scheme Team take note: this is a suggestion for an
improvement to the 7.0 distribution.]  The techniques are slightly different
however:
 1) In either case, change the entry in microcode/config.h to #define
    the symbol Heap_In_Low_Memory .
 2) a) If 6.1.2:
       change the definition of CC in makefiles/pmax to cc -Wl,-D,800000
    b) If 7.0.0:
       add to microcode/m/mips.h #define LD_FLAGS_MACHINE -Wl,-D,800000

There are three potential difficulties with this modification, none of
which appears to be problematic:
 1) Scheme will die horribly if it's text segment ever becomes more than
    4 Mb.  As it's an order of magnitude less currently, this isn't a big
    threat.
 2) The  heap/stack/constant area sizes can not be set as large as without
    the modification.  They can still be set approximately twice as large
    as the defaults, however, so this should suffice for most users.
    There may be a few really serious hackers for which this could be
    a problem, however.  Thus, a note in the documentation would definitely
    be in order.  One possible approach that might allow big heaps and
    high performance would be to shorten the tag field to 7 bits.  I haven't
    looked into this carefully (since I don't need big heaps) but it looks
    like the change shouldn't be tough, and shouldn't hurt the performance,
    since the MIPS can do single-cycle shifts, and hence doesn't need to
    optimize as a load-byte.
 3) Particularly if the heaps are made bigger, they will encroach on the
    address range reserved for shared libraries.  This doesn't appear to
    be an issue with the current software.

Enjoy.