SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Wed, 6 Aug 2003 15:28:59 PDT7
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Re: Warpstock 2003 Presentation

Content Type: text/plain

Lynn H. Maxson wrote:
>
> Wow, Greg, Steven, and Peter, had I known what
> could pique your interest, I would have brought
> it up sooner. You have no idea of just how
> much I appreciate the feedback.

Lynn,

The Subject title of this thread is the target. What I've been doing is
helping you codify your thoughts by giving them a good poke in
vulnerable places. I want your Warpstock presentation to be as solid as
you can make it.

> For the record the PL/I "value block to which Peter
> refers Hursley Labs denoted as a "dope vector",
> because it contained the "dope" on the variable.

This is part of what impressed me so much about PL/I. You could pass
this "dope vector" to a generic subroutine and not worry about whether
it contained a 16-bit unsigned integer or a 15-bit signed integer -- the
routine could check and find out.

> It was a programmer blessing, but a performance nightmare.

Yup. Ask Kodak. :)))

> As a result until it was corrected when the F-level compiler
> became the optimizing compiler IBM Hursley wrote a series of
> subroutine calls known as the "Sears routines" to offer
> performance more in line with that COBOL. In effect PL/I
> executed at interpretive, not compiled speeds in arithmetic
> expressions prior to the F-level optimizing compiler.

I didn't know this, thanks for the history. F was the first I used.

> As we agree on the existence of dope vector, a different
> scheme in PASCAL, and yet another aspect of object-oriented
> programming (programmer-defined class), I can't be accused
> of making these things up. Just add to that list how
> logic programming, AI and Prolog in particular, in a
> similar manner processes rules.

The semantics (the words) used by different language designers and
implementers is a long-time problem and one you should probably
address. A "dope vector" is a description table, nothing more. At
least it's concrete; I've never fully understood the unorthodox typing
of Pascal sets (though I haven't really tried).

Designers and implementers should stop showering us with new descriptive
terms and just say what they're doing. If it's a description table, say
"description table". Dope vector, sheesh, note that I remembered what
it was but sure didn't remember what they called it (thus giving value
to the idea but a fat zero to the name).

> So why not accept the role of a dope vector into which you
> can encode all the rules governing the characteristics and
> behavior of a data variable and its inter-dependencies with
> other data variables?

Why not, indeed? The dope vector was a field-oriented description table
(i.e. go to the xth bit in the yth field and you could find out if the
number was signed or not) but could just as easily have been the
character string of the original type declaration (DCL). The latter is
a *lot* slower to execute since it must be parsed each time the value is
used but the concept is the same. Implementers might want to opt for a
dope vector which includes a pointer to "unusual" elements in the DCL,
for example the named elements of a vector ("dog", "cat", "bird",
"fish").

For an example, the classic code is

Pets[1] = "dog"
Pets[2] = "cat"
Pets[3] = "bird"
Pets[4] = "fish"
PetsCount = 4

and the execution code must look up any supplied input string to see if
there's a match between indexes 1 through 4.

But you should be allowed to say Pets["bird"] and various extensions
such as Zoo[Pets[^bird]] where the Zoo[] vector contains the number of
animals of each kind.

The above example is simple and silly, but when you start to get into
finance and want to keep track of GDP, PerCapitaGDP, DOW, AMEX, Nikkei,
JoblessReport, ConsumerPriceIndex, ProducerPrices and a zillion other
functions there are some good reasons to use named indexes.

> For any given functional code once optimized for speed and
> space why will that not transfer to the code generation
> phase of an HLL implementation? Obviously it can. If you
> do it often enough, eventually you will have exhausted the
> assembly language programmer into submission.

An assembly coder optimizes a particular algorithm. There are zillions
of algorithms. In order for an HLL compiler to optimize that code
you'll have to either a) teach it every single algorithm (i.e. write
everything in assembler anyway and then stick the results into the
compiler in case somebody wants to write the algorithm again some day)
or b) come up with some new compiler optimization techniques.

You haven't discussed implementable compiler optimization techniques.

> It gets a bit more difficult in terms of a complex
> righthand side expression as in
> a = sqrt(b) - arctan(c);
> Here you may want to execute either or both inline or as
> subroutines. Would having "inline" immediately following
> the function expression suffice:
> a = sqrt(b) inline - arctan(c);

Better to optimize the algorithm, Lynn. A mathematician may be able to
reduce the particular expansion sqrt()-arctan() to a simpler
calculation.

Here's a stupid example:

(sin x)^2 + (cos x)^2

The above is optimizable to something much simpler. Should the compiler
be taught to find such things?

> I guess I am too use to PL/I's emphasis on placing the
> programmer's priorities over that of the implementer's.
> It's the job of the implementer to do what the programmer
> wants, not to impose restrictions. It certainly makes
> implementing PL/I compilers a lot harder than the others,
> but it does make the programmer's life easier.

As I recall, the original Level F compiler used 47 passes.

> I don't want the HLL to do any more than it is told to do
> by the programmer except in the most efficient way. If
> the programmer has indicated a function reference, it
> should occur as a subroutine...unless the programmer
> indicates otherwise.

This should be included as part of the strategic direction for your
presentation.

> The goal remains to produce the most efficient code in
> terms of speed and space with the least "programmer"
> effort. I say "programmer" instead of "programming" to
> indicate that I expect the software to do more of the
> programming under the direction of the programmer.

I keep getting a discomforting perception -- that you are intermingling
code generation efficiency with HLL design.

May I suggest an alternative, perhaps more successful, way to approach
this R&D project? _Separately_ develop the desired compiler
optimization techniques and only look for HLL design philosophies in the
results. And, _separately_ develop your HLL design philosophy without
any regard to code optimization.

Then see if they overlap. This isn't a double-blind development yet but
your current direction isn't even single-blind; you've decided what
results you want and are selling the drug before the tests are in and
the FDA has issued an approval.

Cleave it into two beings. Code optimization. HLL development. Don't
make tradeoffs in either arena to try to justify "the other".

- Peter

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 06 | August | 2003 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.