HDTenEightyP/NetNews huggingface dataset:
From: barstad@plains.NoDak.edu (Dwayne Barstad)
Newsgroups: comp.arch
Subject: Upgradeablilty of 386sx machine???
Date: 22 Dec 92 08:11:24 GMT
Article-I.D.: ns1.BznIr0.GLM
Distribution: usa
Organization: North Dakota Higher Education Computing Network

Hello all archetecture wizes,

	I have a rather stupid question to ask.  I have a Packard Bell 386sx
machine (Best Buy special was all I could afford at the time) and would like to
upgrade if possible.  I don't want to get a whole new machine (or mother board)
but just replace the CPU if possible.  Is it possible to replace the sx chip 
with a dx chip (486 or 386) or only a hight Mz 386sx chip...  (Address lines?)
...   Please reply by direct mail only (no need to waste more bandwidth than
I have already), and no flames please... I hope to learn ALL (right..) of it
soon.

Thanks,

Dwayne
-- 
=============================================================================
==  Dwayne Barstad                     barstad@plains.nodak.edu (Internet) ==
==  Computer Engineering (Student)                 barstad@plains (BITNET) ==
==  North Dakota State University		     Phone: (701) 237-5131 ==
=============================================================================
Newsgroups: comp.arch,comp.misc
From: YOUNG@tattoo.cs.widener.edu (Rob Young)
Newsgroups: comp.arch
Subject: Re: Def of a workstation (a lark)
Date: 3 Jan 93 06:00:22 GMT
Organization: Widener News/Mail Gateway
NNTP-Posting-Host: tattoo.cs.widener.edu
X-News-Reader: VMS NEWS 1.20

In <1993Jan3.052930.27869@wam.umd.edu> rsrodger@wam.umd.edu writes:

