Back to the main page

Mailing List Logs for ShadowRN

Message no. 1
From: Dave Sherohman <esper@*****.IMA.UMN.EDU>
Subject: STRIPpers
Date: Tue, 20 Jul 1993 23:45:18 -0500
I like it Hayden, but (for the second time tonight, believe it or not...) I
have an additional restriction to impose - based upon your rationale for the
program's existence and workings, it would seem to me that a Strip program
would have to be custom-coded for the MPCP it was to run on (for pretty
much the same reasons as why the code becomes non-portable). Also, I think
it would be reasonable to allow for the use of a Strip with a lower rating
than the MPCP, but then the reduction is 5% * Strip Rating instead of
5% * MPCP Rating. (Coupled with MPCP-specific Strips, this would basically
just mean that you can throw together a basic Strip to improve your memory-
efficiency a little until you can finish the full-rated Strip for full
optimization.) Naturally, post-Strip size would be based solely off the
program's original (un-Stripped) size - no running Strip-6 over the same
program twice to get a 51% reduction; though you could run a Strip-1
without hampering a future Strip-5.

esper@***.umn.edu
Message no. 2
From: "Robert A. Hayden" <hayden@*******.MANKATO.MSUS.EDU>
Subject: Re: STRIPpers
Date: Wed, 21 Jul 1993 01:28:56 -0500
On Tue, 20 Jul 1993, Dave Sherohman wrote:

> I like it Hayden, but (for the second time tonight, believe it or not...) I
> have an additional restriction to impose - based upon your rationale for the
> program's existence and workings, it would seem to me that a Strip program
> would have to be custom-coded for the MPCP it was to run on (for pretty
> much the same reasons as why the code becomes non-portable). Also, I think
> it would be reasonable to allow for the use of a Strip with a lower rating
> than the MPCP, but then the reduction is 5% * Strip Rating instead of
> 5% * MPCP Rating. (Coupled with MPCP-specific Strips, this would basically
> just mean that you can throw together a basic Strip to improve your memory-
> efficiency a little until you can finish the full-rated Strip for full
> optimization.) Naturally, post-Strip size would be based solely off the
> program's original (un-Stripped) size - no running Strip-6 over the same
> program twice to get a 51% reduction; though you could run a Strip-1
> without hampering a future Strip-5.

Let me try to deal with this from two different directions:

--

1) How I envision STRIP working:

When you run STRIP on a program, it essentially checks for redundency and
removes redundant code (this is redundency within the program and between
the code and the MCP, not to be confused with the other proposal I made of
DEPENDENT PROGRAMS).

Let's pretend that you are compiling a program on your home-grown MCP.
You process it through STRIP. Let's pretend that STRIP finds a function
called 'Foo'. It essentially asks the following questions:

DOES 'Foo' EXIST IN THE MCP?
If yes, remove 'Foo' from program and go to next function
DO OTHER FORMS OF 'Foo' EXIST WITHIN THE PROGRAM
(such as 'Foo.4.Fuchi' 'Foo.4.Tandy', etc)
If yes, remove all other forms.

What this accomplishes is removing possibly multiple functions that are
changed only mildly for the type of MCP, or removing functions that are
already in the MCP. You can see where that could yield a savings in size.

2. STRIP V. MCP RATING <--> STRIP V. STRIP RATING

My thinking is, and I'll gladly accept THWAPS if need be, that the size of
the MCP (its rating) also is indicitive of the size of its own library of
functions. STRIP, as I am seeing it here, is really nothing more that a
small program that compares functions and removes redundency. Nothing
very fancy in and of itself. BUT, you can put in a little Game Balance{tm}
by requiring a STRIP program comparable in rating to the MCP of the deck
it is operating on. This can be reasoned that, for example, a rating:1
STRIP does not have the redundency checking of a rating:8 STRIP.

Perhaps a better rule would be that reduction in size is equal to (STRIP
rating x5) percent, and STRIP:rating cannot exceed MCP. Thus, a MCP:8 and
STRIP:6 would yield a 30% overall reduction in the size of all programs
compiled for that MCP. Now, if I replace the STRIP:6 with a STRIP:8, I
can recompile all of my programs (which takes time) and have a 40% savings
in space.

