Sun-Spots-Request@RICE.EDU.UUCP (06/04/86)
SUN-SPOTS DIGEST Wednesday, 4 June 1986 Volume 4 : Issue 16
Today's Topics:
3.0, ld, and linking code for another machine
Mac, Sun sharing LaserWriter
SUN-3 rlogin hangs (2)
68020 piggyback
-J option for VAX assembler (3)
SUN-3 add-on serial port wanted (In english)?
Plotting on a 3/160C vs a 3/160M?
AI development on Sun3?
Squealing Sun-3/160M's (2)?
------------------------------------------------------------------------
Date: Fri, 30 May 86 01:11:02 CDT
From: David Chase <rbbb@rice-titan>
Subject: 3.0, ld, and linking code for another machine
Note that (though apparently undocumented) it is possible to convince "cc"
to produce .o's for another machine (that is, on a 68020 you can make an
image for a 68010; I have not tried the other, because it is so much
slower), and it is possible to convince "as" to check for non-68010
instructions in its input. HOWEVER, "ld" steadfastly generates an
executable for whatever machine it happens to be running on at the time.
In this case (since I am trying to support a piece of software for use on
Sun2s and Sun3s, both running 3.0) that means that after all the .o's are
built, I have to hop over to a Sun 2 and link it up (oh, the pain). I
tried running a 68020 executable built out of 68010 objects, and it did
not run at all well on a Sun2.
Does anyone out there know of a way to get ld running on a Sun 3 to
generate an image that will run on a Sun 2? Is it perhaps a matter of
swapping out for a different crt0.o?
David
-----------------------------
Date: Fri 30 May 86 16:09:32-EDT
From: "Ralph W. Hyre, Jr." <Ralph.Hyre@C.CS.CMU.EDU>
Subject: Mac, Sun sharing LaserWriter
Thought some might be interested in this...
---------------
Date: Thu, 29 May 86 12:37:13 pdt
From: normac!tim@su-aimvax.ARPA <Tim McCreery>
Subject: Re: Mac, Sun sharing LaserWriter?
Re: the Sun CPU's 8530 SCC chips
The presence of a Zilog 8530 chip is not sufficient to implement
AppleTalk. The following requirements must also be met:
1) It must be possible to clock the bitstream at 230,400
bits per second which usually means an external crystal oscillator
at either this frequency or some multiple (but not faster than 4 MHz).
2) AppleTalk is implemented over RS422 which requires balanced line
drivers and balanced receivers. Since this isn't required for SCC
chips doing RS232, SCC-using circuits may not have these extra
wires in place.
3) To meet the AppleTalk spec, a filter/T-configuration of resistors
and caps is required between the line drivers and the AppleTalk
connector kit transformer.
4) Since the 8530 has limited buffering and AppleTalk is a synchronous
protocol, somebody has to monitor those buffers to keep the 8530 shifting
complete packets of bits in and out without overrun or underrun.
It works out to be about 35 usec per byte. This normally requires a
dedicated processor because bus latency and task switching often eat
up more time than this.
"Hey, I'm a software guy", so Stephen Lewis helped me succinctly
state the above.
My rumor source said that Sun looked at this, figured out what
was needed and decided not to do it at this time.
Re: NFS for the Mac
It's true. We have done a good paper design and have had some preliminary
talks with Sun and Apple about doing an NFS implementation for the Macintosh.
There are some hard problems surrounding file/directory naming which still
need to be worked out. Our goal would be to run without modifications to
either the Mac's HFS/AFP environment or any vanilla NFS server.
This would enable the Mac to be an NFS client only and we don't plan on
allowing NFS clients to be served by AFP servers using this design.
All the work would be done in the Kinetics gateway; the gateway program will
essentially be an AFP server and NFS client and do session bookkeeping,
all command driven from the AFP client. The gateway would need the full
112k RAM expansion, and possibly larger PROMs in the sockets. We are
estimating that it is a 5-6 man-month project if WE do it, but more
exploratory work needs to be done. We haven't started just yet.
We hope to get to it "real soon now" and this is not an officially
announced product for us. I don't think AFP has been announced by Apple either.
Re: MacWorkstation
The MIS group at Apple has converted MacWorkstation to use AppleTalk
through our gateway to Ethernet hosted on a Vax running VMS....
tim
-------
-----------------------------
Date: Sat, 31 May 86 19:32:01 edt
From: "J. Dean Brock" <unc!brock%unc.csnet@CSNET-RELAY.ARPA>
Subject: Sun3 rlogin problem (1)
You're not the only one with the problem. I've had the same thing
occur when I rlogin'ed from my Sun 3/75 into both Sun 2's and DEC VAXen.
However, the problem isn't restricted to Gnu Emacs, I've had the same
problem when I've suspended Unipress Emacs and mail. Same sort of
problems as you encounter---I restart mail and it sets there and eats
carriage returns and acts upon them (i.e., marks mail as being read), but
nothing happens in my workstation window.
-----------------------------
Date: Fri, 30 May 86 11:23:59 edt
From: Eric N Starkman <ens@ATHENA.MIT.EDU>
Subject: GNUemacs hangs rlogin on 3.0 (2)
We have also had this exact problem, as I'm sure many other
people have.
It has nothing to do with GNUemacs, and nothing to do with
sunwindows. It is a bug in the SUN network code. SUN customer support
initially would not help us -- they claimed that the bug is in
GNUemacs. When given a test program that produced the bug (it was a
program which did a lot of ioctl's; when run over the network, it
produced the problem you describe; when a machine rlogins to itself,
this program hung the machine such that L1-A took a while to respond),
a very helpful Sun engineer observed that the problem does not occur
in their next internal release, and told us of a one-line kernel change
in tcp_output.o that might help. It alone did not. He later provided us
with a new /usr/ucb/rlogin. The combination of this and the new
kernel appears to have solved the problem.
I am not at liberty to mail out the fixes, but it suffices to
say that they do exist and that Sun should be able to make them
available to you.
This is a severe problem and has the potential to affect a large
number of people.
-Eric Starkman
GenRad
ARPA: ens@athena.mit.edu
UUCP: decvax!genrad!ens
or mit-eddie!genrad!ens
-----------------------------
Date: Mon, 02 Jun 86 03:26:58 -0500
From: Mark Weiser <mark@markssun.cs.umd.edu>
Subject: 68020 piggyback
I got one or two replies to my query about piggybacking a 68020 onto
a sun 68010 board. A person who wishes to remain anonymous, but
who tried this, reports that the kernel has to know about the
change, since 680{10,20} differ in some data formats (such as
internal error stack formats). Furthermore, because the 68020
has to run at 10mhz (since other circuitry on the Sun board needs this),
and the bus is still only 16 bits wide, the speedup is marginal.
They got it to work, once, but decided not to pursue it.
-mark
-------
Spoken: Mark Weiser ARPA: mark@maryland Phone: +1-301-454-7817
CSNet: mark@umcp-cs UUCP: {seismo,allegra}!umcp-cs!mark
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742
-----------------------------
Date: Sat, 31 May 86 08:51:30 -0200
From: enea!erisun!hans@seismo.CSS.GOV (Hans J. Albertsson)
Subject: -J flag in pc and GNUemacs hang (1)
-------
The -J flag in pc { should be ,gets } passed to the assembler, at least it did
in 4.xBSD. This seems to be a standard way to handle the back ends of
compilers in UNIX.
About GNUemacs hanging rlogin in a tty window:
Ususally this means page mode is ON, and has triggered, eventhough
the mouse cursor is the ordinary arrow. I've only seen this occur
with 8-bit rlogins.
Only seems to occur in GNUmacs startup.
To get out from under: click right, see "Page Mode Off" is
a selectable item and select that.
--
Two's complement, but three's an int.
Hans Albertsson EIS, USENET/uucp: {decvax,philabs}!mcvax!enea!erix!erisun!hans
-----------------------------
Date: 2 Jun 86 (Mon) 13:10:07 EDT
From: John Bazik <jsb%brown.csnet@CSNET-RELAY.ARPA>
Subject: -J option in vax code (2)
The -J is an assembler option which is passed on by pc on a vax.
-----------------------------
Date: Sat, 31 May 86 07:16:02 -0800
From: ---- <keppel%pavepaws@BERKELEY.EDU>
Subject: -J goes to the VAX assembler (3)
The -J flag is passed to the VAX assembler to create longjump
information for code where byte-displacement (relative) branches are
insufficient. According to a SUN man page, -J produces always the
most general, but also the most expensive brances. This should make
worse (slower, bigger) code, but faster compiles. Why this should
cause a program to malfunction, I don't know. Does anybody else
have any ideas? (Could be a bug here, somewhere)
-David Keppel
"Learn by Osmosis: Gospel in, Gospel Out" ..!ucbvax!pavepaws!keppel
agreed, but 4Mb + 130Mb disc seems likely.
I have heard rumours that certain 2.xx version of Sun Unix give
real problems when using NFS with Sun-3 machines.
-------------
Nick Dunlavey
nickd@qmc-cs.uucp UUCP
...!ukc!{root44,wcwvax,kcl-cs,qmc-ori}!qmc-cs!nickd OLD UUCP
nickd@cs.qmc.ac.uk or nickd@uk.ac.qmc.cs JANET
-----------------------------
Date: Thu, 29 May 86 14:10:37 jst
From: nttlab!murakami@su-shasta.arpa (Kenbo MURAKAMI)
Subject: SUN-3 add-on serial port wanted (In english)?
We are using SUN-3/160M with 2 serial ports. However, there are many users
in our laboratory, and we would like to have more ports on SUN-3. We heard Sun
Microsystems delivered only 16-ports add-on board, which costs about $8,000,
though they say more than 9 users causes SUN-3 overload.
Therefore, we need a less expensive board that has around 4 ports.
Does anyone know the information?
-----------------------------
Date: Fri, 30 May 86 19:21:12 EDT
From: Rick Adams <rick@seismo.CSS.GOV>
Subject: plotting on a 3/160C vs a 3/160M?
Some of my users have complained that plotting on the Sun 3/160C is
slower that on the 3/160M. They are doing no color manipulation
and in fact use the same binary. The 3/160C has the graphics options
installed.
Has anyone else noticed this? Or even better, have an explanation.
---rick
-----------------------------
Date: Sun, 1 Jun 86 19:50:02 EST
From: munnari!cidam.oz!mg@seismo.CSS.GOV (Mike A. Gigante)
Subject: AI development on Sun3?
Hi,
I am seeking opinions about the suitability (or otherwise) of a Sun-3
as a AI development environment.
In particular, a Sun 3/52M-106 running Lucid Common Lisp environment.
(68020, 4Mb mem, 106Mb SCSI Disk)
For approximately the same money, (A$30,000 == US$21,600), I can buy
a 3/52 locally or a Xerox 1186 (probably bypassing the local agents
and buying direct from the US). The Sun price does not include the cost
of Lucid. Of course, bypassing the local agents means giving up any
chance of local support for the 1186.
The choice here is not just performance (although it is important), but
also the development environment. Just how rich is the Lucid environment?
Surely not as rich/mature as the Interlisp-D environment of the Xerox.
Has anyone attempted serious development on both systems? If so, I'd like
to hear of your experiences.
As always, thanks in advance
Mike
-----------
Michael Gigante [Research Engineer]
UUCP :...!seismo!munnari!cidam.oz!mg Dept Mechanical & Production Eng.
ARPA :mg%cidam.oz@seismo.css.gov Royal Melbourne Institute of Technology
CSNET:mg%cidam.oz GPO Box 2476V
Phone: +61 3 660-2161 Melbourne Vic., Australia 3001
-----------------------------
Date: Tue 3 Jun 86 09:14:09-EDT
From: "Ralph W. Hyre, Jr." <Ralph.Hyre@C.CS.CMU.EDU>
Subject: Squealing Sun-3/160M's (1)
The squealing is serious enough to make work unpleasant, has anyone else
experienced it? Does Sun have anything to say about it? Both of our
Sun-3's (iusd, iuse) squeal, but our upgraded Sun-2's (iusb, iusc)
don't.
/usr/demo/jumpdemo causes the most interesting effects.
- Ralph
-------
-----------------------------
Date: Tue 3 Jun 86 11:11:10-EDT
From: Bill.Scherlis@C.CS.CMU.EDU
Subject: Re: Squealing Sun-3/160M's (2)
I noticed it early on, but it eventually went away on my Sun.
It was exceedingly annoying when it was present, though.
Bill
-------
-----------------------------
End of SUN-Spots Digest
***********************