theo@natmlab.dms.oz (Theo ten Brummelaar) (12/23/86)
A second attempt .. apols to those who have read this before.
I am running a Unix system on a pdp 11/73.
As you may or may not know this machine/OS combination assigns 64k to programme
and 64k to data for any single process. I am doing a fair amount
of image processing work and would dearly love to know a way
to squeeze more memory into a single process (I have 1.5M all together).
Surely someone has faced this problem before ... did you solve it ? How ?
Thanks in advance
----------------------------------------------------------------------------
Time flies like an arrow , fruit flies like an orange.
----------------------------------------------------------------------------
ACSnet: theo@natmlab CSNET: theo@natmlab.oz
ARPA: theo%natmlab.oz@seismo.css.gov JANET: natmlab.oz!theo@ukc
UUCP:{enea,hplabs,mcvax,prlb2,seismo,ubc-vision,ukc}!munnari!natmlab.oz!theo
----------------------------------------------------------------------------mike@blia.BLI.COM (Mike Ubell) (01/07/87)
In article <1116@natmlab.dms.oz>, theo@natmlab.dms.oz (Theo ten Brummelaar) writes: > .....I am doing a fair amount > of image processing work and would dearly love to know a way > to squeeze more memory into a single process (I have 1.5M all together). > V7 (PDP11) Unix had some support for process text overlays. Of course none of it was documented and we were unable to determine the intentions of ld and had to rewrite it for our needs. As I recall we had to modify adb and put a hook or two in the kernel to debug the stuff nicely.
guy%gorodish@Sun.COM (Guy Harris) (01/07/87)
> V7 (PDP11) Unix had some support for process text overlays. Of course > none of it was documented and we were unable to determine the intentions > of ld and had to rewrite it for our needs. As I recall we had to modify > adb and put a hook or two in the kernel to debug the stuff nicely. If I remember correctly, some Bell Labs memorandum said this was originally stuck in to support the overlay mechanism used by the port of DEC's FORTRAN IV-PLUS compiler to UNIX. (It certainly worked the same way that the overlaying stuff in the Harvard Science Center PDP-11 UNIX did.) However, that port also included a linker that understood DEC's object file format; the support for this format from the standard UNIX linker looked pretty primitive. The idea was that each path through the overlay tree got an executable image of its own. The root segment was the main 410/411 image, and the others were 405 images. When it came time to move to another path through the tree, the overlay manager would "exec" the appropriate 405 image. A 405 image would replace the text but leave the data and stack unchanged.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/08/87)
It is perhaps worth pointing out that several PDP-11 UNIX implementations, including the JHU/BRL PDP-11 UNIX and I believe 2.9BSD, included support for user-mode text overlays. (The BRL implementation is better than Berkeley's, naturally.)
bp@nyit.UUCP (Bruce Perens) (01/09/87)
> In article <1116@natmlab.dms.oz>, theo@natmlab.dms.oz (Theo ten Brummelaar) writes:
(He wants to run `more memory in a process')
Berkeley Unix 2.9 has a nifty segmentation-register overlay system.
You can't get better than that for the PDP-11. I had to wedge the
code from 2.8's overlay system into Version 6 to support an existing
application. I found their overlay code well-written and fast.
Bruce P.