------

Does STRIP have to be unique to it's MCP?
---- ----- ---- -- -- ------ -- ---- ----

I'd tend to think no. As I've thought it through, STRIP is nothing more
that program comparing two things and I'd think it'd be pretty portable.
What it PRODUCES isn't portable in the least, but I'd think the STRIP
program itself is fairly non-unique.

{[> Robert A. Hayden ____ hayden@*******.mankato.msus.edu <]}
{[> \ /__ hayden@****.cs.mankato.msus.edu <]}
{[> \/ / aq650@****.INS.CWRU.Edu <]}
{[> #include <std_disclaimer.h> \/ <]}
-=-=-
GEEK CODE v1.0.1: GSS d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++
n-(---) h+(*) f+ g+ w++ t++ r++ y+(*)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Random Thought:

"Never ascribe to malice that which is caused by greed and ignorance."
-- Cal Keegan
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Message no. 3
From: Robert Watkins <bob@********.NTU.EDU.AU>
Subject: Re: STRIPpers
Date: Wed, 21 Jul 1993 07:20:22 +0000
>
>I like it Hayden, but (for the second time tonight, believe it or not...) I
>have an additional restriction to impose - based upon your rationale for the
>program's existence and workings, it would seem to me that a Strip program
>would have to be custom-coded for the MPCP it was to run on (for pretty
>much the same reasons as why the code becomes non-portable). Also, I think
>it would be reasonable to allow for the use of a Strip with a lower rating
>than the MPCP, but then the reduction is 5% * Strip Rating instead of
>5% * MPCP Rating. (Coupled with MPCP-specific Strips, this would basically
>just mean that you can throw together a basic Strip to improve your memory-
>efficiency a little until you can finish the full-rated Strip for full
>optimization.) Naturally, post-Strip size would be based solely off the
>program's original (un-Stripped) size - no running Strip-6 over the same
>program twice to get a 51% reduction; though you could run a Strip-1
>without hampering a future Strip-5.
>
>esper@***.umn.edu
>

But couldn't you get a STRIP package that had a large range of possible MPCP
and optimized itself?? For example: All Fuchi MPCP presumably have a large
chunk of code in common. This common code is why it's easier to upgrade an MPCP
than to write a new one at the higher level. So a STRIP program could be
written that covered the alternatives, and then optimizes itself. Of course,
you'd need a new program for each family of decks, and if, heaven help you,
you've modified the MPCP somehow (like removing the ID tags *whistle*), it
won't work, full stop.

Admittedly, the unoptimized STRIP would be LARGE.



--
Robert Watkins
bob@******.cs.ntu.edu.au
************ It wouldn't be luck if you could get out of life alive. ***********
Message no. 4
From: ntomlin <ntomlin@*****.VALDOSTA.PEACHNET.EDU>
Subject: Re: STRIPpers
Date: Wed, 21 Jul 1993 09:06:19 -0400
but isn't the compress program from VR doing that same thing
already or is a strip program working on active memory and compress
on stored memory?? I am in no way shape or form a computer person I
just wish I were.
Message no. 5
From: "Robert A. Hayden" <hayden@*******.MANKATO.MSUS.EDU>
Subject: Re: STRIPpers
Date: Wed, 21 Jul 1993 13:32:18 -0500
On Wed, 21 Jul 1993, Robert Watkins wrote:

> But couldn't you get a STRIP package that had a large range of possible MPCP
> and optimized itself?? For example: All Fuchi MPCP presumably have a large
> chunk of code in common. This common code is why it's easier to upgrade an MPCP
> than to write a new one at the higher level. So a STRIP program could be
> written that covered the alternatives, and then optimizes itself. Of course,
> you'd need a new program for each family of decks, and if, heaven help you,
> you've modified the MPCP somehow (like removing the ID tags *whistle*), it
> won't work, full stop.

I would simply say that, if you wanted to reduce the size of STRIP, you'd
just run STRIP on itself. It then becomes totally unportable and any
changes you make to you MCP will require a recompile.

That makes it simple and straight-forward. *shrug*

As for the "largeness" of STRIP, I don't think it would be that big (ie,
it wouldn't be HUGE), mostly because the program itself has fairly simple
operations to perform, simply comparing functions between the program
being compiled and the MCP (and within the program itself). Nothing to
exciting.

{[> Robert A. Hayden ____ hayden@*******.mankato.msus.edu <]}
{[> \ /__ hayden@****.cs.mankato.msus.edu <]}
{[> \/ / aq650@****.INS.CWRU.Edu <]}
{[> #include <std_disclaimer.h> \/ <]}
-=-=-
GEEK CODE v1.0.1: GSS d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++
n-(---) h+(*) f+ g+ w++ t++ r++ y+(*)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Random Thought:

FORTRAN? The syntactically incorrect statement "DO 10 I = 1.10" will parse and
generate code creating a variable, DO10I, as follows: "DO10I = 1.10" If that
doesn't terrify you, it should.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Message no. 6
From: "Robert A. Hayden" <hayden@*******.MANKATO.MSUS.EDU>
Subject: Re: STRIPpers
Date: Wed, 21 Jul 1993 13:36:07 -0500
On Wed, 21 Jul 1993, ntomlin wrote:

> but isn't the compress program from VR doing that same thing
> already or is a strip program working on active memory and compress
> on stored memory?? I am in no way shape or form a computer person I
> just wish I were.

Nope, compress essentially takes out the spaces in a program so that in
storing it, it takes up less room. When you run the program, it has to be
uncompressed.

STRIP, on the other hand, reduces size all around by7 removing redundancy
within the program, but sacrificing portability.

{[> Robert A. Hayden ____ hayden@*******.mankato.msus.edu <]}
{[> \ /__ hayden@****.cs.mankato.msus.edu <]}
{[> \/ / aq650@****.INS.CWRU.Edu <]}
{[> #include <std_disclaimer.h> \/ <]}
-=-=-
GEEK CODE v1.0.1: GSS d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++
n-(---) h+(*) f+ g+ w++ t++ r++ y+(*)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Random Thought:

The following appeared in my MCI bill this month:

MCI> President Bush is proclaiming July 22 as Rose Fitzgerald Kennedy
MCI> Family Appreciation Day, in honor of the 100th birthday of one of
MCI> America's most beloved and respected citizens. Throughout her life,
MCI> family has been of utmost importance to Mrs. Kennedy. Family
MCI> Appreciation Day calls upon Americans to rededicate themselves to family
MCI> values and relationships...
[ they then go on to encourage people to use the telephone a lot. ]

This Sunday, I encourage the following activities:

o Fornicate
o Get a divorce
o Shoot suction-cup darts at photos of JFK
o Fornicate
o Call up your long-distance operator and emit an ear-piercing shreik
o Tell your parents how they've screwed you up for life
o Assist a gay couple in adopting or conceiving
o Use the word "Chappaquiddick" (sic?) in a sentence
o Buy your pre-adolescent children a copy of Blue Boy
o Fornicate
o Spit on a rich person
o Fornicate

Thank you.

- Erb (cooper@**)
Church of the Four-day Workweek
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Message no. 7
From: Dave Sherohman <esper@*****.IMA.UMN.EDU>
Subject: Re: STRIPpers
Date: Wed, 21 Jul 1993 13:50:03 -0500
>1) How I envision STRIP working:

I basically agree with you, Hayden, on how Strip works. I'm just carrying
your non-portability a step further - if a program Stripped on my Fuchi
won't run on yours because of differences in what functions are usable
from the MPCP and/or where those functions are, then I would think that
my Strip wouldn't run on your deck because it'll be looking for the
wrong routines in the MPCP or be looking in the wrong places for them.

>2. STRIP V. MCP RATING <--> STRIP V. STRIP RATING

>Perhaps a better rule would be that reduction in size is equal to (STRIP
>rating x5) percent, and STRIP:rating cannot exceed MCP.

This is what I meant with my addition of letting Strip run on higher-
rated MPCPs. I just didn't state it very clearly, I guess.

>Does STRIP have to be unique to it's MCP?

>I'd tend to think no. As I've thought it through, STRIP is nothing more
>that program comparing two things and I'd think it'd be pretty portable.
>What it PRODUCES isn't portable in the least, but I'd think the STRIP
>program itself is fairly non-unique.

I don't see the two working together - either all MPCPs (or at least those
with the same producer) have the same routines in the same locations (in
which case you end up with Stripped code being portable) or else every MPCP
has a unique list of what routines can be found where, in which case the
Strip program has to know that list (ie be MPCP-specific), in which case it
would have to compare every sequence of instructions in the MPCP with every
sequence of instructions in the program in order to find the redundant
sequences. (Which would allow for a portable Strip, but it would take
forever and a day to run...)

And from TMont...

>Also, lets talk about real SE (Software Engineering) languages. C/C++, Ada,
>and a smitch of MODULA-2. I have yet to meet anyone who does SE with Pascal.

Irrelevant. Show me a reason to believe that anyone will be doing SE with
_any_ existing language 60 years from now. The point is that if a Pascal
compiler can look at eack block of code and 'decide' not to include it in
the final file if it can't be called, then it seems reasonable to assume
that the compilers of the future will be capable of doing so also. (That's
one thing I've never understood about C... Why the compiler grabs the
whole stinkin' library and drops it into the output file when only one of
the library's functions is ever going to be used by that program...)

esper@***.umn.edu
Message no. 8
From: "Robert A. Hayden" <hayden@*******.MANKATO.MSUS.EDU>
Subject: Re: STRIPpers
Date: Wed, 21 Jul 1993 14:25:01 -0500
On Wed, 21 Jul 1993, Dave Sherohman wrote:

> I don't see the two working together - either all MPCPs (or at least those
> with the same producer) have the same routines in the same locations (in
> which case you end up with Stripped code being portable) or else every MPCP
> has a unique list of what routines can be found where, in which case the
> Strip program has to know that list (ie be MPCP-specific), in which case it
> would have to compare every sequence of instructions in the MPCP with every
> sequence of instructions in the program in order to find the redundant
> sequences. (Which would allow for a portable Strip, but it would take
> forever and a day to run...)

is STRIP, as written here, anything more that a GREP/DIFF/COMPARE tryp of
thing? I'd think specific location would be irrelevant, just 'Does
function exist in the MCP/do redundant functions exist in the program'.

{[> Robert A. Hayden ____ hayden@*******.mankato.msus.edu <]}
{[> \ /__ hayden@****.cs.mankato.msus.edu <]}
{[> \/ / aq650@****.INS.CWRU.Edu <]}
{[> #include <std_disclaimer.h> \/ <]}
-=-=-
GEEK CODE v1.0.1: GSS d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++
n-(---) h+(*) f+ g+ w++ t++ r++ y+(*)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Random Thought:

Finagle's Law: The perversity of the universe tends toward a maximum.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Message no. 9
From: Dave Sherohman <esper@*****.IMA.UMN.EDU>
Subject: Re: STRIPpers
Date: Wed, 21 Jul 1993 15:02:19 -0500
>is STRIP, as written here, anything more that a GREP/DIFF/COMPARE tryp of
>thing? I'd think specific location would be irrelevant, just 'Does
>function exist in the MCP/do redundant functions exist in the program'.

Why do you think specific location is irrelevant? Strip couldn't tell a
program to use an MPCP routine unless it knew where to find that routine.
The most efficient way to handle this would be to use an MPCP-specific
Strip program with a list of 'the MPCP contains a procedure to do this
and it begins at this address' info. The Grep/etc. version would be
portable because it would use a brute-force search through the MPCP to
find what's there (and maybe be able to make enough sense of it to
determine what it does), but either way in order to _use_ an MPCP
function, the program has to be able to _find_ it.

esper@***.umn.edu
Message no. 10
From: "Robert A. Hayden" <hayden@*******.MANKATO.MSUS.EDU>
Subject: Re: STRIPpers
Date: Wed, 21 Jul 1993 16:19:14 -0500
On Wed, 21 Jul 1993, Dave Sherohman wrote:

> Why do you think specific location is irrelevant? Strip couldn't tell a
> program to use an MPCP routine unless it knew where to find that routine.
> The most efficient way to handle this would be to use an MPCP-specific
> Strip program with a list of 'the MPCP contains a procedure to do this
> and it begins at this address' info. The Grep/etc. version would be
> portable because it would use a brute-force search through the MPCP to
> find what's there (and maybe be able to make enough sense of it to
> determine what it does), but either way in order to _use_ an MPCP
> function, the program has to be able to _find_ it.

Hmm, as I've said before, I think we are getting a little to specific
about this.

How about this:

PROGRAM STRIP
SIZE ((Rating^2)x10)Mp
COST: Haven't the Foggiest.


What this accomplishes from a Game Balance{tm} standpoint is that the
program is HUGE. A rating 10 STRIP is 1000Mp!

This is the 'portable' version of STRIP. To make a specific version of
STRIP, just STRIP it. A rating 10 STRIP then becomes 500Mp.

Thoughts?

{[> Robert A. Hayden ____ hayden@*******.mankato.msus.edu <]}
{[> \ /__ hayden@****.cs.mankato.msus.edu <]}
{[> \/ / aq650@****.INS.CWRU.Edu <]}
{[> #include <std_disclaimer.h> \/ <]}
-=-=-
GEEK CODE v1.0.1: GSS d- -p+(---) c++(++++) l++ u++ e+/* m++(*)@ s-/++
n-(---) h+(*) f+ g+ w++ t++ r++ y+(*)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Random Thought:

"You need tender loving care once a week - so that I can slap you into shape."
-- Ellyn Mustard
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Message no. 11
From: Todd Montgomery <tmont@****.WVU.EDU>
Subject: Re: STRIPpers
Date: Wed, 21 Jul 1993 17:53:13 -0400
> From: Dave Sherohman <esper@*****.IMA.UMN.EDU>
> And from TMont...
>
> >Also, lets talk about real SE (Software Engineering) languages. C/C++, Ada,
> >and a smitch of MODULA-2. I have yet to meet anyone who does SE with Pascal.
>
> Irrelevant. Show me a reason to believe that anyone will be doing SE with
> _any_ existing language 60 years from now. The point is that if a Pascal
> compiler can look at eack block of code and 'decide' not to include it in
> the final file if it can't be called, then it seems reasonable to assume
> that the compilers of the future will be capable of doing so also. (That's
> one thing I've never understood about C... Why the compiler grabs the
> whole stinkin' library and drops it into the output file when only one of
> the library's functions is ever going to be used by that program...)
>

A Pascal compiler DOES NOT look at each block and do what you said.
I Pascal compiler calls on inherrant functions to do the I/O routines/etc.
that are needed to work. It is platform/OS specific. The compiler is
installed on a platform running a specific OS then it knows what to
include in the executable. It is not easy to determine what needs to be
called and what does not need to be called. I do not know if any compiler
does exactly what you are saying. I am pretty sure Pascal does not. If
you can show me what compiler does I will agree. Until then I am going to
rely on my personal knowledge. On the subject of Irrelevancy:
What in the world do we do. Make up some hypothetical
language and make up hypothetical compilers WITHOUT
any realistic basis?

-- Quiktek
-- Todd Montgomery
tmont@****.wvu.edu
tmont@***.wvu.edu
un032507@*******.wvnet.edu

Further Reading

If you enjoyed reading about STRIPpers, you may also be interested in:

Disclaimer

These messages were posted a long time ago on a mailing list far, far away. The copyright to their contents probably lies with the original authors of the individual messages, but since they were published in an electronic forum that anyone could subscribe to, and the logs were available to subscribers and most likely non-subscribers as well, it's felt that re-publishing them here is a kind of public service.