SCOUG-Programming Mailing List Archives

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

Date:	Wed, 6 Aug 2003 19:34:26 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:
>
> It's relatively difficult since Burroughs popularized
> the stack and RPN logic in the early sixties to find any
> compiler in any language which does not optimize the
> instruction execution of a arithmetic expression, mixed
> or not. In fact unless the assembly language programmer
> does the same translation to RPN the HLL will execute
> faster.

This is new to me. I know what Reverse Polish Notation is; I remember
creating execution stack algorithms which required the compiler to RPN a
calculation.

But I don't understand what you've said in the above paragraph.

> The point that frequently gets lost is that source has two
> communicants, people and machine, to satisfy. The principal
> drive behind HLLs in improving the readability of source by
> people. That relies on the reader's previous experience.

There's one of the flaws in current technology. Nobody is trying to
satisfy the machine.

Source should just satisfy people. Let the compiler satisfy the
machine.

The PL/I F compiler could issue "warnings". I always wished it would
also issue "notes", i.e. "you can optimize this code by moving statement
1847 so it is outside the loop". Such a "note" teaches the programmer
something to watch for; if the compiler did this optimization without
bothering the programmer then the HLL is a bit higher in level. :)

> When you look at "a = 7;" you see a necessary translation
> of 7 into binary. I don't. Blame my PL/I background, the
> IBM 1400 series, the IBM S/360/370/390 series of machines,
> but I see 7 as a decimal number. That's because even Intel
> supports fixed decimal arithmetic regardless of the limited
> architecture of the PDP machine on which K&R developed C.
>
> In PL/I I have the choice of declaring "a" either as
> dcl a fixed dec (5);
> or
> dcl a fixed bin (15);
> I can even make "a"
> dcl a fixed dec (5,2);
> or
> dcl a fixed bin (15, 6);
> both decidedly "real" numbers without being "float",
> though I have either "float dec" or "float bin" as data
> types.

You'll lose your Warpstock audience if you say "PL/I". Don't say it.
Discuss all the merits but don't say PL/I. You can give credit later.
(Much later.)

Both of us have marketing experience and I know you understand my
point. Don't say "PL/I".

By the way, if you want a true decimal machine look at the IBM 7072.
Five bits per byte; three-out-of-five code yielded only 10 possible
permutations. I used a 7072 for several years (Fortran and assembler);
worked just fine. (Characters were represented by two bytes.)

> "...Maybe PL/I or APL or K would be better,
> but they're more complicated and obscure,
> and I just want to get things done. ..."
>
> Leaving aside APL and K, both you and Peter
> are wrong on this one relative to complicated
> and obscure with respect to C and PL/I.

Within your target demographic, PL/I is obscure. And the language
itself is more complicated because it has more keywords (200 or so, I
believe).

> "...The difference exists because programmers
> have intuition and compilers don't. ..."
>
> Oddly enough the software didn't write itself despite
> inane beliefs in such a possibility. Intuition resembles
> an ad hoc query: it's only ad hoc the first time.

It still has to be there. Intuition -- how are you going to put it in
your compiler?

> After that it's clerical. If it's clerical,
> i.e. repeatable, then we can translate that
> process into software.

Note that it isn't necessarily _optimized_ software, just as a human
clerk doesn't always do things in an optimal fashion.

> In truth using C you engage in brute
> force more often than you might think.

The Fortran G compiler, for example. Brute force but it sure compiled
fast. The H compiler was much slower but produced better code.

So _now_ your compiler not only has to have code intuition, but
intuition as to whether it should optimize the compilation speed or the
code. :)

> "...As for all this debate about inline vs. called
> subroutines, I think you're being idealistic... "
>
> I see it did jump up one level above a discussion.
> Subtle here is that inline is only possible if the
> compiler has access to the source, something not
> true with respect to subroutines.

Umm, I thought you were pushing Open Source . . .

> PL/I comes with "builtin" functions which does two things:
> (1) it "knows" the underlying source, and
> (2) it eliminates the need for a library, third-party or not.
> In the almost 40 years of PL/I programming I have never
> had need in terms of either performance or function to
> revert to assembly language.

That's because you've never written a PL/I device driver!

- 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.