SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Sun, 3 Aug 2003 01:12:16 PDT7
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
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

Tom Novelli writes:
"...I doubt if it's worth the trouble.. an HLL is mathematical
notation and a processor is a machine (sort of a nano-abacus)
with some parts that don't match up cleanly to any HLL. C
comes close (it's basically a terse and generic assembler). I
have a hunch that it'd be simpler to use a little assembly here
and there rather than some super-HLL. ..."

Peter Skye writes:
"...But "there's the rub". With a high-level language you
aren't supposed to care about the exact commands performed.
You just want the work done.

Strategy versus logistics. What's best versus what can we do
right now? ..."

While I'm still reacting to what I perceive is Steven's
condescending response to my inexperience with Intel-based
assembly language programs I welcome that people take the
time to respond, allowing this to progress beyond a
monologue.

You have facts and you have interpretations of those facts.
We have enough problems just agreeing on the facts. We
tend to get polarized when it comes to defending our
interpretations.

For example, the Intel reference manual covering the Pentium
instruction set offers three different representations of each
instruction: (1) actual machine code, (2) symbolic assemlbler
code, and (3) an HLL form. That's a fact. My interpretation
says that they are equivalent forms, meaning that a
one-to-one relationship exists, that you can substitute one for
the other. That substitution allows us to incorporate an entire
HLL form within a properly defined, more inclusive one.

That said then no advantage occurs in terms of code
generation, given pattern recognition of these "primitive"
expressions, of using and by necessity learning a "second"
language. You need no recourse to symbolic assembly
language, in-line or out-of-line (subroutine via API), from an
HLL which includes (and whose implementation recognizes)
machine instruction primitives within HLL expressions.

This allows the HLL to treat these primitive expressions as
"raw material" from which we can derive all higher level
expressions or assemblies, consisting of primitive expressions
and other higher level assemblies, This then extends the
constrained macro form of symbolic assembly to the more
flexible form of an HLL.

The raw materials form the axioms used to "prove" theorems,
i.e. higher level assemblies. This forms the basis for
manufacturing logical forms otherwise known as "software".
These axioms, the machine instruction set, represent the
common means of tying the software to the "hardware". In
fact contrary to other assertions that some difference exists
between them, none in fact does: they are two sides to the
same coin.

Machine instructions themselves are logical assemblies. In fact
given that you can emulate a CISC instruction set with a RISC
one we see that at least two levels of instruction sets exist.
Both levels, however, rely on even lower level logical
assemblies of lowest level logical primitives (and, or, not, etc.)
or raw material. Having at one time at the beginning of my
IBM career in 1956 charged with "knowing" the machine down
to the individual component and assembly levels, I can assert
that all software melds seamlessly with the hardware.

I don't regard it as sheer happenstance that APL as a
specification language containing these logical primitives as
operators can symbolic represent all logical levels from the
logical components to their assemblies into instructions and
their assemblies into all higher level software assemblies.
Iverson in his 1962 "A Programming Language" did this
symbolic hardware representation for the IBM 7080. Then in
1964 the APL group published it for the IBM/360 in an IBM
System Journal of that year.

So basically you have an HLL (APL) capable as a specification
language for any hardware architecture and any software
based upon its use. Iverson intended it as such, in fact as a
replacement for flowcharting. As we have basically had it for
use since 1962, some 40+ years, I'm disinclined to regard it as
some form of fantasy, impossible, or undesired dream.

In short the principal difference between an HLL and a
machine instruction set (and the underlying machine logic) is
that the one, HLL, includes the other as a subset.

********

Now we should lay the myth of C as some form of "terse and
generic assembler" more so than any other language has
probably never really looked at APL (referenced earlier) or
PL/I. Sheer curiosity would question why if one is so close to
the other, i.e. C to assembler, that such a difference in
execution speed, some 4 to 1 and greater, should exist.

In fact the only place that C approaches assembler lies in "int"
and its variations. This forms the battle space between the
advocates of "weak" (C) typing and "strong" (every other
HLL). More to the point C does not offer bit strings, fixed or
variable, as a native data type. Nor variable-precision,
fixed-point, decimal arithmetic. Nor non-null-terminated,
variable length character strings. Nor...and the list goes on.
All these are supported in the Intel machine instructions sets
for all its processors from the 8088 (with 8087 co-processor)
on up. All these are supported in both APL and PL/I. In PL/I
they are native data types. It's sheer crap to take a crippled
HLL like C and state that it is somehow closer than anyone
else to an underlying symbolic assembler.

*********

That gets us back to Abrash and his "Zen of Assembly
Language" and the other books I mentioned in the series. I
found Abrash valuable for his descriptive process of
determining by processor architecture optimal instruction
sequences for performance for given function. That it's not
fixed across processors within the same family, e.g. Intel, and
that discovery through deeper understanding of the
architecture relative to the instruction set is necessary gives
rise to his reference to "Zen" in the book title.

We are assured that we can through a discovery process
determine at least one instruction sequence of a function on a
given processor is optimal. He offers a relatively simple and
perhaps even obvious discovery process. However, you don't
have to discover it more than once for each processor
instance. You may use Zen to get to that point, but once
there Zen disappears and sheer repetition (clerical) appears.

As HLL users it should be obvious from the performance
differences that while we don't want to be bothered with
knowing the underlying "commands" (to quote Peter), we
would at least like to know that those who do bother with
such things have done so in the most optimal manner. Yet it
obvious from the performance differences of every HLL
implementation relative to symbolic assembler that they
haven't done so.

Further you have to ask yourself, in reference to Peter's use
of inline symbolic assembler in PASCAL source, why after
some 40+ years the performance difference not only continues
to exist but with the advent of object-oriented it has gotten
even worse?

Does anyone here seriously believe that any performance
difference for equivalent function should exist between
symbolic assembly and an HLL? If you do not, why do you
continue to accept implementations in which they do?
Unfortunately most of open source is based on C or its
derivatives. As it doesn't have the claimed "closeness" to
processor architecture why not opt for something that does?
Why should not an HLL, as a third and fourth generation
language, not incorporate directly within its linguistic form
second generation (symbolic assembly) capabilities? It's not
that it's something new or unheard of.

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

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