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