HDTenEightyP/NetNews huggingface dataset:
From: steev@ipecac.esd.sgi.com (Motorin' Flarey Henderson)
Subject: Re: Multiprocessor Crimson?
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 21 Jan 93 19:06:40 GMT

In <1993Jan21.104509.11830@cc.ic.ac.uk> vulture@imperial.ac.uk (Thomas Sippel - Dau) writes:

>In article <1993Jan21.044828.17595@ringer.cs.utsa.edu>, senseman@lucy.brainlab.utsa.edu (David M. Senseman) writes:
>[qouting R4400 announcement]
>.....
>- >The R4400 microprocessor is a pin-compatible upgrade to the MIPS R4000* and is
>-                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>- Hmmm...I wonder what would happen if I swapped my Indigo's R4000 with a R4400
>- (besides void my warranty :) Wonder how soon Radio Shack will start stocking
>- R4400's in those cute little containers with a cardboard back and a clear
>- plastic front?

>Unless you damaged the motherboard in the process of hedgehog extraction, 
>it should work very well, chugging along at 50 MHz with beautifully clean 
>signal waveforms. Connect an oscilloscope and enjoy while you compute.

Make sure the part is a 5V part!  Plugging in a 3.3V part is a good way
to blow ~$1000.  I've been out of touch with the R4400 lately, so I'm not
sure which voltage and frequency will be available in what time frame.

The CPU comes out very easily, if you have the special tool available from 
the socket vendor. 

>If you however change the timing crystals as well, you will probably see the
>odd bit of blue smoke from some parts of the random logic on the motherboard.
>I would be very surprised if you could actually get that to work for more than
>a few hours - if at all.

It is possible to increase the frequency beyond 50MHZ (with the appropriate
speed 5V CPU, of course) as long as you keep the external interface running 
at 50MHZ or less.  I'll leave this as an exercise for the reader who doesn't 
care about voiding their warranty %^>

Steve "Anarchist Hardware Hacker at Heart" Valin



--
steve valin		steev@sgi.com
	   	  It's like deja vu all over again...
From: woodacre@mips.com (Michael Woodacre)
Newsgroups: comp.sys.sgi
Subject: Re: Multiprocessor Crimson?
Date: 21 Jan 1993 18:05:14 GMT
Organization: Silicon Graphics, Inc.
Distribution: world
NNTP-Posting-Host: krell.mti.sgi.com

In article <1993Jan21.104509.11830@cc.ic.ac.uk>, vulture@imperial.ac.uk (Thomas Sippel - Dau) writes:
|> In article <1993Jan21.044828.17595@ringer.cs.utsa.edu>, senseman@lucy.brainlab.utsa.edu (David M. Senseman) writes:
|> [qouting R4400 announcement]
|> .....
|> - >The R4400 microprocessor is a pin-compatible upgrade to the MIPS R4000* and is
|> -                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|> - Hmmm...I wonder what would happen if I swapped my Indigo's R4000 with a R4400
|> - (besides void my warranty :) Wonder how soon Radio Shack will start stocking
|> - R4400's in those cute little containers with a cardboard back and a clear
|> - plastic front?
|> 
|> Unless you damaged the motherboard in the process of hedgehog extraction, 
|> it should work very well, chugging along at 50 MHz with beautifully clean 
|> signal waveforms. Connect an oscilloscope and enjoy while you compute.
|> 
|> If you however change the timing crystals as well, you will probably see the
|> odd bit of blue smoke from some parts of the random logic on the motherboard.
|> I would be very surprised if you could actually get that to work for more than
|> a few hours - if at all.
|> 
|>                                       Thomas
|> 
|> -- 
|> *** This is the operative statement, all previous statements are inoperative.
|> *   email: cmaae47 @ ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic on Janet)
|> *   voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
|> *   snail: Imperial College of Science, Technology and Medicine
|> *   The Center for Computing Services, Kensington SW7 2BX, Great Britain

Great care was taken in the design of the r4000/r4400 to allow for simple
system upgrades. The speed of the external memory interface is programmable
to allow it to run slower than the internals of the chip - this means it is
possible to use a 75MHz R4400 in a system designed for a 50MHz R4000 simply
by changing the serial boot rom that sets up the external interface speed and
by changing the crystal to 75MHz. This gets you performance improvement from
the chip running at a higher speed, from the larger caches and the uncached
write buffer on the R4400.

Of course - don't try this at home! ;-)

Cheers,
Mike

-- 
   Michael S. Woodacre | Phone: (415) 390 4175
