HDTenEightyP/NetNews huggingface dataset:
From: john@iastate.edu (John Hascall)
Subject: Re: DEC Alpha AXP System INTEGER Performance
Organization: Iowa State University, Ames, IA
Date: Sat, 21 Nov 1992 16:11:39 GMT

yankus@IMD.Sterling.COM (Mike Yankus) writes:
}Blair.Phillips@cao.mts.dec.com writes:
}>Most real programs will use the runtime libraries for string manipulation, and
}>anyone serious about speed won't access single bytes very often, ...

}You are forgetting about a large volume of programs which mainly do
}nothing but character manipulation.  These include editors, compilers,
}mail handling, and the very programs which do the posting and reading
}of News.  I would consider a machine which does not have efficient
}character handling capability a step backwards of about 30 years.

Don't forget that the days of byte-sized `characters' are numbered...

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
Xref: sparky comp.arch:11023 alt.folklore.computers:16647
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: comp.arch,alt.folklore.computers
Subject: Re: What happened to the UCSD p-System?
Date: 23 Nov 92 07:35:16 GMT
Organization: St. Peter's College, US

In article <By54pz.9x2@wimsey.bc.ca>, sl@wimsey.bc.ca (Stuart Lynne) writes:
> I remember hearing about this in the early 80's. Rumour had it that they
> did cross development on larger systems (DEC 10's??).

  I don't have the full text of the parent articles available. However, it
looks like at least 2 threads here.

  First, yes, early Microsoft software was cross-assembled on a DECsystem.
At least Microsoft BASIC and Fortran (CP/M versions) were. I'm sure the
assembler (M-80) was. I'm not sure about the Cobol, or any of the "appli-
cation" stuff. They used a version of the DEC assembler and a custom macro
library. With a few (very few) changes, they could assemble either an 8080
version or an 8086 version from the same source file. This is probably due
to the original "gang of three" - Bill Gates, Paul Allen, and Monty David-
off - who did the original BASIC-80 on the Harvard DECsystem while Bill was
in school.

  As far as the UCSD P-system, well, several things went wrong there. One
was that it wasn't supposed to be a "business" and some folks got very
upset when it grew to the size it did, being from a school and all that.
Second, Western Digital did a version of the WD-16 (the same chipset as is
used in the DEC LSI-11 and the Alpha Micro systems) which directly executed
UCSD P-system code. All of the other systems at the time had an emulator
which ran P-system code on the native hardware. Unfortunately, right after
Western Digital built the chipset (the "Pascal Microengine"), the UCSD folks
decided to rearrange the P-code into some incompatible format. This caused
at least one company that was trying to build machines based on the WD-16
to fold. Of course, there wasn't much market for obsoleted WD-16's at that
point. Everybody sort of crawled away from the wreckage saying that they'd
never do anything with UCSD again (except for UCSD, of course, who had the
ego to think that they still had a major market).

  As far as "P-code", I think the term was used by the original poster as
sort of a generic term for common code emulated on diverse hardware plat-
forms. I don't think anyone would actually use UCSD P-system code for such
products as Multiplan - it would make a lot more sense to develop a code
set suited for the particular application. Probably something like Forth
or STOIC, in this case.

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381
From: supnik@human.enet.dec.com (Bob Supnik)
Newsgroups: comp.arch
Subject: Re: DEC Alpha AXP System INTEGER Performance
Summary: Compilers impacts
Date: 15 Nov 92 18:33:26 GMT
Organization: Digital Equipment Corporation


In article <lgbhcmINNmbc@exodus.Eng.Sun.COM>, grover@brahmand.Eng.Sun.COM (Vinod Grover) writes...
> [text deleted]
>The third is to have clever compilers, that make the machine "appear"
>fast.  How do you tell the difference?. If you measured VAX-780 with
>modern compilers today, I bet it would do more than 1 SPEC{fp,int}92
>mark.
> [text deleted]

This experiment has been done, at least in part, by applying the KAP
preprocessor and an up to date FORTRAN compiler to classic VAX's.  For
SPECmark89, the 11/780 is indeed a "1.3 SPECmark89" machine -- mostly
because of the inflation of MATRIX300 seen in other systems.  For SPEC92,
there is less impact.

The reason better compilers can do little with the 11/780 is that it is
not, at base, a pipelined machine.  The principal optimizations to make
for the 780 would be:

	- Inlining, to minimize use of the high overhead procedure
	  call and return instructions
	- Cache blocking, to maximize use of the 8KB cache
	- Global register allocation, to minimize register spills
	- Careful instruction selection, to use the fastest sequences
	  among alternatives

Recent VAX processors, which are heavily pipelined, benefit for more
aggressive compiler techniques just like RISC processors.

Bob Supnik	>Supnik@human.enet.dec.com
		>All opinions expressed are those of a hardline microcoder
		>and do not reflect those of Digital Equipment Corporation
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.arch
Subject: Re: integer distance or sqrt
Date: 17 Nov 92 17:40:49 GMT
Organization: Department of Computer Science, U of Copenhagen

dmagagno@mcs.drexel.edu (David Magagnosc) writes:

>This reminds me of something I came up with not long after the
>Midatlantic ACM Region Programming Contest last year.  One of the
>problems involved computing square roots by the long division-like
>method (which they claimed we all learned in elementary school).
>I translated it to binary, applied the techniques used for division,
>and came up with a sort of non-restoring square root.

>Now, the convergence is linear (2 bits of input for 1 bit of output
>per iteration), but it uses only elementary operations like shifts
>and adds, so its run time should be comparable to a single division.
>Newton's method, on the other hand, typically uses division on
>every iteration.

>So, the real question is, has someone done something like this
before?

Yes, and it has ben discussed on the net earlier (I think in
comp.theory or sci.math).

>How does it really compare for smallish (under 32 or maybe even 64
>bit) square roots?

Very well, depending of course of whether you have fast hardware
division. If division is implemented using shifts, the square root is
usually one-and-a-half times as slow as division.

	Torben Mogensen (torbenm@diku.dk)
Newsgroups: comp.arch
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: 64 bit Alpha AXP -vs- 32 bit computers
Organization: Metaflow Technologies Inc.
Date: Tue, 17 Nov 1992 23:46:15 GMT

As I've heard the explanation, a primary motivation for 64 bits is to
allow for _REALLY_ big virtual address spaces for processes that need
to access oceans of data.  Really gonzo database applications might
want to memory-map humongous database files.  A 64-bit address
space ought to be able to satisfy that kind of requirement for the
forseeable future (given the fogginess of MY crystal ball, the forseeable
future can't be too far way, though  8-).
 

...Russ Schnapp
BIX: rschnapp           Email: uunet!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, California    Unless otw specified, I`m speaking only for myself!
Newsgroups: comp.sys.sgi
From: lroberts@bottom.ssc.gov (Lee Roberts)
Subject: Re: Indigo as server for a RS600 client - was: NFS links from RS6000 server to SGI client
Organization: Superconducting Super Collider Laboratory
Date: Thu, 19 Nov 1992 23:08:54 GMT

At the SSC Laboratory, we have 4 4D/360S fileservers providing NFS service to
30 SPARCstation 2 and 32 HP 9000/720 workstations.  We encountered problems
with tar between the Suns (NFS client) and SGI (NFS server).

We solved the problem by changing the restricted_chown variable in the IRIX
kernel.  According to Chapter 3.3 of the IRIX 4.0.1 release notes for "eoe":

          o The restricted_chown variable in
            /usr/sysgen/master.d/kernel allows the administrator to
            choose between system V and BSD chown(1) behavior.

            If this variable is zero, System V behavior is used,
            allowing any user to give away files.  If the variable
            is non-zero, BSD behavior is used, allowing only the
            superuser to give away files (POSIX compliance requires
            the BSD behavior).

Apparently, Sun's tar performs a chown on the extracted file before writing
the file contents.  On a BSD system such as the Sun, this chown fails for the
non-superuser and uid/gid match the user.  When writing to the SGI NFS server,
the chown command succeeds (it's being performed on a System V system) and
changes the ownership to match the uid/gid in the tar archive.   Since the
file ownership has changed, tar cannot write the contents.  However, when the
SGI NFS server uses BSD chown behavior, the chown fails and the uid/gid remain
that of the user.

I suspect the same behavior is happening between AIX and SGI.

                                                        -- Lee Roberts
From: joost@cadlab.de (Michael Joosten)
Newsgroups: comp.sys.sgi
Subject: Could somebody tell me what SGI C++ versions are there ?
Date: 23 Nov 92 22:54:10
Organization: CADLAB, Paderborn, FRG
Reply-To: joost@cadlab.de
NNTP-Posting-Host: ori.cadlab.uni-paderborn.de

Hello, I've just read a posting that mentioned C++ 3.0 on SGI. We are
currently running IRIX 4.0.2 and got a C++ 2.1.1, which is based on a 2.0
cfront (really stupid, couldn't they call it 2.0.1.1 ?). Now I'd like to know
what versions are also available, e.g. based on cfront 2.1? Our version smells
somehow obsolete...

PS: 'Call SGI's Tech Center' won't help much (I think) because we got our
machines from Siemens Nixdorf (they are an OEM for Indigos) and calling Munich
... 8-; It's always better to know what to demand, right?

Thank you,   Michael
--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Michael Joosten   |       Tel.  : (+49) (+) 5251-284 120                 |
| CADLAB            |       Fax   : (+49) (+) 5251-284 140                 |
| Bahnhofstr. 32    |       E-Mail: joost@cadlab.de                        |
| D-4790 Paderborn  |        	    ...!uunet!unido!cadlab!joost           | 
| FRG               | Mass mail to: joost@pbinfo.uni-paderborn.de          |
|--------------------------------------------------------------------------|
| CADLAB is a cooperation between Uni-GH Paderborn & SNI AG                |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: peterb@perturb.esd.sgi.com (Peter Birch)
Newsgroups: comp.sys.sgi
Subject: Re: How to "downgrade" an R4000 Indigo XS24Z?
Date: 23 Nov 92 19:45:43 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA


In article <Bxz4tv.68s@well.sf.ca.us>, gaarder@well.sf.ca.us writes:
> We have an R4000 Indigo XS24Z, which is  a very nice machine, but we
> need to test our software on other configurations.  What I would like to
> do is remove various pieces of the hardware to reconfigure the beast into
> XS24, XS, and Entry.  Two questions:
> 
> 1.  Do I need to change jumpers or do anything to the hardware other than
> remove the boards?

Entry and the XS/Elan series are significantly different and require not only
different software but different hardware as well.  You can't "reconfigure" an
XS24Z to be an Entry, so unless you have an old Entry graphics board around, you
are out of luck.  To go from an XS24Z to an XS24, just remove the Z-buffer board
(labeled as ZB4.)  To then downgrade to an XS, remove two of the bitplane boards
(the small vertical ones), leaving the one closest to the back of the machine
installed.  

> 2.  Which parts of the software have to be reinstalled when the config is
> changed?  Since this is a temporary change, I would like to have different
> versions of the necessary files on-line and rename them as needed.

See Dave's posting.

peter

.....Peter Birch.....peterb@perturb.esd.sgi.com.....MTS, Graphics Hardware.....
......Silicon Graphics, Inc.....Mountain View, CA 94039.....(415)390-1512......
From: long@vax.ox.ac.uk (Neil J. Long)
Newsgroups: comp.sys.sgi
Subject: Re: PANIC: Indigo R4000 dies once a day
Keywords: R4000, 4.0.5(f), kernel fault
Date: 17 Nov 92 16:47:23 GMT
Organization: Materials Department, University of Oxford

In article <1992Nov13.094218.25798@wisipc.weizmann.ac.il> edelman@wisdom.weizmann.ac.il (Edelman Shimon) writes:
>From: edelman@wisdom.weizmann.ac.il (Edelman Shimon)
>Subject: PANIC: Indigo R4000 dies once a day
>Keywords: R4000, 4.0.5(f), kernel fault
>Date: 13 Nov 92 09:42:18 GMT
>I had a brand-new Indigo R4000 installed on Nov. 5th. The machine came
>up ok, running Irix 4.0.5(f). Since then, it has been crashing
>consistently once about every day, producing a different PANIC message
>every time. Some of the PANICs were because of kernel faults, others
>because of pagedeque faults, etc, etc. The SYSLOG shows some
>suspicious events such as:
>
>	Nov 10 21:38:44 eos unix: sv1LoadMap: bad sv1AddWork
>	Nov 10 21:38:45 eos last message repeated 34 times
>	Nov 10 21:41:32 eos unix: sv1LoadMap: bad sv1AddWork
>	Nov 10 21:41:32 eos last message repeated 24 times
>	Nov 10 22:31:19 eos syslogd: restart
>
>hinv returns the following information:
>
>	1 50 MHZ IP20 Processor
>	FPU: MIPS R4010 Floating Point Chip Revision: 0.0
>	CPU: MIPS R4000 Processor Chip Revision: 2.2
>	On-board serial ports: 2
>	Data cache size: 8 Kbytes
>	Instruction cache size: 8 Kbytes
>	Secondary unified instruction/data cache size: 1 Mbyte
>	Main memory size: 32 Mbytes
>	Integral Ethernet: ec0, version 1
>	Disk drive: unit 1 on SCSI controller 0
>	Integral SCSI controller 0: Version WD33C93B, revision C
>	Iris Audio Processor: revision 10
>	Graphics board: LG1
>	IndigoVideo board: unit 0, revision 3
>
>The SCSI disk I use is a high-speed one from Micropolis:
>
>	Scsi drive type == MICROP  1908-15MZ1078401PR35
>
>Our local SGI people replaced the CPU board and the memory, to no
>avail.
>
>If you have had similar problems with an (R4000-based) Indigo, please
>help!
>
>Many thanks,
>
>-Shimon
>
>--
>Dr. Shimon Edelman             Internet: edelman@wisdom.weizmann.ac.il
>Dept. of Applied Mathematics and Computer Science
>The Weizmann Institute of Science
>Rehovot 76100, ISRAEL
Hi
We have been having a similarly weird experience with one of 5 R4K's - it 
was fine until the video board was installed. I have found that the crashes 
stop if I switch off all networking and run in stand-alone mode. There were 
similar panic messages but ours were all Unrecoverable ECC errors.
Our local SGI people are aware of it and working on a solution, we will run 
either with the svideo board or networking until then.
I will re-post if a solution becomes available - or even an explanantion 8-)
Neil
From: raines@bohr.physics.upenn.edu (Paul Raines)
Newsgroups: comp.sys.sgi
Subject: xman sections
Date: 23 Nov 92 16:03:04 GMT

How does xman on the SGI know to make the all those  
special (3) Subroutine sections such as (X), (Xt) and
(audio).  There doesn't seem to be any mandesc file so
is this hard coded?  I would like to be able to make
a special (3) section also for local subroutines.
-- 
____________________________________________________________________
Paul Raines	raines@bohr.physics.upenn.edu	215-898-8832
Dept. of Physics
University of Pennsylvania
Xref: sparky comp.sys.sgi:16497 comp.emacs:3564 gnu.emacs.help:4817
From: joost@cadlab.de (Michael Joosten)
Newsgroups: comp.sys.sgi,comp.emacs,gnu.emacs.help
Subject: Re: Problem installing emacs on SGI
Date: 16 Nov 92 20:50:29
Organization: CADLAB, Paderborn, FRG
	<SCOTTH.92Nov13145741@hoshi.corp.sgi.com>
Reply-To: joost@cadlab.de
NNTP-Posting-Host: ori.cadlab.uni-paderborn.de
In-reply-to: scotth@hoshi.corp.sgi.com's message of Fri, 13 Nov 1992 19:57:41 GMT

But this patch has problems when I try to strip the dumped xemacs. I'm now
using 4.0.2 and thus the older compiler/linker set. Stripping without the
patch works, but not *with* the new patch. Any clues??

Michael


--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Michael Joosten   |       Tel.  : (+49) (+) 5251-284 120                 |
| CADLAB            |       Fax   : (+49) (+) 5251-284 140                 |
| Bahnhofstr. 32    |       E-Mail: joost@cadlab.de                        |
| D-4790 Paderborn  |        	    ...!uunet!unido!cadlab!joost           | 
| FRG               | Mass mail to: joost@pbinfo.uni-paderborn.de          |
|--------------------------------------------------------------------------|
| CADLAB is a cooperation between Uni-GH Paderborn & SNI AG                |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: alain@paris.asd.sgi.com (Alain Dumesny)
Newsgroups: comp.sys.sgi
Subject: Re: Inventor experience
Date: 19 Nov 1992 02:47:57 GMT
Organization: Silicon Graphics Inc.
Reply-To: alain@sgi.com
NNTP-Posting-Host: paris.asd.sgi.com
Keywords: IRIS Inventor


    In article <141312@lll-winken.LLNL.GOV>, crawfis@ramius.ocf.llnl.gov
    (Roger Crawfis) writes:
    
    I am just getting started with Inventor, but have scanned the painful
    manuals and have a good feel for its power and flexibility. One of the
    strong suits is the object oriented (not!) and C++ functionality. What
    this allows YOU to do, is to think about adding a class (which is much
    harder than using Inventor) for your couple thousand of POLYGONS. Then
    you can define several renderers for this class, the default being
    your meshing into triangles. This buys you the advantage of having a
    set of renderers for different time/quality trade-offs. For
    interactive rotations, render in a streamlined fashion, when the mouse
    stops update the display.

An alternative and easier way (for the original posting) would be to have
different representations of the same data (regular polygons, ploygons
meshed into 10, etc..) using regular Inventor nodes and use the switch
node to toggle between the different resolutions. The viewers even provide
callbacks to let you know when they start/stop doing interactive work, so
you could use those to change your complexity when doing work. 

This would be much simple since you wouldn't have to create your own node
and implement rendering and picking for it (simpler than doing it in GL,
but still some work). You can think of nodes such as SoCoordinate3,
SoQuadMesh, SoFaceSet and SoTriangleStripSet as simple data structures to
hold the verteces, similar to what you would need to create if you wrote
your program in pure GL. I would highly recommend using existing nodes if
you can. Another option is to create your own NodeKit (a way to package
nodes and functionality into a single package).

-------------------------------------------------------------------------
Alain Dumesny   alain@sgi.com   (415)390-5250       Silicon Graphics Inc.
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.sys.sgi
Subject: Re: SGI Space Simulator Version 1.0 (long)
Date: 24 Nov 92 00:45:29 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Nov23.201718.1962@enterprise.rdd.lmsc.lockheed.com>, stiles@rdd.lmsc.lockheed.com (Randy Stiles) writes:
> ...
> BTW - there are some good utilities on sgi.com, but it
> seems somewhat neglected... there are other demos, etc
> floating around that never make their way onto this machine.


Because sgi.com is owned and operated by Silicon Graphics, we cannot:

    -release much of the contents of the tapes or CDROMs on the machine.
	After all, software pays some of our salaries.

    -release things from third parties.
	If the accountants and lawyers ever look at what we're doing,
	they'll probably have cats, legal mumbo-jumbo all over the
	README files or not.  

	Then Imagine the hassles of ensuring that stuff from third
	parties is really free and clear of restrictive lisenses, not
	to mention sufficiently unlike to trash file systems, mail
	passwords home, or anything else surprising.  It's not just
	malign intent you would have to guard against, but the fact
	that many people simply do not conceive of lisense requirements
	or wide testing.

	Shipping third party stuff would no doubt be considered by the
	lawyers "not in the interests of Silicon Graphics Computer
	Systems Inc" and possibly "imply a continued association
	between SGI and the SGI employee who released the stuff is
	undesirable."

	No one associated with the machine sgi.com has the mandate,
	permission, time, or energy to do the moderating that would be
	necessary.

There are plenty of people at other sites to do not suffer any of these
restrictions and who are happy to host third party software.


There is some rather old cruft in sgi.com:~ftp, but you might be amazed
at old systems people like to run (software as well as hardware).


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.sys.sgi
From: hillig@U.Chem.LSA.UMich.EDU (Kurt Hillig)
Subject: Re: Install problem
Date: Tue, 17 Nov 92 09:43:07 EST
Organization: Department of Chemistry, University of Michigan, Ann Arbor
Keywords: Install CDROM remote

In article <1992Nov17.014909.12730@leland.Stanford.EDU> dhinds@leland.Stanford.EDU (David Hinds) writes:
>In article <srp.721956667@cgl.ucsf.edu> srp@cgl.ucsf.edu (Scott R. Presnell) writes:
> >hillig@U.Chem.LSA.UMich.EDU (Kurt Hillig) writes:
> >
> > [deleted...]
> >
> > > When I run inst on a remote machine, I can't get it to communicate with
> > > the 360 server:
> >
> >1) Are all the client machines in /etc/hosts.equiv on uranium?
> >2)	 or is the uranium:~guest/.rhosts file set correctly?
>
>I think this is the real problem.
>
> >3) It is my recollection that the remote user of inst under 3.3.X was
> >"inst," consequently the .rhosts file had to let "inst" use the login..
> >i.e. the <server>:~guest/.rhosts file had:
> >
> >	hostname1	inst
> >	hostname2	inst
>
>It seems to do it as user 'guest', not 'inst'.
>
>        - David Hinds
>          dhinds@allegro.stanford.edu

Bingo!  I had used "inst" in the ~guest/.rhosts file - which I believe
was a "leftover" from 3.3.3....

But this screws up the security, doesn't it?  I disable the guest account
on the server because I don't want people getting on it without a password,
but I can't keep the remote users from leaving guest unprotected.  If I
have to specify "guest" instead of "inst" in the server's .rhosts file, then
guest users on the remote machine still have passwordless access to the server.

Is my memory right that inst used to use the username "inst"?  If so, what's
the rationale for changing this?

Looking at section 3.3 (p. 3-6) of the Iris Software installation Guide, they
suggest setting up an "instuser" account on the server, and in its home
directory's .rhosts file adding lines of the form:

	client.internet.name	instuser

But this doesn't work either.  Since "instuser" isn't defined on the client
but only on the server, inst still can't get in unless the instuser account
has no password.  And creating an instuser account on the client doesn't
help since inst tries to connect to the server as "guest", not as "instuser".

So, from my point of view, it looks like the documentation is wrong -
at least when I follow the directions it doesn't work - and inst's use
of "guest" rather than "inst" leaves a security hole that I can't easily
plug without upsetting some of my users (some of whom just love having
a passwordless guest account!).

Am I still missing something?

-- 
      Kurt Hillig
   Dept. of Chemistry      I always tell the     khillig@umich.edu
 University of Michigan     absolute truth    Telephone (313)747-2867
Ann Arbor, MI  48109-1055    as I see it.    hillig@chem.lsa.umich.edu