From alice!allegra!ames!uw-beaver!hilbert.ms.washington.edu!bill Fri Jun 17 17:30:14 1988
Date: Fri, 17 Jun 88 08:58:54 PDT
From: allegra!ames!uw-beaver!hilbert.ms.washington.edu!bill (Bill Dunlap)
To: uw-hilbert!rab
Subject: new S

	I got it goiong on a Masscomp 5600 running RTU 3.2.  As usual
on the masscomp, there were some compiler and linker bugs that required
a bit of working around.
	I used mach.m and system.h from the sun directory but had to change
the values of R1MACH 1 and 2 because Masscomp uses an exponent of 255
in a floating point number as a reserved operand:

	(uw-bute)23: diff masscomp/mach.m sun/mach.m
	61,63c61,63
	< # Masscomp constants :
	< define(`R1MACH',`ifelse($1,1,1.1754944e-38,
	< $1,2,3.402823466e38,
	---
	> # PDP11 or VAX constants
	> define(`R1MACH',`ifelse($1,1,0.29387359E-38,
	> $1,2,0.17014117E39,


Problems :

1.  cc -u _sym1 -u _sym2
doesn't work.  It hands this to ld as
	ld -u -u _sym1 _sym2
then ld complains that it cannot find file _sym2.  Even when you
invoke ld directly with the -u's in the right places it doesn't seem
to work.  The problem is in $QPE/Makefile
	$(CC) -o nnSqpe $(LDFLAGS) S_load_time.c -u _ld_init -u _Sfun \
When I simply removed '-u _ld_init' things seemed to work.
(Actually, the -u _ld_init now is in the UNDEF macro in $QPE/Makefile.)
It seems that a dummy routine dummy.c that just contains two "extern" statements
referencing these items should have the desired effect also.  (Masscomp,
IBM, and Microsoft are good at breaking ld options so I've come
to avoid using "nonstandard" ld flags.)

2.  In $QPE/subset.c the RECORD macro is too complicated for cc and bad
code is generated.  (The symptom was that (1:10)[2] returned 3, while
(1:10)[2:3] returned 2 3.  This caused all sorted of problems in any
routine which used subscripts -- print, ...) I broke it up into several
simpler statements and it worked.  Here are the diff's:

(uw-bute)11: diff subset.c subset.c.dist
256,264c256
< #define RECORD                if(last>=0){ \
<                               if (span>1) { \
<                                       *to++ = -span ; \
<                                       *to++ = start ; \
<                               } else { \
<                                       *to++ = start ; \
<                               } \
<                               len += span ; \
<                       }
---
> #define RECORD                if(last>=0){span>1?(*to++= -span,*to++=start):(*
to++=start);len+=span;}


The SAFE macro in eval.c was similar in structure (a combination of '?:'
and comma separated lists) and it had given me problems on the RT's pcc
based compiler so I broke it up on the masscomp as well.  Do you know
if this is an ancient pcc bug?

3.  Other problems on the masscomp involved its 'universes' -- if you
are in the att universe /usr/include is a symbolic link to Sys-Roman-Numeral
style of include files, ucb universe gives Arabic-BSD includes and
they haven't sorted out a few things there.  <sys/signal.h> vs. <signal.h>
was the main culprit.  Also, ranlib is necessary in both universes.
