home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The C Users' Group Library 1994 August
/
wc-cdrom-cusersgrouplibrary-1994-08.iso
/
vol_300
/
357_01
/
cstar1.exe
/
CSTAR.DOC
< prev
next >
Wrap
Text File
|
1991-06-20
|
4KB
|
70 lines
CSTAR.DOC: How PL/68K became CSTAR
June 25, 1991
This documentation explains the evolution of the PL/68K language into the
CSTAR language and the strong and weak points of CSTAR and PL/68K.
CSTAR is an outgrowth of the PL/68K language described in an article in
the January, 1986 issue of Dr. DobbUs Journal. (See the file PL/68K.DOC
for a revision of this article.)
The original PL/68K language contained numerous syntactic restrictions
which seemed necessary to guarantee a close correspondence between
source code and the resulting object code. Shortly after the article in Dr.
Dobb's Journal was published, I discovered that these restrictions were not
required if one were willing to pre-allocate one or two address and data
registers for use as temporary registers. This was the beginning of a process
of significant change to both the language and the compiler. The resulting
language is a superset of the C language, rather than a restricted subset of
C. To mark the great changes made to PL/68K, I have given it a new
name--CSTAR.
The CSTAR language retains the essential features of the PL/68K language,
namely reserved words which stand for registers, machine instructions and
condition codes. Thus, it is possible to write code which has C syntax but
which is translated directly into machine language.
The new language has its own quirks. As I worked more and more on the
code generators I became convinced that it was difficult and ultimately
undesirable to give a rigid explanation of how expressions should be
translated into machine language. Thus, the strict correspondence between
CSTAR expressions and resulting output has been partially abandoned. The
'simple' correspondence between source code and object code that I tried so
hard to achieve in PL/68K has been replaced by more traditional code
generators which produce extremely good code, but code which may not
always be what one naively expects.
I grossly underestimated how difficult it would be to come up with a set of
rules which describe how a competent assembly language programmer
would translated even relatively simple C language constructs into assembly
language. Just because a translation might seem Rsimple and obviousS to a
programmer does not mean that describing the exact rules used to do the
translation is simple. Indeed, the more I tried to tie down the exact
correspondence between PL/68K and the resulting assembly language, the
more complex and confusing the rules became. After a while I despaired of
ever coming up with an easy to understand set of correspondence rules.
(Obviously, the code generation code in the compiler defines a set of
correspondence rules, but these rules are far from simple and easy to
understand.)
A second factor in moving from PL/68K to CSTAR is the fact that PL/68K
required the programmer to specify all the gory details of assembly language
even when there was no need to do so. Why should you have to specify
that a result is to be held in the D6 register when any other D-register would
do as well? This need to over specify unimportant details is one of the most
irritating aspects of assembly language, and PL/68K suffered the very same
drawback. It turned out to be easier for the compiler to handle these details
rather than forcing the programmer specify everything. CSTAR does,
however, allow you to specify exact registers and machine instructions
when you need to do so.
There is no question that writing a CSTAR program is easier than writing a
PL/68K program--CSTAR is just C with some additions. Alas, this new
simplicity of CSTAR can be a drawback to producing very efficient
code--one is continually seduced by the nice syntax into ignoring details
which may impair efficiency. Thus, CSTAR represents a different kind of
design compromise than the original PL/68K language; although virtually
any assembly language program may be coded in the CSTAR language, the
CSTAR compiler no longer forces you to write in "assembly language
style." Is that good or bad? Yes it is, depending on your purpose.