[TUHS] tool (that wnj wrote?) that reduced the data segment size?

[TUHS] tool (that wnj wrote?) that reduced the data segment size?

[Norman Wilson]

I'm too tired to dig for the exact words in the ISO standard,
but I had the impression that the official C rule these days
is that the effect of writing on a string literal is undefined.

So it's legal for an implementation to make strings read-only,
or to point several references to "What's the recipe today, Jim"
to one copy of the stripng in memory, and even to point uses of
"Jim" to the tail of the same string.  Or both.

It is also legal for every string literal to reside in its own
memory and to be writable, but since the effect is undefined,
code that relies on that is on thin ice, especially if meant to
be portable code.

I have used, and even fixed (unrelated) bugs in, a compiler
that merged identical strings.  I forget whether it also looked
for suffix matches.  Whether the strings went in read-only
memory was up to the code generator (of course); in the new
back-end I wrote for it, I made them so.  This turned up quite a
few fumbles in very-old UNIX code that assumed unique, writable
string literals, especially those that called mktemp(3).  To my
mind that just meant the programs needed to be fixed to match
current standards (just as many old programs needed fixes to
compile without error in ISO C), so I fixed them.

I didn't (and still don't) like Joy's heavy-handed hack, but I
see his point, and think it's just fine for the language rules
to allow the compiler to do it hacklessly.

Norman Wilson
Toronto ON

[TUHS] tool (that wnj wrote?) that reduced the data segment size?

[Charles Anthony]

On Sat, Nov 28, 2015 at 3:30 PM, Norman Wilson <norman at oclsc.org> wrote:

>
> I didn't (and still don't) like Joy's heavy-handed hack, but I
> see his point, and think it's just fine for the language rules
> to allow the compiler to do it hacklessly.
>
>
IIRC, in "The Design of an Optimizing Compiler", it says something like:

"The Optimizing Compiler Writer's Motto: It is no sin to make a wrong
program worse."

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151128/ad9a22a4/attachment.html>

[TUHS] tool (that wnj wrote?) that reduced the data segment size?

[John Cowan]

Charles Anthony scripsit:

> "The Optimizing Compiler Writer's Motto: It is no sin to make a wrong
> program worse."

It is if the rules for which programs are wrong are essentially beyond
human comprehension on the fly.  Anyway: "That program has about a
thousand bugs.  Which would you rather, that we fixed all the bugs or
that we made it run a thousand times faster?"

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Heckler: "Go on, Al, tell 'em all you know.  It won't take long."
Al Smith: "I'll tell 'em all we *both* know.  It won't take any longer."

[TUHS] tool (that wnj wrote?) that reduced the data segment size?

[Nick Downing]

Guys I wrote a more modern version of xstr for a project (porting PDP11
utilities and games to a modern compiler for a different embedded system).
How it worked was similar to i18n utilities on a modern system. (I planned
to internationalize later). So what it did was remove any strings bracketed
with _("blah blah") to a strings file and then replace with a 32-bit
integer offset into the file. I had utilities like _printf(long off, ...)
which would access the strings file to get the necessary string and print
it, or just _strdup() which would bring it into memory where the programmer
could use as normal and free when done. What I did next was to have the
linker treat the strings file as a resource and merge it into the
executable, so that with a little trickery the strings could be directly
accessed from flash ROM while not taking any of the precious 64 kbytes RAM
in the program's data space. Happy to dig this up and share.
Nick
On 30/11/2015 2:26 PM, "John Cowan" <cowan at mercury.ccil.org> wrote:

> Charles Anthony scripsit:
>
> > "The Optimizing Compiler Writer's Motto: It is no sin to make a wrong
> > program worse."
>
> It is if the rules for which programs are wrong are essentially beyond
> human comprehension on the fly.  Anyway: "That program has about a
> thousand bugs.  Which would you rather, that we fixed all the bugs or
> that we made it run a thousand times faster?"
>
> --
> John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
> Heckler: "Go on, Al, tell 'em all you know.  It won't take long."
> Al Smith: "I'll tell 'em all we *both* know.  It won't take any longer."
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151130/db77d327/attachment.html>

[TUHS] tool (that wnj wrote?) that reduced the data segment size?

[Erik E. Fair]

The xstr(1) program is still maintained in the NetBSD distribution.
It's not a part of the C compiler - it's much more akin to a C
pre-processor:

	http://man.netbsd.org/7.0/usr/share/man/html1/xstr.html

See also mkstr(1):

	http://man.netbsd.org/7.0/usr/share/man/html1/mkstr.html

As ham-handed as these tools are, they can be used for input to
manual programmer string storage reduction.

	Erik <fair at netbsd.org>

[TUHS] tool (that wnj wrote?) that reduced the data segment size?

[Doug McIlroy]

> Woe betide the user if any string was changed at run time...

That was then. Now it would be OK to do so for const data.
(Unless the tool chain has discarded const indications.)

Doug

[TUHS] tool (that wnj wrote?) that reduced the data segment size?

[Larry McVoy]

On Sat, Nov 28, 2015 at 10:44:58AM +1100, Dave Horsfall wrote:
> On Fri, 27 Nov 2015, Larry McVoy wrote:
> 
> > I've gotten sucked into an embedded system project and they are running 
> > out of memory.  I have a vague memory of some sort of tool that I think 
> > Bill Joy wrote (or maybe he told me about it) that would do some magic 
> > processing of all the string constants and somehow it de-dupped the 
> > space.
> > 
> > Though now that I'm typing this that doesn't seem possible.  Does this 
> > ring a bell with anyone?  I'm sure it was for the PDP 11 port.
> 
> I think you're referring to an abomination called "xstrings" (or "xstr"?).

Yup, that's it.  Cool, thanks.

> It was described by a colleague of mine as "about as subtle as a car 
> crash"; it worked by comparing strings at compilation time, even unto the 
> tails of said strings.
> 
> Woe betide the user if any string was changed at run time...

I get it.  I also get that I have 32KB of RAM and I'm down to my last 1.2KB.

--lm

[TUHS] tool (that wnj wrote?) that reduced the data segment size?

[Dave Horsfall]

On Fri, 27 Nov 2015, Larry McVoy wrote:

> I've gotten sucked into an embedded system project and they are running 
> out of memory.  I have a vague memory of some sort of tool that I think 
> Bill Joy wrote (or maybe he told me about it) that would do some magic 
> processing of all the string constants and somehow it de-dupped the 
> space.
> 
> Though now that I'm typing this that doesn't seem possible.  Does this 
> ring a bell with anyone?  I'm sure it was for the PDP 11 port.

I think you're referring to an abomination called "xstrings" (or "xstr"?).

It was described by a colleague of mine as "about as subtle as a car 
crash"; it worked by comparing strings at compilation time, even unto the 
tails of said strings.

Woe betide the user if any string was changed at run time...

It ranks right up there with nargs() as What Not To Do.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] tool (that wnj wrote?) that reduced the data segment size?

[Larry McVoy]

I've gotten sucked into an embedded system project and they are running out of
memory.  I have a vague memory of some sort of tool that I think Bill Joy
wrote (or maybe he told me about it) that would do some magic processing of
all the string constants and somehow it de-dupped the space.

Though now that I'm typing this that doesn't seem possible.  Does this ring
a bell with anyone?  I'm sure it was for the PDP 11 port.

Thanks,

--lm