home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / forth / 3131 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  3.0 KB
  1. Path: sparky!uunet!pipex!demon!cix.compulink.co.uk!spelk
  2. Newsgroups: comp.lang.forth
  3. From: spelk@cix.compulink.co.uk (MPE Ltd)
  4. Subject: cross compilers
  5. Reply-To: spelk@cix.compulink.co.uk
  6. Date: Tue, 15 Sep 1992 00:04:00 +0000
  7. Message-ID: <memo.627478@cix.compulink.co.uk>
  8. Sender: usenet@gate.demon.co.uk
  9. Lines: 63
  10.  
  11.  
  12. >The first step in standardising cross compilers should be to write
  13. >a clear explanation of how a cross compiler works and publish code
  14. >that does it in an efficient manner.  We will know the code is good
  15. >when it gets copied into various new Forth systems.
  16.  
  17. >>Sorry, I have to disagree with this.  This seems to be saying that
  18. >>we should have one cross-compiler, period....which would by default
  19. >>be standard!  I'd rather see variety in cross-compiler approaches.
  20.  
  21. Then we would have to standardise their features. In practice the
  22. Forth source code to be passed through a cross compiler is
  23. standardised by the standard/dialect being used. Any deviation
  24. from this is usually recognised as a deviation or failure by
  25. both the author and the user. Most of us who develop cross
  26. compilers work hard to minimise these deviations. I will find
  27. it hard to summon any enthusiasm for standardising what are quite
  28. rightly regarded as implementation deficiencies.
  29.  
  30. It is only the control of the cross compiler that could be
  31. standardised. For example how do you define the base address of the
  32. output.
  33.    addr ROM-BASE
  34.    addr n ORG/DB
  35.    addr ROM-ORG
  36. have all been used. How are named labels defined? How are equates
  37. handled. Since I hear many statements that Forth has a major role
  38. to play in the embedded systems area, which is the domain of cross
  39. compilers for many users, surely the ANSI committee is neglecting
  40. a substantial proportion of users by choosing not to consider thes
  41. issues for the moment. Perhaps the major cross compiler vendors
  42. (MPE, LMI, Forth Inc ...) may care to prpare a joint submission?
  43. MPE would be willing to coordinate this.
  44.  
  45. The next step would be to standardise assembler syntax -
  46. assembler facilities are VERY important when cross compiling
  47. a kernel. For example, even within an 8086 assembler the following
  48. may be found between Forth implementations.
  49.    MOV AX, # 0100
  50.    MOV AX, 0100
  51.    MOV AX 0100
  52.    AX, 0100 MOV
  53.    AX, # 0100 MOV
  54.    # 0100 AX MOV
  55. Trying to standardise that many variants across twenty or thirty
  56. processors is an udesirable task.
  57.  
  58. >BTW, I think Stephen Pelc has devised a useful nomenclature
  59. >for metacompilers:
  60. >a "cross-compiler" can produce code for a different CPU.
  61. >A "recompiler" --
  62. >e.g. Pygmy -- can simply regenerate the kernel for the host CPU;
  63. >it can't produce code for a new CPU.
  64. >I think "metacompiler" is the general class.  (Please correct me if
  65. I'm
  66. >wrong, Stephen.)
  67.  
  68. Right, except that "metacompiler" is misnomer that should be avoided.
  69. A metacompiler produces a compiler for another language. Metacompiler
  70. is the general term for tools such as YACC, and Forth cross compilers
  71. do not yet perform that task. I use the term cross compiler as the
  72. general class. The term target compiler is sometimes used for cross
  73. compiler.
  74.