SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Fri, 15 Apr 2005 07:24:59 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: Progress--Step 3

Content Type: text/plain

"So because LEX and YACC output a C intermediate, the
untimate compiler can only process C constructs? I guess that
the g77 and g95 parts of GCC are figments of my
imagination-even though they manage to compile my old
dusty deck FORTRAN programs. I guess that I must also
assume that the Ada and the Java front ends to GCC are also
incapable of compiling real Ada and Java code."

Greg,

Does an apple look like an orange to you? LEX & YACC, the
original subjects raised, produce output that goes to a C
compiler. That implies that the "compiled" source is C even if
the "inputed" language is not. What happens if the inputed
language allows expressions, builtin functions, and data types
not "native" to C?

Take, for example, the UNSPEC and SUBTR string builtin
functions of PL/I. UNSPEC on the right-hand side of an
assignment statement converts a character to a bit string.
Used on the left-hand side (as a pseudo-variable) it converts
a bit string to a character. SUBSTR allows bit and character
manipulation of bit and character strings respectively.

If you don't have bit strings as a native data type in a
compiled language, how do you convert a character to a bit
string and vice versa? How do you do a "shift left", a "shift
right", a "rotate left", or "rotate right" of a bit string and then
put the result back into a character?

"Do we have here an argument that to write a compiler for
some language X you must use a superset of language X for
the compiler?"

No. But to use the language by itself it must at least equal
the inputed language. You cannot have a superset on input
and not use something other than the compiled language on
output, e.g. an assembly language library module.

"Are the compiler writers incapable of writing a DLL to carry
out the operations on this DATA STRUCTURE that has been
defined for the data type "blat"?"

No. The DLL has to be written in something. If it is other than
the compiled language, then you've answered your own set of
questions.

I can't speak to the g77 and g95 parts of GCC or to the JAVA
and ADA front ends. I've not done a detailed examination on
them. I did sign on to engage in a SourceForge project to
write a PL/I front end to the Version 4 GCC compiler. I signed
on wondering how it could work due to the issues you raised
here. So far "dormant" is an understatement of the progress
achieved thus far. If your dusty FORTRAN is FORTRAN IV, then
I have no doubt that it has a C equivalent. That's why PL/I
started out as FORTRAN VI originally.

I believe that you can use C and assembly language library
modules to achieve what you can do in PL/I. In the same way
you can use PL/I to achieve anything you can do with C and
assembly language. That's basically why in using PL/I I have
never had to resort to supplementing it with an assembly
language routine in now nearly 40 years of use. The only
exception occurred early on with the so-called "Sears"
routines to overcome some of the early performance issues of
PL/I's "interpretive" nature. That only lasted for a few
months before the necessary changes occurred within the
compiler.

I don't want this to come down to a "I said, you said" standoff.
As I stated earlier I haven't examined in detail the
implementations you mentioned. I would suggest that we
resolve this by exiting the realm of opinion to one of fact. We
can do the same for LEX & YACC. Therein we would all have
a clearer understanding of the situation.

While we progress slower than we might like in the PSIG
discussions such as this help us in setting a direction and
maintaining a focus. We have questions. We need answers.

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

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
"postmaster@scoug.com".

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

Return to [ 15 | April | 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.