rap@hare.cdc.com (Rob Peters) (06/05/91)
I have a company that wishes to convert their compiler to MIPs hardware. The product is mostly coded in C, except for the Code Generator which is in assembly code (they do native implementations). They are now converting 80386 assembly routines to 4000 assembly code. I suggested that maybe they could use the MIPs Code Generator, assuming that it is modular and is accessible by a third-party compiler writer. I have been trying to get documentation regarding this MIPs Code Generator, but have had little luck. Can anyone help me get information on this product or tool? Is there such a thing at all? Would it help in the above situation or am I out in left field? Rob Peters Control Data Corporation Internet peters@dsr.cpg.cdc.com Benchmark and Demonstration Lab Phone 612-853-7025
jeffj@sco.COM (Jeff Johnson) (06/07/91)
In article <33839@shamash.cdc.com> peters@dsr.cpg.cdc.com (Rob Peters) writes: >I have a company that wishes to convert their compiler to MIPs hardware. >The product is mostly coded in C, except for the Code Generator which is >in assembly code (they do native implementations). They are now converting >80386 assembly routines to 4000 assembly code. I suggested that maybe they >could use the MIPs Code Generator, assuming that it is modular and is >accessible by a third-party compiler writer. > >I have been trying to get documentation regarding this MIPs Code Generator, >but have had little luck. Can anyone help me get information on this >product or tool? Is there such a thing at all? Would it help in the above >situation or am I out in left field? I don't believe the MIPS back end is availiable as a product or a public interface, but what do I know? Ask MIPS. I just wanted to suggest a possible alternative approach. You might consider converting the 386 assembler to C. Then you will be using the MIPS back end to generate your own :-). But seriously, in RISC philosophy the compiler should be about as smart about generating code as you are. Others may have some more informed opinions about that. What had to be in assembler an a 386 may not need to be on an R4000, unless there is a religious belief about bootstrapping the compiler from an assembler. You'll probably get acceptable performance from C, and you'll be really glad when you port it to the next processor. Just an idle thought to ruminate on. Jeff Johnson, The Santa Cruz Operation, Inc. (A division of your company) email: jeffj@sco.com, uunet!sco!jeffj Voice: 408-458-1422, FAX: 408-458-0811
murphy@mips.com (Mike Murphy) (06/08/91)
>In article <33839@shamash.cdc.com> peters@dsr.cpg.cdc.com (Rob Peters) writes: >I have a company that wishes to convert their compiler to MIPs hardware. >The product is mostly coded in C, except for the Code Generator which is >in assembly code (they do native implementations). They are now converting >80386 assembly routines to 4000 assembly code. I suggested that maybe they >could use the MIPs Code Generator, assuming that it is modular and is >accessible by a third-party compiler writer. > >I have been trying to get documentation regarding this MIPs Code Generator, >but have had little luck. Can anyone help me get information on this >product or tool? Is there such a thing at all? Would it help in the above >situation or am I out in left field? Since no one else has spoken up, I'll throw in my two cents: This is possible, and in fact has been done by other companies; however, it may not be particularly easy, depending on how the other compiler is structured. Our code generator takes ucode as its input, so the main work is in writing a translation phase that converts whatever old intermediate language they were using into ucode. One of the main advantages of doing this is that you will get to take advantage of our global optimizer, which also operates on ucode. To do all of this they would need to get a source license to our compiler, and they would only be allowed to use this for MIPS-based targets. --mike
grunwald@foobar.colorado.edu (Dirk Grunwald) (06/11/91)
The other alternative is to tell them to target their compiler to generate 'C' output. This way, they can use e.g., the MIPS code generator or the new DEC RISC C compiler as well. Obviously, it will be slower, but they can probably ignore most of the optimization issues entirely, passing those onto the backend. They'd still have to do non-C-ish things themselves, like inter-procedural optimization. I use several `compilers' (Scheme->C, Fortran->C, Pascal->C, Modula3->C) that do this, and they're generally easier to retarget and not really all that much slower (since the front-end can ignore optimization, which is the slow part). Not to mention that your customers time-to-market would be cut a lot, it doesn't involve any licenses and you can target a broader market quicker. Dirk Grunwald -- Univ. of Colorado at Boulder (grunwald@foobar.colorado.edu) (grunwald@cs.colorado.edu)
paul@u02.svl.cdc.com (Paul Kohlmiller) (06/11/91)
murphy@mips.com (Mike Murphy) writes: >>In article <33839@shamash.cdc.com> peters@dsr.cpg.cdc.com (Rob Peters) writes: >>I have a company that wishes to convert their compiler to MIPs hardware. >>The product is mostly coded in C, except for the Code Generator which is >>in assembly code (they do native implementations). They are now converting >>80386 assembly routines to 4000 assembly code. I suggested that maybe they >>could use the MIPs Code Generator, assuming that it is modular and is >>accessible by a third-party compiler writer. >> Here's another idea ... The problem in moving a compiler to a new code generator is that the compiler will be generating some kind of intermediate language and the code generator accepts a different intermediate language. Word has it that OSF will be promoting a "universal" intermediate language called ANDF. Imagine the following: your customer wants to move a compiler to the MIPS hardware. They need a ANDF converter that takes their code (object code, assembler code, intermediate code, whatever) and generates ANDF code. Then someone else creates an ANDF translator for MIPS (let's say EP/IX) that takes ANDF and produces C code. You now have a cross-compiler. If you move the customers compiler (that eventually creates ANDF code) to EP/IX, you have now moved the compiler to EP/IX (at some cost in compilation time). The only thing missing is the two converters. Producing an ANDF to C translator for EP/IX should be a piece of cake (hope we can find someone to do it). The 386 to ANDF converter may already be done (you would have to check with OSF). Good Luck. Paul Kohlmiller -- // Paul H. Kohlmiller // "Cybers, Macs and Mips" // // Control Data Corporation // Internet: paul@robin.svl.cdc.com // // All comments are strictly // America Online: Paul CDC // // my own. // Compuserve: 71170,2064 //