SCOUG-Programming Mailing List Archives

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

Date:	Thu, 7 Aug 2003 08:14:20 PDT7
From:	Tom Novelli <tcn@mtdata.com >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Re: Warpstock 2003 Presentation

Content Type: text/plain

On Wed, 6 Aug 2003, Lynn H. Maxson wrote:

> I have similar concerns about when a discussion turns into a
> debate and from there into an argument. People differ when
> those transition points occur. I would hope that we find this
> forum a discussion of the first level without the need to raise
> to either of the other two.

Yeah. I refuse to get into an argument :)

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

Right. No point in using assembly language unless there's some trick you
can do that the compiler can't. There's a proliferation of 100% assembler
kernels and programs now, mostly written by teenagers.. for example,
Asmutils-0.16 'grep' is about 100 times slower than GNU grep! I managed
to write a (highly simplified) grep in assembly, which matched GNU grep's
performance but didn't exceed it. These kids need to learn another
language.. and some decent algorithms :)

> >From the register we can "add", "substract", "divide",
> "multply", "and", "or", "exclusive or", "nand", "compare",
> "shift left/right", "rotate left/right", or "test under mask".
> There's probably more, but I think it makes the point: you
> have two modes, arithmetic and logical.

A guy named Jack Crenshaw wrote a series of introductory tutorials on
compilers & interpreters. He made a distinction between 'bitwise' and
'relational' logical operations ('&' vs. '&&' in C) and pointed out that
(on a two's compliment machine) these become identical if you let TRUE=-1
and FALSE=0. Thus you reduce the number of operators and precedence
levels which can confuse a programmer, without resorting to strong
typing.. it may be necessary to use more parenthesis, but that improves
readability. Anyway, it's just a thought - I haven't seen or written a
compiler like this yet.

I wonder... now that the world seems to have standardized on Von Neumann
two's-compliment machines with equally-sized data words and addresses, is
all the complexity of the 1960's languages still necessary? Even C seems
like overkill. Portability isn't always worth the trouble. If some
radically different machine hits the market in 10 years, that seems like a
good time to rewrite code.

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

Then I'd say C is an MLL - Mid-Level Language; it doesn't go out of its
way to cater to humans, but expects people and machine to meet in the
middle. It provides some portability between processors, reduces typing;
the fact that it's more readable than assembly may be just a side-effect.
I wasn't even born at the time, but I understand that C was created for
programming the Unix kernel on the second or third iteration, because Unix
was being implemented on a few different PDP-series machines and Assembly
was becoming tedious to maintain. I'm also aware that Ken Thompson worked
on the PL/I-based Multics OS project, and when that went down the tubes he
lowered his sights and designed this crude but effective OS all by himself
and named it Unix in mockery of Multics. By the way, that TUNES project
seems to be following in Multics' footsteps, thinking everything would
have worked out if only they'd had computers 1,000,000 times faster...
well, now we have them we still can't maintain code on that level of
complexity.

I think there's a place for an MLL and LLL - e.g. kernels, drivers,
libraries, graphics, compilers, embedded systems; systems programming in
general. That's the kind of programming I'm doing now. Someday I'll have
to look at PL/I and APL and its derivatives.. there's a place for a good
HLL. There's also room for plenty of special-purpose languages, formats,
protocols... call it metaprogramming or whatever.

Using one language for all levels, we'd end up with a syntax that defies
the principle of least effort.. e.g. "(and (reg 'eax) (address 0x400042))"
vs. "and eax, [0x400042]" vs. "& *0x400042". There are only so many
symbols on the keyboard, and while you could add more, it'd take too long
to hunt for them. IMHO.

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

You weren't doing realtime graphics, were you? I've done some business
programming myself... for example, we had a rather naive mil-std-1388
import routine that took a few hours to load a 1-meg file, but that was
half the time it took the "top of the line" certified commercial program
and the managers thought that was great. I got it down to 30 seconds,
still using SQL and BASIC; the engineers said "now that's more like it!"
Sure, I could have done it in under a second using C and a little
assembly, but 30 seconds was fine. On the other hand, a lot more effort
must have gone into the target identification, 3D terrain display, and
fly-by-wire systems running on radiation-hardened 100-mhz processors... I
can't believe they did it all in ADA, or we'd all be Russians now :)

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

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