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 >
Text File  |  1991-06-20  |  4KB  |  70 lines
  1. CSTAR.DOC:  How PL/68K became CSTAR
  2.  
  3. June 25, 1991
  4.  
  5. This documentation explains the evolution of the PL/68K language into the 
  6. CSTAR language and the strong and weak points of CSTAR and PL/68K.  
  7. CSTAR is an outgrowth of the PL/68K language described in an article in 
  8. the January, 1986 issue of Dr. DobbUs Journal.  (See the file PL/68K.DOC 
  9. for a revision of this article.) 
  10.  
  11. The original PL/68K language contained numerous syntactic restrictions 
  12. which seemed necessary to guarantee a close correspondence between 
  13. source code and the resulting object code.  Shortly after the article in Dr. 
  14. Dobb's Journal was published, I discovered that these restrictions were not 
  15. required if one were willing to pre-allocate one or two address and data 
  16. registers for use as temporary registers. This was the beginning of a process 
  17. of significant change to both the language and the compiler.  The resulting 
  18. language is a superset of the C language, rather than a restricted subset of 
  19. C.  To mark the great changes made to PL/68K,  I have given it a new 
  20. name--CSTAR.
  21.  
  22. The CSTAR language retains the essential features of the PL/68K language, 
  23. namely reserved words which stand for registers, machine instructions and 
  24. condition codes.  Thus, it is possible to write code which has C syntax but 
  25. which is translated directly into machine language.
  26.  
  27. The new language has its own quirks.  As I worked more and more on the 
  28. code generators I became convinced that it was difficult and ultimately 
  29. undesirable to give a rigid explanation of how expressions should be 
  30. translated into machine language.  Thus, the strict correspondence between 
  31. CSTAR expressions and resulting output has been partially abandoned.  The 
  32. 'simple' correspondence between source code and object code that I tried so 
  33. hard to achieve in PL/68K has been replaced by more traditional code 
  34. generators which produce extremely good code, but code which may not 
  35. always be what one naively expects.
  36.  
  37. I grossly underestimated how difficult it would be to come up with a set of 
  38. rules which describe how a competent assembly language programmer 
  39. would translated even relatively simple C language constructs into assembly 
  40. language.  Just because a translation might seem Rsimple and obviousS to a 
  41. programmer does not mean that describing the exact rules used to do the 
  42. translation is simple.  Indeed, the more I tried to tie down the exact 
  43. correspondence between PL/68K and the resulting assembly language, the 
  44. more complex and confusing the rules became.  After a while I despaired of 
  45. ever coming up with an easy to understand set of correspondence rules.  
  46. (Obviously, the code generation code in the compiler defines a set of 
  47. correspondence rules, but these rules are far from simple and easy to 
  48. understand.)
  49.  
  50. A second factor in moving from PL/68K to CSTAR is the fact that PL/68K 
  51. required the programmer to specify all the gory details of assembly language 
  52. even when there was no need to do so.  Why should you have to specify 
  53. that a result is to be held in the D6 register when any other D-register would 
  54. do as well?  This need to over specify unimportant details is one of the most 
  55. irritating aspects of assembly language, and PL/68K suffered the very same 
  56. drawback.  It turned out to be easier for the compiler to handle these details 
  57. rather than forcing the programmer specify everything.  CSTAR does, 
  58. however, allow you to specify exact registers and machine instructions 
  59. when you need to do so.
  60.  
  61. There is no question that writing a CSTAR program is easier than writing a 
  62. PL/68K program--CSTAR is just C with some additions.  Alas, this new 
  63. simplicity of CSTAR can be a drawback to producing very efficient 
  64. code--one is continually seduced by the nice syntax into ignoring details 
  65. which may impair efficiency.  Thus, CSTAR represents a different kind of 
  66. design compromise than the original PL/68K language;  although virtually 
  67. any assembly language program may be coded in the CSTAR language, the 
  68. CSTAR compiler no longer forces you to write in "assembly language 
  69. style."  Is that good or bad?  Yes it is, depending on your purpose.
  70.