UUCP: {ames,pyramid,decwrl}!sgi!woodacre OR woodacre@sgi.com
USPS: MIPS Technologies Inc, M/S 10U-178,
      2011 N. Shoreline Blvd, Mountain View, CA 94039



Newsgroups: comp.sys.sgi
From: reznik@robios.me.wisc.edu (Dan S Reznik)
Subject: Upgrading P.I. 4D20
Organization: U. Wisconsin-Madison, Robotics Laboratory
Date: 26 Jan 93 11:46:19


We run a small robotics lab and we have a 4 yr old Personal Iris 4D20
which we would like to upgrade. We have 24 bit color and Z buffer, and
the CPU runs at 12 MHz. Both rendering and compile-times are obviously
very slow for today's standards. Recently there were some postings on
what can be done both in terms of CPU speed and graphic hardware
upgrades. I would appreciate if that (or any related) information were
posted again, in particular, mentioning approximate prices of the
various options available.

Thanks

Dan S Reznik
Robotics Lab
UW-Madison
Newsgroups: comp.sys.sgi
From: ledwards@leland.Stanford.EDU (Laurence James Edwards)
Subject: Re: mouse cleaning
Organization: DSG, Stanford University, CA 94305, USA
Date: Mon, 25 Jan 93 01:43:05 GMT

