Sun-Spots-Request@RICE.EDU (Vicky Riffle) (08/24/87)
SUN-SPOTS DIGEST Monday, 24 August 1987 Volume 5 : Issue 35
Today's Topics:
Administrivia (FTP and the archives)
Answer to strange FTP question
Re: Strange ftp problems
Warning about SunOS 3.4 and TERM
Faster (slightly) sunview link times
vadvise(VA_ANOM) for garbage collection looses.
Bit-field instructions
netstat interface selection
NTSC Video from Sun Workstations
Minor bug in vmunix; deficit in paging system
Trouble with Ethernet
Re: Sun OS 3.2 Assembler Problem -- bitfield instructions (2)
2 questions: fpa with MAGIC and Eagles with 2333
slipping a cylinder?
Sun and Tokyo Electron sign $10 million OEM agreement
----------------------------------------------------------------------
Date: Mon, 24 Aug 87 11:41:10 CDT
From: William LeFebvre <phil@Rice.edu>
Subject: Administrivia (FTP and the archives)
I realize that there are many people outside of the Internet that are
currently not able to get ahold of source and icons being sent to this
list. I promise to place a positive announcement regarding the archive
server in the next issue. Please be patient. I want to make sure that it
all works well before opening the floodgates.
Those who have unsuccessfully tried to use anonymous FTP from the host
"rice.edu" (to access the archives) need to read more carefully. The
archives (and icons and source) are available from the host named
"titan.rice.edu". The machine "rice.edu" is completely different.
Please FTP to "titan.rice.edu" to log in anonymously.
William LeFebvre
------------------------------
Date: Wed, 19 Aug 87 08:40:20 EDT
From: kimery@helicon.math.purdue.edu
Subject: Answer to strange FTP question
Thanks to the 100's of you out there that supplied me with the correct
answer to the strange ftp problem.
The solution was a rather simple one. It seems that the ifconfig was
failing trying to assign and address to match $hostname in rc.boot. This
could be caused by not having the name in the client /etc/hosts match the
one assigned in rc.boot, or the name could be missing all together.
While checking for correct host names and the like I discovered the real
cause of the problem. ALL of the internet address that were placed in the
host table by the SUN setup program had been munged. Address in the form
of 128.210.3.X were transformed into 128.210.X.
The soultion to the problem was to change the address to the correct form
and reboot.
I am happy to report that FTP now works.
Sam Kimery kimery@helicon.math.purdue.edu
Purdue University Mathematics Dept.
[[ Thanks also to Keith Sklower (sklower@renoir.berkeley.edu) and
Sandro Wallach (sandro@itsgw.rpi.edu) for providing similar information
to the digest. As many people suspected, the problem had nothing to do
with subnets. --wnl ]]
------------------------------
Date: Tue, 18 Aug 87 20:37:02 PDT
From: Craig Leres <leres%lbl-helios@lbl-rtsg.arpa>
Subject: Re: Strange ftp problems
I have a 3/140 that was giving me the "ftp: bind: can't assign requested
address" error message. The problem was garbage in the sockaddr struct in
the ie_softc struct. This was because /etc/rc.local was setup to ifconfig
le0 instead of ie0 (I had copied a 3/50 root when setting up the 3/140.) I
suspect there is some nd magic that partially sets the ethernet data
structures; this explains why the 3/140 could boot and work (almost
normally) even though its ethernet interface had not been properly
ifconfig'ed.
It is unclear to me what this problem has to do with subnets. Both 3.3 and
3.4 definitely support subnets; this was achieved through kernel not
client changes.
Craig
[[ Looks like this was a different problem with similar symptoms. --wnl ]]
------------------------------
Date: Mon, 17 Aug 87 15:03:43 PDT
From: jonab@cam.unisys.com (Jonathan P. Biggar)
Subject: Warning about SunOS 3.4 and TERM
A warning to all who have or will install Sun OS release 3.4:
The interaction between 'set term' and 'setenv TERM' in csh has been
changed. Under release 3.2 or earlier, setting the csh variable term
would update the environment variable TERM and vice versa. Now, under
3.4, setting term will udate TERM, but setenv'ing TERM will not update
term. This causes a problem because the 'tset' command updates only the
environment variable.
To work around this problem, in your .login place the following command
after you call tset:
set term=$TERM
Yet another example of Sun changing something to be incompatible with
normal 4.2/4.3 functionality.
Jon Biggar
jonab@cam.unisys.com
------------------------------
Date: Mon, 17 Aug 87 16:26:06 -0700
From: Bob Brown <rlb@riacs.edu>
Subject: Faster (slightly) sunview link times
I've chopped about 20-30% off of the time it takes the loader to link a
moderately large program (10K lines source) with the Sun View, et al.,
libraries. I did this by creating a SunView.o that contains all the
routines my program uses from the suntool, sunwindow, and pixrect
libraries, and then linking that with my dot-oh files. Sample ld times on
a 3/180S are below. I expect the savings would be greater,
percentage-wise, on smaller programs.
scanning libraries using SunView.o
14.9u 4.2s 0:30 10.7u 3.5s 0:23
14.6u 3.6s 0:29 11.2u 3.0s 0:21
14.4u 4.5S 0:31 10.7u 3.4s 0:20
The apropos lines in my Makefile are
myProg: ${OBJS} SunView.o
cc ${CFLAGS} -o myProg ${OBJS} SunView.o
SunView.o:SUNVIEW.EXTERNS
ld -r `sed 's/^/-u /' SUNVIEW.EXTERNS` ${LIBS}
mv a.out SunView.o
SUNVIEW.EXTERNS:
cc ${CFLAGS} -o myProg ${OBJS} 2>&1 | \
grep '^_' | sort > SUNVIEW.EXTERNS
This uses a file, SUNVIEW.EXTERNS, to hold the names of the undefined
library routines generated when my program is linked without any
libraries. The construction of SunView.o is accomplished using ld and the
-r option, which preserves the relocation bits and doesn't complain about
other undefines, and the -u option, to force-load the top level Sun
routines from the libraries.
Final note: when I use this method from a diskless workstation (3/160), I
always get NFS timeouts when ld hits the SunView.o file. This happens
even when the network and the server are idle. Both server and client
have 16MB memory.
Bob
------------------------------
Date: Tue, 18 Aug 87 07:46:39 EDT
From: ramsdell%linus@mitre-bedford.arpa
Subject: vadvise(VA_ANOM) for garbage collection looses.
In reply to:
> From: dplatt@teknowledge-vaxc.arpa (Dave Platt)
> Subject: Use of vadvise(VA_ANOM) within Lisp
My experience has been that paging activity always increases as a result
of calling vadvise(VA_ANOM) when using a state-of-the-art garbage
collector, such as the one by Douglas Clark, "An Efficient List-Moving
Algorithm Using Constant Workspace", in CACM, June 1976, Vol. 19, No. 6,
pp. 352-5. My experience comes from writing combinator reduction
machines, but the people on the T Project at Yale came to the same
conclusion. T is a dialect of Lisp based on Scheme which features an
optimizing compiler that generates code of roughly the same quality as
that produced by the C compiler on the Suns when there are no floating
point operations. I think the vadvise(VA_ANOM) was useful for Franz Lisp
when it used a mark and sweep garbage collector. Nearly all Lisps that
stop when garbage collecting, use stop and copy algorithms these days.
There is a call to vadvise that is useful for garbage collection. After
garbage collection has completed, and one of the heaps has been evacuated,
calling vadvise(VA_FLUSH), reduces the total amount of system time used by
a process. This call seems to reduce the effort required to figure out
that the pages in old space should be paged out.
John
P.S. To find out how to obtain T, send mail to T-project@yale.edu.
[[ We've got T at Rice. It's a memory hog, but it works great! --wnl ]]
------------------------------
Date: Tue, 18 Aug 87 08:56:55 PDT
From: pplace!waterworks!deutsch@sun.com (Peter Deutsch)
Subject: Bit-field instructions
The Sun-3 C compiler generates bit-field instructions quite nicely when
accessing struct members that have been declared as bit fields.
Regarding the syntax, remember that the source operand always comes first.
Thus for a bfext instruction, the syntax is
bfextu/s source{bn:w},dn
I don't know whether this actually works in the assembler, but it's what
the compiler produces in a .s file.
------------------------------
Date: Tue, 18 Aug 87 14:24:48 +0200
From: mcvax!olsen!lance@seismo.css.gov (Lance Berc)
Subject: netstat interface selection
(in reply to Terry Slattery Sun-Spots v5i33)
netstat takes an optional (and undocumented) -i<interface> argument for
specifying an interface. For instance "netstat -ime0" will give statistics
for the me0 interface. The documentation ommision has been reported to
Sun.
lance
Lance Berc mcvax!olsen!lance@seismo.css.gov
------------------------------
Date: 19 Aug 87 11:50:00 MST
From: diegert@sandia-2.arpa
Subject: NTSC Video from Sun Workstations
Sun's announcement at Siggraph offers a new way to generate those NTSC
video cassettes you need to help with visualization at your conference
presentations. I have placed my order, but will not have hands-on
experience to report for a few months.
For less money than you need to buy a box to do good (interpolated, etc.)
translation from "high" (about 1000 by 1000) resolution RGB to NTSC, you
can buy a TAAC-1 VME board right off Sun's latest price list at $25000
list. I will slip the TACC inside my 3/280 -- no separate box. Aside
from the TACC's high-resolution ability, interposing itself (RGB in/RGB
out) between Sun's standard frame buffer and its (Hitachi) color display,
the TACC can instead be software configured to generate NTSC video.
Actually the TACC puts out RGB+sync (or will genlock), and you need
something like a Bostch TCE-2000 to put together a composite video signal
for your Sony HF1000 or whatever. I believe that you can use some BNC
Y-adapters and leave both the Sun color monitor and the TCE-2000 hooked to
the TACC's RGB out. (I would be careful to power off the Sun monitor
before telling the TACC to send out NTSC!).
By spending your bucks on the TACC instead of a scan converter you get a
C-programmable (using a cross-compiler on the Sun) co-processor alleged to
to good for graphics or other heavy integer or floating-point crunching.
I vaguely recall that the LINPACK-type routines in the TACC library run at
20-30 MFLOPS but I don't see these timings on the sales blurb. They do
claim doing ray-tracing for "high-quality rendering" in under three
minutes -- I assume this means a ray for each pixel in half the TACC's
frame buffer, 1024x1024x32-bits.
I have no stock, etc., in Sun or in the former Transcept (?) (Sun bought
them). I am just interesting in using this product in my research. My
good intention, once I get a TACC and get it working, is to post a note on
my experience [[ please do. --wnl ]] (unless another TACC'er with more
time to devote beats me to it).
Carl (diegert@sandia-2.arpa)
------------------------------
Date: Mon, 17 Aug 87 19:07:56 +0200
From: H}vard Eidnes <H_Eidnes%vax.runit.unit.uninett@tor.nta.no>
Subject: Minor bug in vmunix; deficit in paging system
The following is output from vmstat on a Sun-3/160 with 12MB memory
installed and with 2 active users:
% vmstat 5
procs memory page disk faults cpu
r b w avm fre re at pi po fr de sr x0 s0 s1 x3 in sy cs us sy id
1 0 0 1920 5952 0 0 0 0 0 72 0 1 0 0 0 5 20 6 1 2 97
1 0 0 2128 5896 0 0 0 0 0 72 0 7 0 0 0 7 208 13 97 3 0
1 0 0 1960 5864 0 0 0 0 0 72 0 6 0 0 0 6 76 11 98 2 0
____________________
From what I have heard about the "de" field it is supposed to indicate
"the short-term memory shortage" or some such. When this figure creeps
above 0, the system is supposed to be really desperate for memory. But as
you can see, there is no paging activity and ample amounts of free memory.
So; bug or feature? Can anyone enlighten me as to what is going on here?
(Oh, by the way, we run SunOS 3.2 configured for 10 users)
E-Mail: <h_eidnes%vax.runit.unit.uninett@tor.nta.no> (or @nta-vax.arpa)
H}vard Eidnes (or TeXish: H\aa vard Eidnes)
Division of Computer Science, Norwegian Institute of Technology
------------------------------
Date: 18 Aug 87 20:42:14 GMT
From: cullvax!drw@eddie.mit.edu (Dale Worley)
Subject: Trouble with Ethernet
We're installing a Sun on an Ethernet that already has a Vax (Ultrix) host
and a bunch of IBM PCs. This seems to work physically fine, but
communications is broken.
It appears that the problem is that the Vax (and the PCs) have internet
addresses 126.1.0.*, whereas the Sun (and its client) have addresses
192.9.200.*. (These aren't properly assigned internet addresses, but we
aren't connected to the internet.) It appears that both the Sun and Vax
believe that all hosts on a single Ethernet have the first three parts of
their addresses the same. Thus, the Sun refuses to put packets on the net
for addresses other than 192.9.200.*, and the Vax refuses to put packets
on the net for addresses other than 126.1.0.*. Thus, the Sun and Vax
can't talk to each other, and a PC can talk to only one of the two at a
time (depending on the address that the PC is set to respond to).
There seem to be two possible solutions:
1. Change the addresses of the Sun (and its client diskless Sun) to
126.1.0.* addresses.
2. Get the Sun and the Vax to understand that both sets of addresses are
physically on the same Ethernet. (Since they are both BSD 4.2 versions,
the same fix should work for both.)
Does anyone know how to do either of these? Please reply directly, as I
don't read any of these newsgroups.
Dale Worley Cullinet Software
ARPA: cullvax!drw@eddie.mit.edu
UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw
------------------------------
Date: Tue, 18 Aug 87 16:38:16 EDT
From: moss!codas!novavax!proxftl!jesse@rutgers.edu (Jesse Perry)
Subject: Re: Sun OS 3.2 Assembler Problem -- bitfield instructions
>From: "Timothy P. Donahue" <tdonahue@lf-server-2.bbn.com>
>
>I'm looking for some help in figuring out the correct Sun OS 3.2 assembler
>syntax for the MC68020 bit field instructions, such as BFFFO. Page 59 of
>the Assembly Language Reference Manual gives the following:
>
> bfffo dn,ea{n,n}
Our system uses Sun OS 3.3, so the following may not be useful to Mr.
Donahue. Then again, it may be, since I had the same problem myself. The
Sun-3 assembly manual is wrong about all the bit field instructions. The
correct forms are:
bfchg ea{n:n} bfffo ea{n:n},dm
bfclr ea{n:n} bfins dm,ea{n:n}
bfexts ea{n:n},dm bfset ea{n:n}
bfextu ea{n:n},dm bftst ea{n:n}
where each operand within the curly braces can be either a data register
or an immediate value between 0 and 31. For example,
bfffo a6@{d0:#4},d1
The first operand in curly braces specifies the bit offset to the low
order bit of the bitfield, while the second operand specifies its width.
While we're on the subject of problems with the assembler, I have a few
questions of my own. Any hints would be appreciated.
1. Does the assembler have any support for the 68020 "memory indirect"
addressing modes? The manual claims it does (p. 45), but the syntax
shown there can't be right -- it is the same as that for register
indirect with index.
2. Is there any way to specify a scale value other than 1, and/or an
outer displacement value, when using the indexed addressing modes?
Again, the syntax shown in the manual does not seem to allow this.
3. Finally, if anyone knows of any bugs in the assembler, I'd like to
hear about them. If there is sufficient response, I'll summarize
for this digest.
-Jesse Perry
Proximity Technology
...!sun!sunvice!proxftl!jesse
------------------------------
Date: Tue, 18 Aug 87 21:37:57 PDT
From: jamesa@sun.com (James D. Allen)
Subject: Re: Sun OS 3.2 Assembler Problem -- bitfield instructions
"Timothy P. Donahue" <tdonahue@lf-server-2.bbn.com> writes:
> I'm looking for some help in figuring out the correct Sun OS 3.2 assembler
> syntax for the MC68020 bit field instructions, such as BFFFO. Page 59 of
> the Assembly Language Reference Manual gives the following:
> bfffo dn,ea{n,n}
> We have tried this (and several dozen variations) and received the
> "Invalid operand" error each time. Curiously, after a day of trying, we
> were unable to get the Sun C compiler to generate any 68020 bit field
> instructions...leading us to believe that they are not working in the
> assembler.
Someone from Sun's compiler group will probably respond to this, but since
I use bfffo on *my* Sun assembler, I'll give it a shot in case they don't.
The general syntax is:
bfffo ea{n:n},dn
Here are some examples:
bfffo d4{#0:#0},d1
bfffo sp@{d6:d7},d1
(A width of 32 can be specified as either 0 or 32, although a warning is
issued if you specify 32.)
I have not gotten the C compiler to generate bit field instructions
either, but the codes are known to `as' and `adb'. They are also known to
the optimizer so that if your C source has:
asm(" bfffo d4{#0,#16},d7");
and is compiled with the `-O' option, register reference reductions will
be done correctly!
Since `adb' knows the codes, and uses the same syntax as `as', you can
always discover the syntax in a roundabout way:
From Motorola documentation determine the desired opcode, eg 0xedc00000
Then:
% cp any_old_a.out scratchpad
% adb -w scratchpad
main?W edc00000
_main: 0x4e560000 = 0xedc00000
main?i
_main: bfffo d0{#0:#32},d0
$q
%
True, this is an ugly thing to have to do, but at least it is general.
I'm glad to see another fan of BFFFO. It would be a shame to miss out on
this efficient instruction just because of a documentation oversight.
-- james dow allen
------------------------------
Date: Fri, 14 Aug 87 14:23:04 EDT
From: Steve Levitan <levitan%pitt@relay.cs.net>
Subject: 2 questions: fpa with MAGIC and Eagles with 2333
Two questions:
Does anyone out there have any experience with MAGIC and the fpa board? We
have a SUN 3/260 OS 3.3 with a fpa. MAGIC 4.2 works fine with the 68881
but with the fpa option it crashes with a floating point exception: "bus
error" (code 404) We do know that MAGIC tinkers with the Signal handlers
and we think that is the cause of the problem. The fpa board does seem to
work fine with all our our software.
Also:
We are thinking of hooking up a M2351 (eagle?) onto our machine. The
eagle has been used for the past 3 years on a VAX/750 and the vms users
claimed it was a 450 meg device. Sun setup claims that a M2351 is a 500+
meg device. Is this a formating issue? Also, we have a Xylogics 450/451
controller and a M2333 260meg drive already. Can we just chain the new
disk on that?
Any help or advice would be appreciated.
Steve Levitan
University of Pittsburgh
Electrical Engineering
csnet: levitan@pitt
------------------------------
Date: 15 Aug 87 12:20:10 PDT (Sat)
From: deanm%tekgvs.tek.com@relay.cs.net
Subject: slipping a cylinder?
I am trying to hook up a Fujitsu M2284 disk drive to a Sun 3/160 via a
Zylogics 451 controller. For reasons which I will not go into, I believe
there is a bad signal on the servo track for cylinder #650.
Is there any way to "slip" this cylinder using the standard Sun diagnostic
software, or by appropriate switch settings on the drive or controller?
Note that the flaw map is too full to enter all 320 sectors and, besides,
there must be an easier way. Someone suggested that it should be simple
to modify the device driver to map cylinders [651,822] to [650,821]. Is
this really true? Thanks for any help.
Dean Messing
Tektronix Laboratories
deanm@tekgvs.tek.com
------------------------------
Date: Wed, 19 Aug 87 10:23:47 PDT
From: marleen@sun.com (Marleen Martin McDaniel)
Subject: Sun and Tokyo Electron sign $10 million OEM agreement
SUN AND TOKYO ELECTRON SIGN $10 MILLION OEM AGREEMENT
MOUNTAIN VIEW, CA August 18, 1987 Sun Microsystems and Tokyo Electron
Ltd., (TEL) of Tokyo, Japan, announced today that TEL's computer systems
division has signed an original-equipment-manufacturer (OEM) agreement
with Sun's Japanese subsidiary, Nihon Sun Microsystems. The agreement is
valued at $10 million over three years.
TEL is Japan's leading supplier of semiconductor production equipment and
electronic parts and components. Under the agreement, TEL will integrate
Sun-3 and the newly introduced Sun-4 workstations with hardware and
software from a variety of vendors, such as GenRad (HILO-3), Convex,
Celerity, Vicom, and SDRC (I-DEAS), and will resell the systems in the
electrical and mechanical computer-aided design markets.
TEL will also sell Sun workstations in Japan as front-end processors for
super-minicomputers. The integrated systems will provide users with
superior computing performance in a distributed networked environment,
using Sun's industry standard Network File System (NFS) to connect systems
from a variety of computer vendors.
Sun is the leading supplier of workstations in Japan, as reported by
Dataquest, Inc. "This agreement with TEL strengthens Sun's prominent
position in Japan," said Dennis Ohryn, vice president of intercontinental
sales for Sun. "Design automation is the largest workstation market in
Japan. We look forward to working with TEL to increase our penetration in
this area."
Tokyo Electron Limited, founded in 1963, has established itself as one of
Japan's leading suppliers of high-technology semiconductor production
equipment, computer systems, and electronic parts and components.
Press contacts: Sun Microsystems, Inc., Kim Miller (415) 691-7583
Tokyo Electron Ltd., Yugi Ogino (415) 964-3127
------------------------------
End of SUN-Spots Digest
***********************