Path: utzoo!attcan!uunet!mcvax!ukc!stl!stc!root44!aegl From: aegl@root.co.uk (Tony Luck) Newsgroups: comp.unix.wizards Subject: Re: Problem with xstr Message-ID: <638@root44.co.uk> Date: 22 Sep 88 09:16:55 GMT References: <4252@thorin.cs.unc.edu> <145@taux02.UUCP> Reply-To: aegl@root44.UUCP (Tony Luck) Organization: UniSoft Ltd, London, England Lines: 29 In article <145@taux02.UUCP> amos@taux02.UUCP (Amos Shapir) writes: >Unless you use a pdp11 with separate I/D space, the solution is to just >throw out all the xstr stuff from your makefiles, and compile normally >instead. > >Xstr is a hack for putting strings, which are supposed to be read-only, >into the executable's text (code) space. This makes more room for data >on machines with limited address space. On 32-bit machines, this >approach is obsolete and causes more trouble than benefit. I don't think that xstr is any use on a split I/D space machine as you'd have to bodge the compiler to address modes that refer to I-space addresses rather than D-space when fetching bytes from the strings. (But I could be wrong about this ... I went straight from a pdp 11/34 (no split I/D space) running version 6 to a VAX running 4.1bsd ... talk about culture shock!) Xstr isn't a hack for ... making more room for data. It is a hack to allow you to share the strings between executables - so if you have some word processor package that is packed full of cute error messages you don't have 50K of memory used for strings in each and every copy of the program running. It's probably still obsolete though as with demand paging you can probably leave all those strings on disk ... and with silly amounts of memory (the "little" machine on my desk has 16 Mbytes ... but please don't let this be the start of a "mine is bigger than yours" waste of net bandwidth) perhaps there are more important things to worry about than saving a few kilobytes. -Tony Luck (UniSoft Ltd.)