alexande@unc.cs.unc.edu (Geoffrey D. Alexander) (09/18/88)
I am using xstr as follow: cc prog.c -E | xstr -v - cc x.c -c -O -o x.o cc xs.c -c -O -o xs.o -R cc x.o xs.o -o prog rm x.c x.o xs.c xs.o strip prog In some cases the C preprossor can generate fairly large lines, especially when processing nested macros. I am running to a problem with xstr producing a syntatically incorrect translation on these large lines. It appears that xstr is partially substituting for a string. For example, the string "test it" might be substituted with "(&xstr[0])t it" in x.c where &xstr[0] references "tes" in xs.c. Does anyone have a suggestion on how to get around this problem with xstr? Note that I am running on SUN BSD UNIX 4.2. Please e-mail responses directly to me. Thanks, Geoff
amos@taux02.UUCP (Amos Shapir) (09/19/88)
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. -- Amos Shapir amos@nsc.com National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 TWX: 33691, fax: +972-52-558322 34 48 E / 32 10 N (My other cpu is a NS32532)
jfh@rpp386.Dallas.TX.US (The Beach Bum) (09/21/88)
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 loser in a separated i & d space system. xstr places the strings into the pure text segment which is not addressable from d-space. >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. it also makes the strings shared text. all constants should be put into a constants section and shared [ hmmm. found a use for "const" !!! ]. this is a real win for programs which have considerable amounts of constant character data. -- John F. Haugh II (jfh@rpp386.Dallas.TX.US) HASA, "S" Division "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias
alexande@unc.cs.unc.edu (Geoffrey D. Alexander) (09/22/88)
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 beg to differ. I am running on SUNs (2, 3 and 4). The SUN C compiler generates a seperate copy of a string each time it occurs. If I have a string in a nested macro, this could get expensive. For example, say I have a 99 character string in a macro that gets invoked 100 times. Thus, without xstr the string storage is 10,000 bytes, with xstr it is 100 bytes. Multiply this by a few dozen strings. You end up with a significant savings in program size. I have yet to receive an answer to my question. Does anyone know how to make xstr handle large lines potentially generated by the C preprocessor? Geoff Alexander
alexande@unc.cs.unc.edu (Geoffrey D. Alexander) (09/22/88)
In article <4322@thorin.cs.unc.edu>, I said: > > I have yet to receive an answer to my question. Does anyone know how to make > xstr handle large lines potentially generated by the C preprocessor? Well, I found the source to xstr. Simply changing the three occurances of BUFSIZ to BUFSIZ*16 fixed my problem. Geoff Alexander
aegl@root.co.uk (Tony Luck) (09/22/88)
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.) <aegl@root.co.uk>
aida@porthos.csl.sri.com (Hitoshi Aida) (09/23/88)
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. No! You can't put strings into code segment on separate I/D machines! The reason why xstr makes more room is because same strings will be shared within a program, not because they will go to code segment. -------- Hitoshi AIDA (aida@csl.sri.com) Computer Science Lab, SRI International
chris@mimsy.UUCP (Chris Torek) (09/24/88)
In article <638@root44.co.uk> aegl@root.co.uk (Tony Luck) writes: >Xstr isn't a hack for ... making more room for data. It is a hack to allow >you to share the strings between executables .... [second ellipsis mine] While xtr is *primarily* a hack for sharing strings, it is also a hack for making more room for data. In particular, if you have some code that looks like, e.g., printf("%s %d\n", a, b); ... printf("%d\n", c); xstr compiles this to printf(&xstr[OFFSET], a, b); ... printf(&xstr[OFFSET+3], c); (where OFFSET is some constant). Presto, one copy of % d \n \0 deleted! -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
amos@taux02.UUCP (Amos Shapir) (09/25/88)
Thanks to all people who corrected my mistake - separate I/D pdp11 cannot support text-segment shared data. It's been a long time since I hacked a pdp11 :-( I still think xstr is a hack, though, especially with the new keyword 'const' added to standard C. -- Amos Shapir amos@nsc.com National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 TWX: 33691, fax: +972-52-558322 34 48 E / 32 10 N (My other cpu is a NS32532)