Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!uunet!umbc3!alex From: alex@umbc3.UUCP Newsgroups: unix-pc.general Subject: wot? no memory? arrghh... Message-ID: <610@umbc3.UMD.EDU> Date: Thu, 3-Dec-87 01:44:32 EST Article-I.D.: umbc3.610 Posted: Thu Dec 3 01:44:32 1987 Date-Received: Sun, 6-Dec-87 22:44:43 EST Reply-To: alex@umbc3.UMD.EDU (Alex S. Crain) Organization: University of Maryland, Baltimore County Lines: 49 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