In article <1993Jan24.043748.18802@ringer.cs.utsa.edu>, senseman@lucy.brainlab.utsa.edu (David M. Senseman) writes:
|> In article <35173@adm.brl.mil> blbates@aero36.larc.nasa.gov (Brent L. Bates ViGYAN AAD/TAB) writes:
|> >
|> >     You're being sarcastic, right?!
|> >     I want my optical mouse back!!!!!!!!!!!!!!!!!!!!!!!!
|> >     Actually, our three older systems still have the superior optical mice,
|> >so I'm only annoyed when I have to use our new Indigo that has the crummy
|> >machanical mouse.  I have yet to hear any one give me an inteligent reason
|> >why they prefer machanical mice.  You still need a pad for them.  The balls
|> >tend to `jam' and jurk.  They are heavy.  And most of all they are machanical,
|> >so they have parts that easily ware out, get dirty, etc..
|> > [...]

I have a slight preference for the optical mice myself ... but under heavy use
the felt pads on the bottom of the mice do wear out, and the aluminum pads do
get sticky and have to be washed.

Larry Edwards
From: smant@nlr.nl (smant g.a.)
Newsgroups: comp.sys.sgi
Subject: RE: troff and nroff
Date: 21 Jan 93 12:24:21 GMT

According to Randolph J. Herber:
> 
[snip!]
> 
> +Getting serious: Am I missing something?
> +Where can I get nroff and troff?
> 
> +Regards,
> +Horst Kern
[snip!]
> 
> This is a FAQ!  But, the FAQ file is not ready. :-(
> 
> DWB (I believe a 2.0 or 2.1 version) is a package available from SGI.
> The last I heard it cost about $300.  This gives you nroff and troff.
> 
[snip!]
> But you say you also want to print the manuals.  Gotcha!
> To obtain the necessary tables (which I feel should be part of DWB),
> you need to obtain LPS (Laser Printer Support).  This is a mere $800.
> 

I think it would be better if SGi moved the dps_dev (Display PostScript
Development System) from the IRIS Development Option (IDO) package onto
the Laser Printer Support (LPS) package and in stead of the dps_dev, SGi
could supply the Documenter's Workbench (DWB) with the rest of the IDO
package (developers do make man-pages, don't they?). I think these would
make a MUCH BETTER combination!

What is the opinion of all you SGi-machine users out there ?!?!

-- 
Best Regards, Geert Albert Smant.
------------------------------------------------------------------------
Ing. G.A. Smant (Informatics Division, IR-NOP)
National Aerospace Laboratory (NLR)           Email:   smant@nlr.nl
Voorsterweg  31,  8316 PR Marknesse           Phone: (+31)(0)5274 - 8418
P.O. Box    153,  8300 AD Emmeloord                  (+31)(0)5274 - 8444
The Netherlands                               Fax:   (+31)(0)5274 - 8210
------------------------------------------------------------------------
From: mouli@irit.irit.fr (Richard MOULI)
Newsgroups: comp.sys.sgi
Subject: bug(s) in gldebug ?? (!)
Date: 27 Jan 93 18:09:36 GMT
Organization: IRIT-UPS, Toulouse, France

I write this litle code to tri gldebug :

----------------------------------------------------------------
#include <gl.h>
#include <gl/get.h>

main()
{	long w, w1, sw1;

	foreground();
	w = winopen("RGB");
	RGBmode();
	gconfig();
	RGBcolor(25, 220, 125);
	clear();
	w1 = winopen("MAP");
	sw1 = swinopen(w1);
	winposition(10, 20, 10, 20);
	reshapeviewport();
	winset(w1);
	color(2);
	clear();
	winset(w);
	printf("mode %ld %ld\n", DMRGB, getdisplaymode());
	winset(sw1);
	printf("mode %ld %ld\n", DMSINGLE, getdisplaymode());
	color(3);
	clear();
	getchar();
}

----------------------------------------------------------------
the ouput of an excecution is : 
mode 0 0
mode 1 1

This mean the window w is in single buffer and rgb color mode.
And the subwindow of sw1 of window w1 is in single buffer and map color mode.
It's what it's expected.

Then I run :
% gldegub test
and I obtained the following history produced by gldebug :
----------------------------------------------------------------
/* GLDEBUG HISTORY */

foreground();
winopen("RGB");
RGBmode();
gconfig();
RGBcolor(25, 220, 125);
clear();
winopen("MAP");
swinopen(2);
winposition(10, 20, 10, 20);
reshapeviewport();
winset(2);
color(2);
clear();
winset(1);
getdisplaymode();
winset(3);
getdisplaymode();
color(3);

/* XXX GLDEBUG WARNING - color(): called in bad state: RGB mode XXX */

clear();
----------------------------------------------------------------

Does anybody have an explanation of the warning detected by gldebug?
Is this a bug of gldebug?
...

Richard MOULI UPS-IRIT Toulouse FRANCE

mouli@irit.fr
Xref: sparky comp.sys.sgi:18985 comp.lang.c++:19659
From: tpm@ecs (TP Monks)
Newsgroups: comp.sys.sgi,comp.lang.c++
Subject: C++ templates, link simulation.
Date: 21 Jan 93 09:39:44 GMT


I'm using cfront on an sgi machine and have come across a problem.
It appears that the link simulator is not capable of picking up
undefined symbols in libraries.  I had a quick hunt through the doc 
but didn't spot any mention of this... perhaps I was too quick..
							  
In a large project with several libraries, isn't it a reasonable to want to
use libraries containing template definitions, and to link into these
relying on a common repository to allow undefined symbols to be resolved.

Isn't it a pain to have lots of template definition files kicking around
which aren't in a library?
								 
Please could someone point me to a ref for this.

Tim

--
-----------------------------------------------------------------------------
Tim Monks                                Vision, Speech and Signal Processing
tpm@ecs.soton.ac.uk                                    Southampton University
Tel: +44 (703) 592774                                   Fax: +44 (703) 592895
Newsgroups: comp.sys.sgi
From: pebi@aem.umn.edu (Peter A. Bidian)
Subject: Re: colrm
Organization: University of Minnesota
Date: Wed, 27 Jan 1993 19:39:59 GMT

pebi@aem.umn.edu (Peter A. Bidian) writes:


>Hi!

>I have a quick question. Maybe that hasn't to do with the IRIS itself
>but it occurs on an Iris, so maybe someone can help. 

>On a Sun I have a command colrm, that allows me to delete the characters
>up to a certain position. On the Iris this doesn't work. It says
>'Command not found'. Do you know what an equivalent command would be?

>The concrete example is:

>	set prompt="`hostname|colrm 3`> "

>I want to have only the first two characters from the hostname as a prompt.

>Thanks,

Thanks to all who answered. The cut command indeed does the job.

Peter


>		                                                               
>==========================================================================
>Peter Bidian					Internet: pebi@aem.umn.edu
>Dept. of Aerospace Eng.				Bitnet:    AE02022@UMNACVX
>University of Minnesota				phone:      (612) 625-1346
>==========================================================================
Newsgroups: comp.sys.sgi
From: vulture@imperial.ac.uk (Thomas Sippel - Dau)
Subject: Re: Multiprocessor Crimson?
Reply-To: cmaae47@imperial.ac.uk
Organization: Imperial College of Science, Technology and Medicine
Date: Thu, 21 Jan 93 10:45:09 GMT

In article <1993Jan21.044828.17595@ringer.cs.utsa.edu>, senseman@lucy.brainlab.utsa.edu (David M. Senseman) writes:
[qouting R4400 announcement]
.....
- >The R4400 microprocessor is a pin-compatible upgrade to the MIPS R4000* and is
-                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- Hmmm...I wonder what would happen if I swapped my Indigo's R4000 with a R4400
- (besides void my warranty :) Wonder how soon Radio Shack will start stocking
- R4400's in those cute little containers with a cardboard back and a clear
- plastic front?

Unless you damaged the motherboard in the process of hedgehog extraction, 
it should work very well, chugging along at 50 MHz with beautifully clean 
signal waveforms. Connect an oscilloscope and enjoy while you compute.

If you however change the timing crystals as well, you will probably see the
odd bit of blue smoke from some parts of the random logic on the motherboard.
I would be very surprised if you could actually get that to work for more than
a few hours - if at all.

                                      Thomas

-- 
*** This is the operative statement, all previous statements are inoperative.
*   email: cmaae47 @ ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic on Janet)
*   voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
*   snail: Imperial College of Science, Technology and Medicine
*   The Center for Computing Services, Kensington SW7 2BX, Great Britain
Newsgroups: comp.sys.sgi
From: acas@cgl.citri.edu.au (Andrew Cassin)
Subject: Development tools bundled with IRIX?
Organization: Collaborative Information Technology Research Institute
Date: 28 Jan 93 06:46:10 GMT

An interesting quote appeared in a recent UnixWorld (Volume IX, No. 11, 
November 1992, page 67):

Quote:
"The unbundling decision isn't unanimous. IBM includes a compiler with AIX,
its version of UNIX for its RS/6000 workstations, as does Silicon Graphics
Inc. with its graphical workstations."

This is not what I hear from SGI Australia (particularly the melbourne 
workshops). I was of the understanding you had to obtain a license for dev, 
is this not the case?  Is this true for any architecture? 

Andrew Cassin
RMIT Advanced Computer Graphics Centre
email address: acas@godzilla.cgl.citri.edu.au
Newsgroups: comp.sys.sgi
From: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Subject: R4400 (was: Re: Multiprocessor Crimson?)
Reply-To: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Organization: MRL - UIUC
Date: Thu, 21 Jan 1993 20:28:16 GMT

In article <1jmokqINNh82@spim.mti.sgi.com>, woodacre@mips.com (Michael Woodacre) writes:
|>In article <1993Jan21.104509.11830@cc.ic.ac.uk>, vulture@imperial.ac.uk (Thomas Sippel - Dau)
|>writes:
|>|> In article <1993Jan21.044828.17595@ringer.cs.utsa.edu>, senseman@lucy.brainlab.utsa.edu (David
|>M. Senseman) writes:
|>|> [qouting R4400 announcement]
|>|> .....
|>|> - >The R4400 microprocessor is a pin-compatible upgrade to the MIPS R4000* and is
|>|> -                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|>|> - Hmmm...I wonder what would happen if I swapped my Indigo's R4000 with a R4400
|>|> - (besides void my warranty :) Wonder how soon Radio Shack will start stocking
|>
|>Great care was taken in the design of the r4000/r4400 to allow for simple
|>system upgrades. The speed of the external memory interface is programmable
|>to allow it to run slower than the internals of the chip - this means it is
|>possible to use a 75MHz R4400 in a system designed for a 50MHz R4000 simply
|>by changing the serial boot rom that sets up the external interface speed and
|>by changing the crystal to 75MHz. This gets you performance improvement from
|>the chip running at a higher speed, from the larger caches and the uncached
|>write buffer on the R4400.

i know this is one of the questions which have no answer, or any answer,
because it's application-dependent, but *roughly*, what kind of improvement in 
64-bit floating point speed is expected from the R4400, with respect to the
R4000?  +10%? +50%? +300%?

--
furio ercolessi    <furio@uiuc.edu>*    <furio@sissa.it>+
* materials research lab, uni illinois at urbana-champaign
+ intl school for advanced studies, trieste, italy   

"Change nothing and continue with immaculate consistency"
                                      [ Brian Eno, "Oblique Strategies" ]
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: R4400 (was: Re: Multiprocessor Crimson?)
Date: 22 Jan 93 08:24:00 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <C180v5.L6q@news.cso.uiuc.edu> ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi) writes:
| i know this is one of the questions which have no answer, or any answer,
| because it's application-dependent, but *roughly*, what kind of improvement in 
| 64-bit floating point speed is expected from the R4400, with respect to the
| R4000?  +10%? +50%? +300%?

IF they are both running at 50 MHz (i.e., only the cache size differences
having an effect), then I'd expect it to be quite small for most programs.
Of course, if you have lots of loops that fit in 16K, but not in 8
(or data for those loops), it could be fairly substantial.

If you are talking 75 MHz R4400 vs 50 MHz R4000, then I'd expect
somewhat less than 50% for most code, since memory bandwidth
will (on most implementations, anyway) remain the same.  Of course
the cache effects above could also come into play.  The real answer
is that you will have to try on code that you care about.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
From: shankar@sgi.com (Shankar Unni)
Newsgroups: comp.sys.sgi
Subject: Re: Does an Indigo make read-only text segments?
Date: 25 Jan 1993 21:50:28 GMT
Organization: Silicon Graphics, Inc.
NNTP-Posting-Host: boris.wpd.sgi.com
X-Newsreader: Tin 1.1 PL5

Shankar Unni (shankar@sgi.com) wrote:

> Stephen Samuel (samuel@cs.ubc.ca) wrote:
> > char *astring="a constant string";
> 
> This is a direct violation of ANSI C right there.

Sorry. I just got rapped figuratively on the knuckles for making this wild
statement.

Character string literals are of type "char *". *However*, any attempts to
modify their contents are, according to the standard, likely to cause
"undefined behavior" in the program. So that is covered there..
--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-390-2072
Newsgroups: comp.sys.sgi,comp.lang.fortran
From: johnu@syma.sussex.ac.uk (John E. Upham)
Subject: Linking problem in Fortran
Keywords: link
Organization: University of Sussex
Date: Mon, 25 Jan 1993 12:59:43 GMT

I am trying to link two files and get the following error message:

/usr/bin/ld:
No symbolic information for: test.o


I'm using the  Makefile appended below and the file test.o is
mipseb demand paged stripped - version 2.0 and I havnt got access to the
.f file. My compiler is 3.4.1 on OS 4.0.5f on a SG Indigo R4000.

Thanks for any help.

 John upham

FFLAGS	=  -G 0 -O1

FCOMPL= f77

all: program

testl0.o:	testl0.f
		$(FCOMPL) $(FFLAGS) -c testl0.f

test:	testl0.o test.o
	$(FCOMPL) -o prog testl0.o test.o


-- 
John Upham, Dept. of Chemistry, University of Reading, Berks., RG6 2AD, UK.
Email: scsupham%susssys1.rdg.ac.uk@uk.ac (BITnet), scsupham@rdg.susssys1 (Janet)
Voice:   +44 734 875123 x7441 (day), Fax: +44 734 311610
From: potatoe@mind.ORG (potatoe)
Newsgroups: comp.sys.sgi
Subject: New Product Release
Date: 23 Jan 93 16:14:45 GMT
Article-I.D.: mind.a4ZuXB2w165w
Organization: Fortress Development HQ


        Applied Innovation Management introduces INFO-POWER
             a network distributive information system
 
 FREEMONT, CA - Applied Innovation Management introduces INFO-POWER,
 a network distributive information system designed to help system
 administrators, network managers and users better manage their 
 network and workstations.  INFO-POWER is a custom database and daemon
 server that is designed to run on a heterogenous network.
 
 Some of the features of INFO-POWER:
 
 - Problem Tracking
 - Asset Tracking
 - Service and Support Agreements
 - System Configurations
 - User Management
 - Network Printer Management
 - Software Distribution
 - Job Scheduler
 
 INFO-POWER has a user friendly, window interface.  Menus, buttons,
 scroll lists and other familiar gadgets allow the user quick and simple
 access to all INFO-POWER's tools.  The interface will run on any 
computer
 that supports a VT-100 terminal.  A systems administrator can dial in
 on his PC from home and use INFO-POWER!  Open Look and Motif interfaces
 are also available.
 
 INFO-POWER is designed to operate in a heterogenous environment.  The 
only
 requirement is that the database server reside on a Sun, HP, DEC Ultrix,
 or IBM RS6000.  Any computer on the network with connectivity to the 
 database server can run INFO-POWER.
 
 Applied Innovation Management, Inc. manufactures and markets network
 distributive information systems and mass storage subsystems.  For
 For more information, call or write them at:
 
 Applied Innovation Management, Inc.
 46540 Freemont Blvd. #502
 Fremont, CA 94538
 Tel: 510-226-2727
 Fax: 510-226-7990
 
 In the southeast:
 
 Applied Innovation Management, Inc.
 2203 Ashley Run Drive
 Norcross, GA 30092
 Tel/Fax: 404-409-1082 
 
 In the Washington D.C. area:
 
 Applied Innovation Management, Inc.
 5349 Columbia Road, Ste. B
 Columbia, MD 21044
 Tel/Fax: 410-730-1977