🚀 go-pugleaf

>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)