Internal Memo XEROX To From Mimosa interest Russell Atkinson PARC/CSL Subject Date Mimosa overview October 8, 1987 Introduction Mimosa is a CSL project to build a retargetable Cedar/Mesa compiler. The Mimosa goal is to produce a family of compilers that translate current Cedar/Mesa programs into native object code for a variety of machines. The Cedar/Mesa language is an extension of the Mesa language used in Xerox product programs. This extension is compatible with existing Mesa programs. The extensions include automatic storage management and dynamic type discrimination. It is not our goal to guarantee that all current Cedar/Mesa programs will compile and execute without change. Only programs that avoid machine dependencies such as addressing granularity, alignment restrictions, and equivalence of certain data representations will behave the same for all of the anticipated target machines. The Mimosa project is intended to provide additional options to Xerox. Xerox would be free to develop or buy non-PrincOps processors, yet retain the advantages of Cedar/Mesa. It would also be possible to mix code written in Cedar/Mesa with code written in other languages (for example, C). Customers Initial CSL needs Mimosa in order to produce code for new research machines. For CSL's purposes, the Mesa programs accepted by Mimosa include those using the Cedar extensions used by CSL. Supporting the Cedar extensions has no adverse impact on Mesa users. DSBU needs Mimosa to translate Mesa programs to run on commercial microprocessors. DSBU contributes funding for the Mimosa project, as well as loaning two staff members. Potential Potential customers in Xerox include all organizations that use Cedar/Mesa and would like to use Cedar/Mesa on non-Xerox computers. For example, we have received substantial interest in Mimosa from RBG for use in future reprographic products. Use of Mimosa could extend to external customers. In particular, Xerox could consider selling Cedar/Mesa programs to be run on non-Xerox machines. Targets Initial The primary initial target is the C programming language. The intention is not to produce one-time transfer of Cedar/Mesa code to C, but rather to use C as an abstract assembly language that will allow Cedar/Mesa code to run on a large variety of machines. We have also nearly completed work on a "native" target compiler that directly generates machine code for the Dragon instruction set. It is unlikely, however, that CSL will proceed with the Dragon instruction set, so this version of the compiler only has value as a starting point for future native compilers. Potential Potential targets include other native instruction sets, intermediate codes, and other (sufficiently expressive) high level languages. Details Components The front end of the compiler translates from the Cedar/Mesa language to Mimosa intermediate code. The front end performs parsing, type checking, and intermediate code generation. The front end is essentially complete except for some minor additions necessary for the C language target. The "Cedar-to-C" code generator translates from the Mimosa intermediate code to the C language. It primarily treats the C language as an assembly language. The C code generated will be specific to a particular class of machines. Word size, addressing granularity, byte order, and alignment constraints affect the C code produced. The C runtime support for the Cedar/Mesa language provides support for Mesa features such as signals, processes, dynamic loading, monitors, module initialization and start traps. It also provides support for Cedar features such as collectible storage and runtime types. Staff Russell Atkinson (CSL) has been working on the front end of the Mimosa compiler since mid-1985. Jim Foote (DSBU) will be working on the front end additions and the C language target. Jim arrived in September 1987. Christian Jacobi (CSL) has been working on the C language target since May 1987. Peter Kessler (CSL) has been working on the Dragon native target since mid-1985. Andy Litman (DSBU) has been working on the C runtime support for the Cedar/Mesa language since late July 1987. Mark Weiser (CSL) has been working on the C runtime support for the Cedar/Mesa language since June 1987. Questions and Answers Can Mimosa be used for "one-time" translation to C? As currently designed, Mimosa is not suitable for direct source to source translation, since the C output is not inteneded to be readable or maintainable by programmers. The technical problems of translating between the languages at the source level are not simple ones, whereas we believe that we have solutions for these problems when treating C as an assembly language. Even if such translation were feasible, there is reason to believe that it is not a good idea. The opinion of many programmers is that use of the Mesa language results in programs that are easier to maintain. This derives from the principled use of interfaces and better type checking for a richer type system. Most programmers familiar with the additional Cedar features would add that Cedar programs are easier to write and maintain due to the automatic storage management in the Cedar language. What is the "runtime support" for the C target? The Mesa language requires support for signals, processes, and monitors. This support will be furnished by a small set of Unix-based utilities developed as part of the Mimosa project. The Cedar features of collectible storage and runtime types require runtime support. Again, this support will be furnished by a small set of Unix-based utilities provided by the Mimosa project. Although not required by Cedar/Mesa, runtime loading and linking is also supported by another set of Unix-based utilities provided by the Mimosa project. This support includes a replacement for the Binder, so current configurations will continue to be supported. What about debugging support for the C target? The Mimosa project does not include debugging support, although we are investigating various possibilities for adding that support. The policy that we have adopted is to obtain leverage by using the debugging support of the target machine. In the Mimosa runtime development for the Sun-3 and Sun-4 processors a stopgap debugging approach based on the dbx debugger is being used. Some modifications are planned to assist source language debugging, although the result will not be as complete as the Sword debugger for XDE or the Cedar debugger. What about efficiency? The code resulting from the two levels of translation may be slightly less efficient than that produced by one level of translation. However, we believe that this difference is more than compensated for by the use of faster processors, more portability, and the use of optimizing C compilers. The primitives of Mesa (procedure call, data structure access, arithmetic, loops, and conditionals) have essentially identical cost for the equivalent C constructs. Since the cost of the primitives and the cost of composing the primitives are nearly identical for the two languages, we do not expect serious performance changes in either direction. When? We expect that a preliminary version of the compiler and runtime support will be available by 1 Q 88 (portions are already working) for intrepid users only. This version will require the use of the Cedar environment for the compiler, although we plan to make the compiler available as a network service for XDE users. We plan to offer the compiler and runtime for serious development in 2 Q 88, with bug fixes and enhancements occuring throughout 1988. We further plan to port the compiler to a Unix-based environment late in 1988.  NewlineDelimiter (cedardoc) styleStyleDefBeginStyle (Cedar) AttachStyle (firstHeadersAfterPage) {0} .cvx .def (root) "format for root nodes" { FontPrefix docStandard 36 pt topMargin 36 pt headerMargin .5 in footerMargin .5 in bottomMargin 1.75 in leftMargin 1.5 in rightMargin 5.25 in lineLength 24 pt topIndent 24 pt topLeading 0 leftIndent 10 pt rightIndent } StyleRule (positionInternalMemoLogo) "Xerox logo: screen" { docStandard 1 pt leading 1 pt topLeading 1 pt bottomLeading } ScreenRule (positionInternalMemoLogo) "for Xerox logo" { docStandard 1 pt leading 1 pt topLeading -28 pt bottomLeading -1.5 in leftIndent } PrintRule (internalMemoLogo) "Xerox logo: screen" { "Logo" family 18 bp size 20 pt topLeading 20 pt bottomLeading } ScreenRule (internalMemoLogo) "for Xerox logo" { "Logo" family 18 pt size 12 pt leading -28 pt topLeading 36 pt bottomLeading -1.5 in leftIndent } PrintRule (memoHead) "for the To, From, Subject nodes at front of memos" { docStandard AlternateFontFamily 240 pt tabStops } StyleRule EndStyleIblockMark insideHeaderbox IpositioninternalmemologoIinternalmemologomemoheadsNt N NNNNN NNNhead KKKK KK KKKK K KKKK_KvKPKPKnKh3KK/KKK.KKKKK6$#