Date: Tue, 28 May 1996 11:44:18 PDT From: Matthai Philipose Folks, I was chatting with Jack a couple of days ago, and he mentioned he had a couple of things he'd really like added to the mflow compiler. Also, Fletcher and I were talking the other day about coming up with some kind of priority list of what we want him to do after he gets the 64-bit stuff done. Maybe we should discuss this stuff in our meeting next Monday. Jack, we meet in Sieg 224 at 3:30... maybe you can stop by with your ideas? Matthai ******************************************************************************** ******************************************************************************** ******************************************************************************** Date: Tue, 28 May 1996 15:16:06 -0700 From: garrett (Charles Garrett) I have another topic to add to our discussion of multiflow changes for the summer, namely the porting of Modula-3 to use a multiflow backend. I think that the port will be fairly easy, given the structure of the Modula-3 compiler from SRC, so let me lay out a proposal which we can discuss next week. The Modula-3 compiler currently works in two phases which communicate through an intermediate language file. The first phase reads Modula-3 source, performs type-checking and generates a file containing intermediate language for a stack machine. There is one intermediate language file for every Modula-3 interface or module file. The second phase consists of a modified GNU C backend which first reads the intermediate language file and transforms the stack machine language into GNU rtl instructions. Then it performs any optimizations and generates machine code for the file. When Greg DeFouw ported the Modula-3 frontend to the Vortex compiler, he changed the first phase to generate Vortex intermediate language instead of the stack machine language. I was hoping to do the same thing for multiflow, but it looks like the multiflow compiler will not read a file of intermediate language instructions. I asked Ben Cutler about this and he said, "No provision is available for emitting and then rereading IL, so you would need to add this yourself." Since that is the case, I can see three ways to proceed, each with some advantages and disadvantages. ---------------------------------------- 1. Use C as the intermediate language. Advantages This is the simplest solution, since we would not have to change the multiflow compiler at all. Intermediate C code will probably be easier to read than multiflow IL. Disadvantages Reading in the C code will increase the total compilation time. We may not be able to specify everything in C that we could in the intermediate language. For example, the multiflow IL allows a declaration that a procedure has no side effects. ---------------------------------------- 2. Write a multiflow frontend which reads its IL Advantages This eliminates the cost of reading in C code. We could take advantage of the full complexity of the intermediate language. Disadvantages It requires adding a major new piece to multiflow. The IL used by the compiler seems to have changed from the IL described in the documentation, so some reverse engineering might be required. ---------------------------------------- 3. Combine the Modula-3 frontend and multiflow into one program. Advantages By using the same procedure call interface as the C frontend or the Fortran frontend we could avoid writing any intermediate files at all. Disadvantages The procedure call interface is apparently not documented. This would take a lot longer to program than using C as an intermediate language. ---------------------------------------- I prefer the first option, using C as the intermediate language. If we choose that option, then I think there is a reasonable chance of porting all of Modula-3 to multiflow this summer. Let me outline a plan for discussion purposes: 1. I will modify a plain DEC SRC Modula-3 frontend (without SPIN extensions) to generate code that works with the 32-bit version of the multiflow compiler. 2. Once the 32-bit version works, I will move to the 64-bit version. With a C intermediate language, I don't expect many problems here. 3. We can merge the new code into the SPIN compiler and compile operating system code. ---------------------------------------- Please let me know what you think about this plan, either through e-mail or at one of our meetings. -- Charlie ******************************************************************************** ******************************************************************************** ******************************************************************************** Date: Tue, 28 May 1996 16:58:43 -0700 From: garrett (Charles Garrett) > Modula-3 has lots of stuff that K&R C doesn't, like classes and > objects and distinctions between objects on the heap and the stack, > and threads and more. How would you encode all this in C? Fortunately, most of these things are handled either in the frontend itself, or in the runtime support code. The intermediate language can be quite oblivious to them. Using C or an intermediate representation of similar power is feasible, as shown by the early Cecil compiler which generated C code or by the present Modula-3 compiler which gets by with GNU rtl instructions. Let me give some examples of how it all works. Objects are mostly taken care of in the frontend. When an object is allocated, the frontend generates a procedure call which allocates the right amount of space and places the proper typecode at the beginning of the space. When a method is invoked, the frontend generates an indirect procedure call using constant offsets which it can compute. The management of threads is primarily handled by the runtime libraries. As long as the frontend inserts the right procedure calls in the right places, threads will work fine. Also, there is some auxiliary information which the frontend generates and which the runtime libraries use, such as the information which tells the garbage collector how to trace objects in the heap. This is generated as static data in the C code which then gets interpreted at runtime. -- Charlie ******************************************************************************** ******************************************************************************** ******************************************************************************** Date: Tue, 28 May 1996 17:15:20 -0700 From: jlo (Jack Lo) Charlie's suggestions are somewhat related to some issues that we've discussed briefly in the context of our simultaneous multithreading (SMT) work. I can talk about some of this next week, but I'll briefly outline some of the issues so you can all think a bit about it. For SMT, we've used a compilation framework that's very similar to the first option that Charlie proposed. We've been using the SUIF compiler from Stanford to parallelize applications, but because it's backend optimizations are minimal and poor, we have it generate C code. We then use the Mflow as the backend optimizer for this C code. The most significant problem with this approach is, as Charlie noted, that we can't specify everything in C that we could in the IL. Specifically, SUIF does a lot of analysis to identify parallel loops and identifies them with calls to a runtime in the C code. The Mflow compiler, though, can't distinguish these calls from any other call; when converting SUIF IL to C code, we've lost all of the parallelization analysis done by SUIF. I'm not familiar with Modula 3, but I wonder whether you might encounter similar difficulties down the road, if C were used as the IL. For what it's worth, option 2 would be really useful for the SMT work, because it could also leverage off of the Mflow frontend to read in its IL. Anyway, I can discuss this in more detail next week or via email... Jack ******************************************************************************** ******************************************************************************** ******************************************************************************** Date: Tue, 28 May 1996 22:26:59 PDT From: Fletcher Sandbeck Just to put in my two cents in this conversation. The C front end is one of the hairiest modules in the Multiflow compiler. It was originally based on yacc modules and was intended to be easy to expand, but it has been seriously hacked since then. It would be nice to dispose of the whole thing and graft on new C and Fortran front ends. I'm currently working in the front end, trying to figure out how to emit 64 bit IL1 properly. I'll look around and see how easy it would be to separate out the front end and interface directly with IL1. fletcher