alex@umbc3.UUCP (12/03/87)
In porting KCL lisp to my AT&T 3b1, I ran into the problem that I
thought I had left behind when I swore off MSDOS for life, image size
restrictions. the 3b1 has a process size limit of ~2.5meg for text+data+stack
that is hardware set (I think). KCL boots up in ~2.1meg (with all the bells
and whistles) which only leaves ~400K to play with. That sounds like alot,
but it goes too fast for my liking. I can pick up another 700K by not loading
the compiler or on line help, but that means keeping two executables at
>1.5meg text each, and the compiler is seriously hampered by the lack of space.
(It blew up trying to compile 30K of lisp source :-( )
SO: What to do? I dug through the linker startup files and the system
include files and came up with a load pattern that looks like
0 - 0x80000 not used/useable, entry point at 0x80000
0x80000 - 0x300000 user program area. max brk() = 29f000
0x300000 - 0x380000 space for shared librarys
0x380000 - 0x400000 kernal space
and a max virtual address of 400000. While I understand what the numbers mean,
at this point I run into a gray area of my UN*X expertise. As I recall the
Mc68010 processor in my machine has 24 address pins, which corrisponds to the
4meg virtual address limit (2^24). so, trying to squeeze blood from a turnip...
the file /lib/shlib is ~128K and the largest mapped address in shlib.ifile
is 0x3818d0. Is the memory above 0x380000 a straight map from shlib?
and if so can I add 380k of lisp routines (or screen drivers, etc) and
add addresses to an ifile.... Or can I dynamically allocate this memory
somehow? KCL supports a relocatable paging allocation scheme?
as an alternative, can I put 3/4 of GNU Emacs in shlib and have an emacs
that boots faster than ed? is shlib in a special format or just
stripped .o files catted together?
can I remove the 0x29f000 stack/heap boundry and set up a configuration
scheme that lest the stack fight the heap for memory, probably coupled
with a disk pager, etc. this seems to be the most realistic concept,
(at least the disk demand paging idea as the allocation system is page
based). i remember reading a bsd manual that talked about resetting the
stack limit.
whats below 80000? can I have it if I ask nice?
Any body got any other ideas?
:alex.
alex@umbc3.umd.edu