At 9:02 AM -0500 8/22/02, Dennis Handly <[log in to unmask]> wrote:

>  F. Alfredo Rego ([log in to unmask]) wrote:
>: Here is one function from that source file, for your edification:
>: static int replace_page ...
>:      { char buf[PAGE_SIZE] ;
>:          if ( !(seek_ok = *((int*)buf) ...
>
>This isn't valid because there is no guarantee that buf is int aligned.
>Better to use int buf[PAGE_SIZE/sizeof(int)];
>(And round up if you don't think PAGE_SIZE is a power of two. :-)

Hey, tell the SAPDB folks...  This is, most definitely, NOT
my code.  I am just the innocent messenger :-)

And this is just ONE tiny example out of thousands (if not
millions) of code.  In all fairness, SAPDB's source code is very
nice, when compared to some other code I have had the (mis)fortune
to (attempt to) understand.  I just have an instinctive reaction
to "balance things out" when some people say that MPE-Image are
totally washed out "legacy" things and that the future belongs to
"whatever".  I enjoy taking "whatever" under the microscope :-)


>: I know that memory was
>: a super-valuable resource in the old days of legacy systems.  Nowadays,
>: saving a few words of memory AND paying for the "saving" by recycling
>: the same variable for totally different purposes is not necessary.
>
>Not true in all cases.  If you have threads, you don't want to blow the
>trivially small thread stack of 64Kb on HP-UX if you have recursion.

I agree.  I was just being facetious regarding "the old days of
legacy systems" (i.e., our brave new world is also full of economic
constraints).

In actuality, *the* economic problem is always there.  As I wrote to
a good friend yesterday:

    It is simply a matter of economics (and I define economics as
    "the art & science of facing unlimited desires with limited
    resources").

I am glad you came up with such an excellent example, Dennis:

    If you have threads, you don't want to blow the trivially small
    thread stack of 64Kb on HP-UX if you have recursion.

You brought back fond memories (and almost tears).  In the very early
1970s, I developed all kinds of "commercial" systems software (sort,
merge, i/o libraries, file-management, you-name-it) under RTE (which
was supposed to be used only for "scientific computing").  I had a
32Kb space.  That was HALF of HP-UX's "trivially small tread stack".
No wonder I learned, early in life, to be frugal :-)


>(Currently the compiler flattens all of the locals.)
>And having 1000 4 byte ints/pointers quickly grew when inlining was used.

The old tradeoff between space and speed.  What is the limiting factor
for HP-UX's thread stack?  Is the limit imposed by software (some
hardwired constant somewhere) or by hardware (for instance, cost of
the particular kind of memory used for the stack)?  Or some combination?


>: why not choose a neutral name that applies to ALL the file operations?
>
>Yes.

Good.  I am glad you and I see eye-to-eye on this.  All the other
topics are issues of economics and one can deal with them by making
choices (guided/constrained by standard engineering tradeoffs).  There
is no excuse for using (totally unnecessarily) a misleading specific
name for a generic purpose.

   _______________
  |               |
  |               |
  |            r  |  Alfredo                     [log in to unmask]
  |          e    |                           http://www.adager.com
  |        g      |  F. Alfredo Rego
  |      a        |  Manager, R & D Labs
  |    d          |  Adager Corporation
  |  A            |  Sun Valley, Idaho 83353-3000            U.S.A.
  |               |
  |_______________|

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *