[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bigger heaps
- To: Charles Dolan <cpd@UCLA-LOCUS>
- Subject: Re: Bigger heaps
- From: Jim Meehan <Meehan@YALE.ARPA>
- Date: Wed ,13 Mar 85 09:42:52 EDT
- Cc: T-Users@YALE.ARPA, Adams@YALE.ARPA
- In-reply-to: Charles Dolan <cpd@UCLA-LOCUS.ARPA>, Mon, 11 Mar 85 13:55:18 PST
A while ago Norman Adams sent out a message describing the way that
the Apollo allocate the heaps. He mentioned that it does grab as much
as it could on the Terns.
I assume you mean "does NOT grab ..."
We have 5 terns at UCLA, and were wondering how we could use more
of the virt. addr. space. Can anyone give the changes to the
startup code.
The change is simple, but the installation is not. There's a loop
in BIGGEST_HOLE in TTOP.PAS that scans the virtual address space,
performing a test on every segment (32 segments per megabyte). The
loop stops at 14 megabytes or so. Simply let it run to 256 megabytes,
and do NOT assume that the "hole" at the end of the address range is
free.
The installation isn't simple, because the test involves an unreleased
system call, and TTOP.PAS requires that you "%INCLUDE" some unreleased
(i.e., Apollo-proprietary) insert files. If you have a source license\n from Apollo, as Yale does, or if you get Apollo to allow you to have
copies of the relevant insert files, you can make the change yourself.
If you had a T license from us (Cognitive Systems), we could send you
the new executable T (though not the Apollo-proprietary sources, of
course), since we made this change to our version. Otherwise, assuming
you have a T license from Yale, someone at Yale will have to fix TTOP
for you. That may be difficult, since there's no official support
for T work at Yale these days. Norman's just being a good citizen
by answering the mail.
-------