> 	At first I was tempted to talk about UNIX or RISC, but these
> 	were less than satisfactory (UNIX because he could be running
> 	UNIX, and RISC sounds deficient--those old M68k based Suns are
> 	still workstations...and then there's the 386i...)..
>  
> 	Anyone?  Come to think of it, it's pretty muddled to me, too.
> 

The bus.  At least that is how DEC is differentiating their Alpha PC (yet
to debut) from their workstations.  The PC will have the same chip (125
MHz) as the yet to debut low-end workstation.  The workstation is Turbochannel
based, the PC EISA. 
				Rob

                                                     young@tattoo.cs.widener.edu
"The reasonable man adapts himself to the world; the unreasonable one persists
 in trying to adapt the world to himself.  Therefore all progress depends 
  on the unreasonable man." --George Bernard Shaw
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: IBM AS/400 is the world's slowest computer
Date: 24 Dec 92 23:03:28 GMT
Organization: Auspex Systems, Santa Clara

>You could, of course, either emulate these features in software, or
>modify the basic PowerPC architecture.  ...
>and the second *could* involve extensive modifications to the basic
>PowerPC architecture and implementations.

I'm curious whether such a modified POWER or PowerPC architecture would
have to differ more from the current architecture than, say, the Intel
960 (nine-six-zero) "extended" architecture differs from the 960
"protected" architecture.
Newsgroups: comp.arch
From: feustel@netcom.com (David Feustel)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: DAFCO: OS/2 Software Support & Consulting
Date: Thu, 24 Dec 1992 23:11:52 GMT

Just curious: Is EDT the "real" editor referred to in earlier posts?
If so, I'll stick with the "toy" vi editor.
-- 
Dave Feustel N9MYI <feustel@netcom.com>
 
                        Happy Holidays to ALL!!!
From: imhw400@indyvax.iupui.edu
Newsgroups: comp.arch
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Date: 22 Dec 92 14:23:58 -0500
Followup-To: comp.arch

In article <42743@sdcc12.ucsd.edu>, xm9@sdcc12.ucsd.edu (richard g. adair) writes:
>>6) File system limited to sequential file, forcing applications to create their
>>own file system on top of the UNIX one, thus preventing any standardization or
>>application independent optimization.
> 
> This is  feature, not a bug!  Have you ever worked with a record
> oriented system like VMS?  You spend most of you programming time
> defeating the file system :-(

No, I don't.

> No, UNIX is better for these reasons:
> 
> 	pipes
got it
> 	make
got it
> 	light sub-processes
on the way
> 	the path
got it
> 	transparent networking
Hahahahaha.  Got it.  Had it years earlier.
> 	network file sharing
got it
> 	no RMS
I'm sorry for you.
> 	choice of shells
got it
> 	machine independant, choice of vendor freedom
VMS runs on two architectures now, maybe more later
> 	vendor price and speed wars
VMS has to compete too.  And it does.
> 	better hardware
Hahahahaha
> 	graphics
got it
> 	it does't have DEC-this DEC-that all over (gak!)
The real reason surfaces!
> 	simplicity
got it
-- 
Mark H. Wood, Lead Analyst/Programmer    +1 317 274 0749   [@disclaimer@]
Internet:  IMHW400@INDYVAX.IUPUI.EDU     BITNET:  IMHW400@INDYVAX
Celebrate freedom:  read a banned newsgroup.
From: work@forum.sublink.org (Andrea Gozzi)
Newsgroups: comp.arch
Subject: 0 Wait states and caches
Date: 25 Dec 92 18:39:43 GMT
Organization: Forum Graphics Exchange in Correggio (RE) ITALY

I'm almost a novice in comp.arch, but i have a question for the net.
Today i received a 486SX motherboard at 25MHz. 
It is possible to install an external SRAM cache, but it is not currently
installed on board.
Well, i experimented with the setup for a while and discovered that the board
works at 25MHz with 0 wait states without SRAM cache.

What is the difference in operating at 0wait states with or without
cahce? Installing the cache would make any difference ?

By logic, i'd say no, but if not, for which kind of reason 
did they included the cache possibility?

Andrea
-- 
   ///////////////////////////////////////////////////////////////////////
   /  Andrea Gozzi - Via Campagnola 21/A - 42015 Correggio (RE) ITALY    / 
   /  INTERNET: work@forum.sublink.org UUCP: ..rutgers!sublink!forum     /
   /  Fax ++39522692916 Ints:RayTracing-Electronic Music-Ensoniq addicted/
   ///////////////////////////////////////////////////////////////////////
Newsgroups: comp.arch
From: peter@ferranti.com (Peter da Silva)
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Organization: Xenix Support, FICC
Date: Wed, 30 Dec 1992 19:07:44 GMT

In article <1367@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes:
> I once implemented a complete port of Unix that ran within a single VMS
> process, the Unix kernel ran in a VMS process in supervisor mode, it ran
> multiple Unix processes in user mode, supervisor mode ASTs were used for
> Unix 'interrupts' (for example for input characters from terminals, disk
> IO completeions etc etc)

Sounds reasonable. I'd hate to think of doing it the opposite way.

> >Much of the *C* run-time in *any* language is non-reentrant, and I would
> >be surprised if the VMS library was any better. If I get an AST while I'm

> Yeah this is a major design flaw in the Unix/C world - an operating system
> that returns more than 1 thing from its system calls is implemented in
> a language that only returns 1 thing from a call.

That's not the problem. The problem is that there's all sorts of internal
state. You mention errno, but that's the least of it. What about the internal
contents of io buffers? How do you resolve that? You either abandon user
level buffering (no thanks), or you put a semaphore around every library
call, or you defer ASTs while in the runtime. That means you get unpredictable
I/O delays (how long does a read from a serial port take? Could be days), or
the chance of deadlocks (call printf or WRITE(6,*) in an AST called while
in a previous call to the same routine). Errno is an easy one!

	sigio()
	{
		int save_errno = errno;
		do your own I/O.
		errno = save_errno;
	}

> This doesn't mean that
> C shouldn't have been used for Unix - just that the API should have been 
> designed differently for example:
> 
> 	(act_len, errno) = read(file, data, len);
> 
> probably should have been done as:
> 
> 	errno = read(file, data, len, &act_len);

I like:

	token = syscall(args);
	status = get_status(token);
	result = get_result(token);
	discard(token);

Where token is an opaque object. Much more versatile.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
Newsgroups: comp.arch
Subject: Re: VMS vs Unix
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 24 Dec 92 01:51:55 GMT
Distribution: world
Organization: The Wolery

davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
> In article <1992Dec23.015329.8249@brt.deakin.edu.au>, dougcc@brt.deakin.edu.au (Douglas Miller) writes:
> | no, no, take your pick of VMScluster, DNS, NFS, DECnet/OSI, TCP/IP
> 
>   I tried to stay out, but VMS isn't even transparent across it's local
> devices. A name like
> 
>   joesvax::a$physical_disk$name_here_like_dra0:[dir.dir.dir]filename
> 
> may work from anywhere on the net, but you need to know the node name,
> physical device name, and lots of syntax with variable numbers of
> colons, and [names] as well.

That's one case, ie a DECnet file access.  The exact unix equivalent of

$ cmd joesvax::a$physical_disk$name_here_like_dra0:[dir.dir.dir]filename

% rcp joesvax:/some-root/some-dir/filename localfile
% cmd localfle
% rm localfile

Now, which do _you_ prefer?  The unix approach requires local storage.
DECnet file access doesn't.  (Sure, a lot of cases can be dealt with by
piping, but it's not the same.)

File sharing via DFS, NFS or clustering is genuinely transparent.  (NFS
has some gotchas if the server is a unix box, but only because there aren't
any useful features in the unix filesystem. 8-)

So what's your point?

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
From: wayne@backbone.uucp (Wayne Schlitt)
Newsgroups: comp.arch
Subject: Re: Def of a workstation (a lark)
Date: Mon, 4 Jan 1993 00:42:16 GMT
Organization: The Backbone Cabal
NNTP-Posting-Host: helios.unl.edu

In article <1993Jan3.052930.27869@wam.umd.edu> rsrodger@wam.umd.edu (Yamanari) writes:
>  
> 	Can anyone give me a definition of workstation, other than 
> 	cost, that seperates it from modern high-end PC systems (in his
> 	case, one that cost no more than $3500).


This is almost certain to cause a long string of definitions, and
quite possible a flame war or two.


Why?


Well, other than that's what usually happens on Usenet, it's because
there has never been a clear definition of what a workstation is.
What definition there is, has been defined more by the marking folks
than by anyone else.  There have been long discussions about what the
difference between a mainframe and a minicomputer and a microcomputer
are.  What separates a PC from a workstation is much less well
defined.


So, instead of trying to give one exact definition, I am just going to
list a few general items that I have heard people use.  (Chances are,
you won't think that all of these are good qualifications for what a
workstation is, but then, I don't even agree with all of them... :-)



* A workstation must be network ready.
  This doesn't mean that you can't have one workstation sitting
  somewhere, but you must be able to add additional workstations easily.

* A workstation must be multitasking
  But then, I have heard of DOS machines connected via Novell as being
  called "Novell workstations".  I have also heard HP call the
  HP9000/300's running Rocky Mountain Basic as "basic workstations".
  (they were network ready)

* A workstation must run UNIX
  This is a favorite of the unix bigots.  Of course, one of the
  founders of the workstation field was apollo and they didn't run unix.

* A workstation must have a GUI
  Well, the "Novell workstations" and the "basic workstations"
  mentioned above fail this test, but it does seem to be very common
  for workstations to have a GUI.

* Workstations must be multi-user
  Well, this is kind of part of being on a network.  A lot of what
  goes into Novell is adding multi-user functions to DOS.  This also
  makes OS/2 and WNT questionable.  (That may be why I have heard it
  used as a requirement recently :-)

* Workstations must run a Real Operating System
  A great definition which allows you to get into the "What is a Real
  Operating System flame war".

* "Workstation" is a buzz word
  It became a popular buzz word somewhere after "User Friendly" and
  before "Object Oriented"...   :->


I think the more explicitly you try to make the definition, the less
people you will find that agree with that definition.


-wayne
Xref: sparky comp.arch:11989 comp.sys.dec:6642 comp.sys.sgi:18373 comp.sys.hp:14415
From: mike@starburst.umd.edu (Michael F. Santangelo)
Newsgroups: comp.arch
Subject: Re: question about DMA devices
Date: 27 Dec 1992 21:38:54 GMT
Organization: University of Maryland, Chesapeake Biological Laboratory
NNTP-Posting-Host: starburst.umd.edu

don@zl2tnm.gen.nz (Don Stokes) writes:

>jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes:
>> A number of smaller Vaxen (only the uVaxI? or also the 725/730?) didn't have
>> these and in general had to do I/O a page at a time...probably still slightly
>> faster than a PC/XT :).

>The MicroVAX I addressed memory on the Qbus, in the same way it addressed
>peripherals.  DMA is no different on these systems, except that there is no
>need for mapping registers because the memory is in the same address space
>as the peripheral and can be addressed directly.  I'm not sure about the 
>11/730, but there's nothing special about the I/O adapters -- bog standard
>Unibus devices that presumably have some sort of map into memory.

The 11/730 had mapping registers.  It's memory (MS730-CA) was same
as VAX 11/750's memory boards (MS730CA = MS750-CA 1MB bds).  The 730
had a special I/O accelerator bus for its "IDC" (Integrated Disk
Controller) on the -ZA models (the RB730).  Basically the IDC RB730
board got signals from the UNIBUS controller integral to the KA730
processor board-set but xfered data on the special accelerator bus
(there was some special microcode for those 8 4-bit AMD2901 bit slice
processors that made up the KA730 that handled these xfers).  The
KA730 did have a normal and FULL UNIBUS interface.  The backplane
of the -ZA (IDC based) model had slots (1 full function HEX, and
5 QUAD slots shared with MS730/750 boards).  You could even extend
the UNIBUS into an external BA11 chassis.  But anyway, more approprate
to this thread, the KA730's had the standard VAX UNIBUS interface with
mapping registers, et al.

The latter -CA 730's did away with the IDC/RB730 and just had normal UNIBUS
--
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Michael F. Santangelo                 + Internet: mike@cbl.umd.edu      [work]
Computer & Network Systems Head       +           mike@kavishar.umd.edu [home]
Univ MD: CEES / CBL (Solomons Island) + BITNET:   MIKE@UMUC  [fwd to mike@cbl]
From: mcdonald@aries.scs.uiuc.edu (J. D. McDonald)
Newsgroups: comp.arch
Subject: Re: UNIX fseek time (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
Date: 30 Dec 92 01:25:49 GMT
Organization: UIUC SCS

In article <mcdonald.8@aries.scs.uiuc.edu>  I wrote:

>A seek to a location in a text file is no slower than in a binary file.

>This is because the location ... the number that the fseek is to ...
>can be to a number of bytes in the file ... one does **not** need to
>take into account the CRLF pairs. An fseek can **only** be to one of three
>places:

>1) the beginning

>2) the end
        ^^^
