Path: utzoo!utgpu!watmath!att!dptg!rutgers!gatech!udel!mmdf From: Leisner.Henr@xerox.com (marty) Newsgroups: comp.os.minix Subject: Re: GNU cc, etc. Message-ID: <21751@louie.udel.EDU> Date: 15 Aug 89 14:47:54 GMT Sender: mmdf@udel.EDU Lines: 35 Virtual memory is kind of a necessity for gcc. Gcc reads in a file, converts to an internal representation of the C module (rtl -- register transfer language) and then munges on this in-core RTL representation before generating assembler code at the end. Big files require significant virtual memory -- virtual memory is kinda implied for the GNU system. [BTW -- I agree with the methodology -- don't handicap the programmers due to hardware limitations. Virtual memory is now over 25 years old]. Minix current memory manager granularity is process sized, where the process size is defined in the a.out header. For something like gcc, it would be useful to grow the data segment and the stack segment on demand (i.e via stack faults and brk()), and reduce the granularity. On simpler machines, the pages would be sequential and the text, data and stack would be contiguous. On machines which have page tables, the pages could be located anywhere in disk or core. ast elected to leave out virtual memory (sorta an "exercise for the reader"?). I feel it would be most useful to put machine dependent files in the memory manager to support page-level virtual memory. For simpler machines, the files wouldn't do anything except preserve an architecture [this is in lieu of ifdefs]. I would like to see virtual memory added to Minix -- I really am not sure how the pieces would work. marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: leisner:wbst139:xerox UUCP: hplabs!arisia!leisner