kelem@aero2.ARPA (08/30/85)
>To: info-vlsi@sandia-cad.ARPA >Subject: Magic on Apollo and others? >Does anybody know of a port of Magic to the Apollo workstation? How about >ports to other systems and graphics terminals? We like to get in touch with >people who have done ports. >--Bob Mayo, for the Magic group > mayo@ucbkim.BERKELEY.EDU > mayo@berkeley.ARPA > ucbvax!mayo -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= We (The Aerospace Corporation's Computer Science Lab) have tried to port the Berkeley cad tools to the Apollos. Admittedly, not yet to the newest SR9 pre-release, but to all the releases since SR7. (SR==Software Release) We have had lots of problems trying to do the ports: 1. Name changes in /usr/include/stdio.h . Apollo changed names like _IOREAD to _SIRD, etc. This is somewhat minor, and could be easily remedied by adding the Unix names to the Apollo stdio.h file if we knew that there was a one-to-one correspondence between the Unix names and the Apollo names (there are a few we're not sure about). 2. Long names are used in many programs developed under BSD4.2, but cause problems on Apollos. 32 is a magic number at Apollo. The maximum stack size in the compiler is 32. The maximum variable name length is 32. The same restriction applies to external names, and file names. Apollo is experimenting with a fix to the C compiler to extend the names to something really big (512? just like on the Vax), but that won't solve the external name length restriction. Since this is a major rewrite for Apollo's operating system and software, Apollo says they're not going to worry about extending the lengths until they do an Ada compiler. They haven't set a date for that. 3. Apollo sells a CORE graphics package, but because of the name length restriction and for a consistent naming strategy in Apollo libraries, they've changed ALL the names in the Siggraph CORE standard. First, they've prefixed all the routine names with "CORE_$". Second, they've shorted the Siggraph CORE names so that each routine name is 32 characters or shorter. Third, the parameters to the Apollo CORE routines are compatible between C, Pascal, and FORTRAN, so structures are represented by the highest common language feature - the array. So instead of referencing the primitive attribute "font" with "attribute.font" on the Sun and Vax (with Schlumberger/Fairchild's cgraph package), you have to do it with "attribute[3]" on the Apollo. Again, porting Schlumberger/Fairchild's cgraph package is difficult because of the name length restrictions on the Apollo. 4. Berkeley comes out with new versions pretty often (full releases twice a year?) and fixes whenever they're discovered. (For cad tool user, this is a great feature. For someone doing a port, this is a real problem.) With these factors to consider, what's the best strategy to getting the cad tools running on the Apollos? Getting someone to do the port would be ok, except for the fact that new versions come pretty quickly, and then a lot of work has to be redone. Porting means a longer delay before getting the new version/fix running and manual conversion is a good source of bugs. It's not like porting to the Suns and Vaxes, where you unload the source files, compile 'em, and then run (we did this on a demo Sun and it worked). If someone else does the conversion, then it's pretty difficult for us to find or track down bugs. (I'm not saying that we want to fix bugs, but having the source makes it a lot easier to find out where a problem lies before submitting a bug report to the authors.) The worst part of this strategy is that if we make improvements, we can't share them with the rest of the community without doing a LOT of extra work. The next best thing is to try to write a translator from Siggraph CORE into Apollo CORE. This could only be done if the original source is kept, and modifications (not Apollo-specific) are made ONLY to the original and not the translated copy. But this is also a lot of work. Not only do the CORE routine names have to be changed (via lookup & substitution), but CORE structures have to be converted to Apollo arrays and long variable names have to be shortened to meet the 32-character restriction. We haven't tried to do this...yet. The best solution is to try to get Apollo to fix their software. They claim it's BSD4.2 compatible, but there are still a few things that need fixing before software will port easily. We are interested in getting the Berkeley, Schlumberger/Fairchild, and our own tools running on the Apollos. We are currently working with the Apollo C compiler and the Apollo Unix efforts as a beta-test site. We will provide testing support if anyone else has already started the work. Of course, we would like to see and work with a group effort to get Apollo to understand the importance of the work. Steve Kelem The Aerospace Corporation (a non-profit, Federally Chartered Research Center)