This is wrong. It's illegal. I hit the "send" key too soon!
Newsgroups: comp.arch
Organization: Ministry of Education, Computer Center NETNEWS system V2.3
Date: Monday, 28 Dec 1992 18:07:27 EST
From: <TKUS135@TWNMOE10.BITNET>
Newsgroups: comp.arch
Subject: Asking stuff for HiPPI
 <1hm0cpINN8nf@darkstar.UCSC.EDU>


Greetings:
I'm looking for the info about the HiPPI (High Performance Peripheral
Interface). Any references, papers or journals are highly appreciated.
There is one article concerned about HiPPI can be found in the
"Computer Design," June '92 issue, however without much detailed
description about the architecural layers and protocols.

Please forward your point to me directly.

Thanks,

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Yin-Chih Lin                   Industrial Technology Research Institute (ITRI)
Design Eng.                    Computer & Communication Research Labs.  (CCL)
lycmit@x1sun6.ccl.itri.org.tw  Microcomputer System Department X100
Tel: 886-35-917331             14 Bldg, 195 Chung Hsing Rd., Section 4
Fax: 886-35-917503             Chutung, Hsinchu 31015
                               Taiwan, R.O.C.
From: peter@ferranti.com (peter da silva)
Newsgroups: comp.arch
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Date: 21 Dec 92 21:56:47 GMT
Organization: Xenix Support, FICC

