SCOUG-Programming Mailing List Archives

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

Date:	Sat, 1 Jan 2005 17:46:20 PST8
From:	"Gregory W. Smith" <gsmith@well.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Programming in the new year

Content Type: text/plain

On Thu, 30 Dec 2004, Lynn H. Maxson wrote:
> I mention this because over on SourceForge they have a
> project to have a PL/I pre-processor to a proposed C 4.0
> language compiler. I have my doubts because no version of C
> comes anywhere near the native data types of PL/I: no bit
> strings, no non-null terminated character strings of length
> greater than one and no variable precision real and integer,
> binary and decimal arithmetic, no variable precision fixed and
> floating point, decimal and binary values.
>
> This means that C and its current derivatives can only
> natively express a subset of that possible in PL/I. Thus you
> could write a C pre-processor to PL/I, but not the
> reverse...unless you revert to assembly language. If you
> revert to assembly language you will not have a C language,
> but a hybrid.

Can you say "red herring?" So if you can't 'natively express'
something, it can't be done at all?

Balderdash. Express what you want in terms of something else
that you can 'natively express.' This is what Peter pointed
out. The compiler generates DATA STRUCTURES for what the
language specifies as a 'native data type' and uses calls to
library routines to manipulate these 'native data types.'
At least that was back in the PL/I F compiler days--And that
is still the case.

And that is what the Gnu C/C++ compiler does today. The front
end reads the C/C++ source and generates an INTERMEDIATE code
that following passes use to generate machine code. That is
what little has managed to stick with me from a number of
presentations by the Red Hat compiler gurus that I have heard.
Of course, much of what the compiler gurus had to say went over
my head. But what I did get was that any other language front
end to the compiler will generate the same INTERMEDIATE code--
along with the data structures needed for whatever 'native
data types' that the language needs. In addition, the language
implementor needs to supply the appropriate library routines
for the language. So the Gnu Fortran Compiler, which can be
added onto Gnu C/C++, installs additional runtime libraries to
do what doesn't come free with libc, libm, etc.

To paraphrase what Peter wrote in another post, your view of
the 'problem set' is much more constrained than many of the
problems that I encounter. For example, one 'problem set'
from continuum mechanics (heat, momentum, and mass transfer)
has a 'solution set' described by scalar, vector, or tensor
fields constrained by the basic rules of calculus. And any
'solution set' generated by a digital computer will only be
an approximation. An analog computer can give me the real
'solution set' if I want. (A wind tunnel is just a giant
analog computer for solving the Navier-Stokes equations.)
But I want to use my under $1000 laptop instead of a multi-
million dollar wind tunnel. So, like Peter, I think in terms
of algorithms and systems to abstract the multi-million
dollar wind tunnel to something to run on the PC.

And when I have to consider the hardware, I get smacked by the
WEASEL WORDS in the PL/I languge specification. From the
IBM PL/I Language Specification (SC27-1460-03) we have:

--> Binary floating-point data
-->
--> The data attributes for declaring binary floating-point
--> variables are BINARY and FLOAT. For example:
-->
--> declare S binary float (16);
-->
--> S represents binary floating-point data with a precision
--> of 16 binary digits.
-->
--> The exponent cannot exceed five decimal digits. If the
--> declared precision is less than or equal to (21), short
--> floating-point form is used. If the declared precision is
--> greater than (21) and less than or equal to (53), long
--> floating-point form is used. If the declared precision is
--> greater than (53), extended floating-point form is used.

In other words, the language implementor is free to use the
machine's floating point hardware. Pad the extra bits with
zero, carry them through on all calculations and throw them
away at the end. The big deception, however, comes from the
semantic overloading of 'binary' from the English language.
The precision depends on the floating point radix. So on an
IBM 360 with a hex radix, the precision is NOT 16 binary
digits; it is really 4 hexadecimal digits. Which might be
a really nasty surprise to some scientist or engineer who
takes his code from some other machine to the 360.

Oh well, I guess it is time to trash my PC and start on the
wind tunnel in the back yard.
--
Gregory W. Smith (WD9GAY) gsmith@well.com

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

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 [ 01 | January | 2005 ]

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.