Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsd!chem.ucsd.edu!jwp
From: jwp@chem.ucsd.edu (John Pierce)
Newsgroups: comp.sys.celerity
Subject: Re: X for Celerity?
Message-ID: <678@chem.ucsd.EDU>
Date: 8 Feb 90 07:35:02 GMT
References: <28116@brunix.UUCP>
Reply-To: jwp@chem.ucsd.edu (John Pierce)
Distribution: usa
Organization: Chemistry Dept, UC San Diego
Lines: 52

In article <28116@brunix.UUCP> gwk@cs.brown.edu (Greg Kilcup) writes:
 > 
 > Has anyone ported X to the Celerity?

We have not tried it as a server (would that even be sensible?), but I have
three sitting here happily running client processes for an NCD X-terminal.
There are two (known to me) problems:

1.  X11.src/lib/Xt/TextTr.c contains nothing but a comment at the top of the
file, and the initialization of a char array to a *long* string.  /lib/cpp
(on the Celerity) treats the entire file as a single token; by that, I mean
that the comment is NOT elided prior to tokenizing the character array.  This
causes /lib/cpp to generate a "token too long" error.  Which is stupid.  This
problem is most easily dealt with (not 'fixed') by deleting the comment from
the top of lib/Xt/TextTr.c

Celerity's bcopy() has a problem with negative 'length' arguments.  It will
actually copy between one and eight bytes from 'src' to 'dest', depending on
the *unsigned* value of 'length'.  This condition can actually occur in some
of the 'Resource' associated routines (and possibly elsewhere).  While I
question the philosophical correctness of handing bcopy() a negative length,
it is clear that the actual behavior is incorrect.  Assuming you have bcopy.s,
the following will fix it:

	_bcopy:
	# Collect the arguments.  (This line and next two are original)
		tfsc	s32,%source
		tfsc	s33,%dest
	# The next four lines were added to detect a negative length argument.
		tfsc	s34,%endsource
		aw	%endsource,%source
		cwu	%endsource,%source
		jleq	nop_exit
	# Select direction of move.  (This and balance of file is original)
	...

This fix to bcopy.s may well not be the optimal one.  When I made this I could
not find my copy of the 1230/1260 architecture manual, so I hand to sort of
guess at what the best assembly language would be.  I do know that making this
change allowed the X window system to run correctly on all Celerities at UCSD,
and they would not run correctly (at all, actually) without it.  I don't know
what you do if you don't have source for bcopy.s.  I suppose you either replace
it with a C equivalent that would be a lot slower, or scream a lot at your
field service rep to get you the source.

These problems occur in porting X11.r3 to the Celerity 1230 and 1260D.
Celerity now belongs to Floating Point Systems, and I do not know if these
problems remain in the new FPS boxes.

-- 
   John Pierce	Chemistry, B-032, UCSD, La Jolla,  CA 92093
		jwp@chem.ucsd.edu  jpierce@ucsd  +1 619 534 0203