In article <BzIuKw.Buy@dscomsa.desy.de> Hallam@zeus02.desy.de writes:
> There is no way of making a UNIX machine look as if it configured in one way
> to one program but in quite a different way to another program.

That depends on where the program looks for the configuration, of course.
There are UNIX programs with hard-coded file names, just as there are DOS
programs that write direct to the screen. This has to do with how "virtual"
the execution environment is. UNIX does very well in this department compared
to other 20 year old operating systems, and it's quite easy to fake out an
application in all sorts of *other* ways.

But it sounds like what you really want here is Plan 9.

> If you have more
> than 20 people on a cluster you will realize why it is impossible to give root
> privs to everybody.

Why would you want to? We have about three people with root here, and when
more people want it we arrange things so they don't need it.

> Having beds for rent does not mean that a bordello is a hotel.

> A multiuser machine should be just that, it should allow multiple users to
> access it without interfering with each other.

Gee, I thought we were doing that quite well, apart from CPU speed degradation
and so far as I know only the DoD cares about that.

> In addition to this inadequate resource
> monitoring means that the scheduler is practicaly useless, any user can simply
> spawn tasks to increase the proportion of CPU alloted to their needs. 

Well, eventually they reach the per-user process limit. And antisocial
behaviour can be addressed outside the OS. Defending against every possible
resource starvation attack is damned hard, and I'd rather spend my personal
on more productive areas. Like the boot/configuration environment, for example.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
Newsgroups: comp.arch
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: "Open" systems
Organization: Purdue University Statistics Department
Date: Mon, 21 Dec 1992 13:16:29 GMT

In article <fWTeSfY@quack.sac.ca.us> dfox@quack.sac.ca.us (David Fox) writes:
>In article <BzIx0C.C6G@dscomsa.desy.de> Hallam@zeus02.desy.de writes:
>>In article <fWPrzAU@quack.sac.ca.us>, dfox@quack.sac.ca.us (David Fox) writes:

>>|>>|>> So far, the most "open" system I can think of is a 386 running DOS:
>>|>>|>> - systems available from all sorts of people
>>|>>|>> - CPU's available from (at least) AMD, Intel, IBM, and Cyrix

>>|>shell out to the various software writers to try those compilers out.
>>|>With Unix, one can get gcc for free, including source.

But this is on an obsolete computer.  Are any of the newer machines in this
category?  

However, I disagree with the apparent philosophy of the so-called recent
"open systems" approach.  The idea seems to be that information on the
internals will be available to VENDORS, who may or may not put things in.
Now it does not pay a vendor to make a minor change which provides a 
substantial improvement for even 1000 small users, while the users themselves,
given reasonable information, could make it easily.  

A truly open system would enable a user to get rid of the user inimical
(usually called friendly) obstacles which the vendors have put in to reach
the mass market, and to come up with reasonable software.  A disassembler
should be required for ALL software, or a promise to very quickly take care
of these obstacles.

Only someone who is arrogant, ignorant, or stupid can expect vendors to
supply the variety of software which is needed to get good performance.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
Newsgroups: comp.arch
From: kunkel@rchland.vnet.ibm.com (Steven Kunkel)
Subject: Re: IBM AS/400 is the world's slowest computer
Date: Mon, 21 Dec 1992 14:32:32 GMT
Reply-To: kunkel@vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester

In article <1992Dec18.165950.15013@webo.dg.com>, lewine@cheshirecat.webo.dg.com (Donald A. Lewine) writes:
|> IBM is currently running full-page Ads that claim "The AS/400
|> is the world's most powerfull computer with the industry's best
|> price/performance(*)"
|> 
|> "(*) According to the TPC-C benchmark results published through
|>      12/3/92"
|> 
|> IBM does not point out the the AS/400 is the only computer with
|> TPC-C results published as of 12/3/93.  The AS/400 is also the
|> world's slowest and most expensive computer by the same benchmark.
|>

Incorrect.  HP was the first to publish a few months ago.  IBM then
published a high end AS/400 that has better TPC-C performance and a
low end model that has better price/performance.  Look for many
companies to publish this spring now that the ice has been broken.
HP and IBM will also likely publish improved numbers.

TPC-C is, of course, only one benchmark.  However, it better
represents what customers are doing in the transaction processing
market than any other public benchmark.

|> Do people fall for this stuff?  IBM claims that the AS/400 is the
|> best selling mid-range system in the world, so someone must fall
|> for it.
|> 
|> --------------------------------------------------------------------
|> Donald A. Lewine                (508) 870-9008 Voice
|> Data General Corporation        (508) 366-0750 FAX
|> 4400 Computer Drive. MS D112A
|> Westboro, MA 01580  U.S.A.
|> 
|> uucp: uunet!dg!lewine   Internet: lewine@cheshirecat.webo.dg.com

-- 

Regards,

Steven Kunkel
Mail: IBM
      3605 Hwy. 52 North
      Rochester, MN  55901-7829
Phone: (507)253-0698
Email: kunkel@vnet.ibm.com
Disclaimer: Ya' know.  What the lawyers need to see.  I spoke, not IBM. 
Newsgroups: comp.arch
From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Reply-To: vhs@rhein-main.de
Date: Mon, 21 Dec 92 19:46:57 GMT

In article <1992Dec20.164501.291@rlgsc.com> gezelter@rlgsc.com writes:
[discussion about file formats on VMS vs. UNIX flat file deleted]
> Incorrect. The reason that you cannot read it with C is that C 
> has consistently ignored the standardization of IO interfaces.

#include <stdio.h>

(The first line in the first example code in the K&R C book)

Honestly it's the definition of IO that's missing here. C/UNIX
have standardized on NOT sequential but flat direct-access files
for the filesystem and sequential access for pipes, some devices,
input format for most system commands, etc.
Other OSes have standardized on supplying high-level file formats
only (which is braindead) and even others offer both.
I would hazard to say that using non-flat files just isn't as open
as flat files, simply because the lowest common denominator is
exceeded.

--
Volker Herminghaus-Shirai (vhs@qb.rhein-main.de)

Looks good on the outside, but -
	intel inside
Newsgroups: comp.arch