HDTenEightyP/NetNews huggingface dataset:
From: wayne@backbone.uucp (Wayne Schlitt)
Subject: Re: big + little endian (was: Comparison of Alpha, MIPS ..)
Organization: The Backbone Cabal
	<28164@dog.ee.lbl.gov> <1hquujINNmov@fido.asd.sgi.com>
Date: Wed, 30 Dec 1992 15:39:50 GMT

In article <1hquujINNmov@fido.asd.sgi.com> pj@sam.wpd.sgi.com (Paul Jackson) writes:
> |> 01101001 may mean `105' (big-endian) or `150' (little-endian)
> 
> Big and little endian refer to the order of bytes within words,
> not to the order of bits within bytes.
> 

Big and little endian refer to the order of sub-units within units,
not just bytes and words.  

You can order bits within bytes either way, bytes within words, and
words within double words.  Various computers systems have made
different choices at all of those levels.  The ordering of bits within
bytes has pretty much standardized on the little-endian format.


Similar confusion occurs when you try to decide whether to put the low
address of a memory dump at the top or the bottom of the page and if
you should address the screen from the top left or the bottom left
corner.  (If computer development wasn't so eurocentric, then we would
probably have debates on left vs right too.)


-wayne
From: rf@cl.cam.ac.uk (Robin Fairbairns)
Newsgroups: comp.arch
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Keywords: I/O, Point-to-Point, High Performance, Low Cost, Bus
Date: 22 Dec 92 20:39:20 GMT
Organization: U of Cambridge Computer Lab, UK

In article <id.IO0W.TLE@ferranti.com>, peter@ferranti.com (peter da silva) writes:
|> [re the idea of pluggable buses]
|> [...]
|> 
|> I'd like to see the bus specifics decoupled from the software, so you had
|> some sort of interface that you told "go to unit so-and-so and send this
|> control/read this data". Then you could use a low-cost hookup with ethernet
|> type cables, or a high-speed bus type option, without impacting the software.
|> You could even plug a low-speed adaptor into a high speed bus to hook up
|> your laptop when you get home.
|> 
|> If course this would logically be a LAN (um, CAN: Computer Area Network?).

We have a project making this sort of thing here.  The network
technology is actually ATM, and the problem being addressed is that of
bus overload arising from very high incoming data rates from a gigabit
network - the data never actually touches a `bus', it goes direct to
the device it's for.

This is a big win in the case we're interested in, the multimedia
video stream (which can come direct from our ATM camera in one
workstation, over one of the ATM LANs we have, and thence to the ATM
framestore which we'll have real soon now (TM)).


But there are interesting other classes of research issue - for
example, if your processor is separated from its DRAM by an ATM
interconnect, how's about rescheduling when you get a secondary cache
miss?

And the name?  Well, it's not so much a computer-area as a desk-area:
it's called a DAN.
--
Robin (Campaign for Real Radio 3) Fairbairns       rf@cl.cam.ac.uk
U of Cambridge Computer Lab, Pembroke St, Cambridge  CB2 3QG, UK
"They had twelve years to lay in wait for us" - Bush supporter on Nov 4
From: pj@sam.wpd.sgi.com (Paul Jackson)
Newsgroups: comp.arch
Subject: big + little endian (was: Comparison of Alpha, MIPS ..)
Date: 30 Dec 1992 01:44:51 GMT
Organization: Silicon Graphics, Research & Development
Distribution: world
Reply-To: pj@sgi.com
NNTP-Posting-Host: sam.wpd.sgi.com

In article <28164@dog.ee.lbl.gov>, torek@horse.ee.lbl.gov (Chris Torek) writes:
|> 01101001 may mean `105' (big-endian) or `150' (little-endian)

Big and little endian refer to the order of bytes within words,
not to the order of bits within bytes.

I have followed this up to just comp.arch, not the other groups
for dec, sgi or hp, against my better judgement (which was to
follow up to /dev/null.)

-- 

				I won't rest till it's the best ...
				Software Production Engineer
				Paul Jackson (pj@sgi.com), x1373
Newsgroups: comp.arch
From: stripes@pix.com (Josh Osborne)
Subject: Re: Any new instructions in a i486?
Organization: Pix Technologies -- The company with no adult supervision
Date: Tue, 22 Dec 1992 02:19:41 GMT

In article <id.RO0W.F1F@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <BzMEIJ.Anz@pix.com> stripes@pix.com (Josh Osborne) writes:
[...someone says the cy486DLC + cy487 is about as fast is an i486DX...]
>> I don't think this is the case (but I would love to be wrong...).  I beleve
>> the #clocks each insn takes is more like the 386, then the i486.
>
>If NeXTstep does busyloops using instruction timing, I don't want it no
>matter WHAT it looks like.

I had removed all the stuff about NeXTstep from the message.  I was just 
disputing the speed claim.  However it turns out that I am wrong.  Which is
nice (in this case).

I really doubt thare any hard timing loops, more likely to be a MMU diffrence.
-- 
           stripes@pix.com              "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.       - Larry Wall
From: YOUNG@tattoo.cs.widener.edu (Rob Young)
Newsgroups: comp.arch
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Date: 23 Dec 1992 20:31:07 GMT
Organization: Widener News/Mail Gateway
Distribution: world
NNTP-Posting-Host: tattoo.cs.widener.edu
X-News-Reader: VMS NEWS 1.20


In <id.OG2W.USA@ferranti.com> peter@ferranti.com writes:

> In article <1992Dec22.142358.188@indyvax.iupui.edu> imhw400@indyvax.iupui.edu writes:
> > > 	pipes
> > got it
> 
> $ DIR | SORT
> %DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters
> 

If you have the bucks you can purchase the POSIX shell for VMS.  It is
dog slow but works.  Of course if you are talking about an Alpha AXP box, who
cares??  Otherwise there are pipe packages available via anonymous FTP.

$ posix
psx> dcl directory/date/size | sort
sort: [standard input]: line 15: no newline at end of file




Directory DUA1:[T]
EXTRACT.BIN;1             7  17-NOV-1992 12:29:11.39
LIBRARY.BIN;68           49  23-DEC-1992 11:49:52.06
NOMENU.BIN;63            16  23-DEC-1992 11:51:53.51
PHOTO.LOG;1               0  23-DEC-1992 15:11:59.62
REPORTER.BIN;69          30  23-DEC-1992 11:50:38.25
SAVE.BIN;59              30  23-DEC-1992 11:46:50.42
SPANISH.BIN;2            59  22-FEB-1991 13:24:19.34
SYSTEM.BIN;3             57  23-DEC-1992 11:48:47.64
TTY.BIN;61               28  23-DEC-1992 11:51:16.64
Total of 9 files, 276 blocks.

> > > 	make
> > got it
> 
> When did that show up. I once spent a week writing make for VMS because it
> wasn't there.

Version 5.5.  Get the POSIX shell.  It has a good make.  Otherwise there are 
numerous *decent* makes available via anon ftp.

> > > 	choice of shells
> > got it
> 
> Damn, can't seem to find any but DCL.
> 

Get the POSIX shell.  I know, I know, "why should I have to pay extra???"  
It is available though at a modest cost.  (i.e. $185 for a MicroVAX II).

> > > 	machine independant, choice of vendor freedom
> > VMS runs on two architectures now, maybe more later
> 
> Doesn't run on my PC.

But it will run on a PC, may not be yours though.  DEC is working on the 
drivers to bring it down to the Alpha PC level.

> > > 	simplicity
> > got it
> 
> OK, quick, without looking it up. Is it
> 
> 	delete queue/entry=
> or
> 	delete entry/queue=

I avoid this by doing the following:

	$ delete/entry=???

The queue manager assigns unique entry numbers so it doesn't have to worry
about target queue anymore.  

You seem to be stuck at a prior version of VMS.  Like any robust operating 
system VMS has added new features, including the availability of a POSIX 
(kshell) shell at VMS 5.5.

Peter, since you now have to support a VMS machine(s) you aren't trying to 
learn VMS tricks/techniques by critiqueing it are you?

				Rob


                                                     young@tattoo.cs.widener.edu
"Even the street fighters over at Sun are concerned when they look at what's
happening with Windows.  They see the way the market works: The users are a
bunch of sheep, and Billy [Gates, Microsoft CEO] is the shepherd"
						-- Maureen O'Gara
						   Unigram-X editor
Newsgroups: comp.arch,comp.sys.intel
From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin)
Subject: Re: Superscalar vs. multiple CPUs ?
Organization: College of Marine Studies, U. Del.
Date: Wed, 23 Dec 1992 20:32:23 GMT

In article <Bzpzwq.18q@news.udel.edu> mccalpin@perelandra.cms.udel.edu (John D. McCalpin) writes:
>Although I don't think it was ever done, the world's fastest text
>editor could probably have been written for the ETA-10, which had a
>bewildering variety of instructions for copying and searching chunks of
>its bit-addressable memory at vector speeds.   The Cray machines could
>be competitive, but the lack of byte addressability makes working with
>text awkward and relatively slow.

I have been corrected on this last point by some friendly Cray-persons.
After hearing their explanations of how many of the C library string
handling routines have been vectorized, I still contend that it is
awkward, but now see that it need not be slow....
-- 
--
John D. McCalpin                        mccalpin@perelandra.cms.udel.edu
Assistant Professor                     mccalpin@brahms.udel.edu
College of Marine Studies, U. Del.      John.McCalpin@mvs.udel.edu
From: paul@taniwha.UUCP (Paul Campbell)
Newsgroups: comp.arch
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Date: 28 Dec 92 22:22:51 GMT
Organization: Taniwha Systems Design

In article <id.SQ3W.IB6@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <1992Dec23.212321.26522@ryn.mro4.dec.com> Peter.Mayne@cao.mts.dec.com writes:

>And in UNIX the analog is a "signal". Now, a signal is a little "safer" than
>an AST (at least as under RMX), in that it's guaranteed to run in your task
>context.

Well VMS user-mode ASTs run just like signals. Actually each AST runs in
it's tasks context - it's just that it's possible to create an AST for
another task. Not much use in user mode (ie like signals) but very usefull as
a kernel mechanism where you WANT something to happen in the context of
another process.

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)


>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. 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);


	Paul

-- 
Paul Campbell    UUCP: ..!mtxinu!taniwha!paul     AppleLink: CAMPBELL.P
"Finally after much thought he tied a dollar bill to the top of the tree, it
seemed to fit - after all it was the premier capitalist holiday, besides after
the 'fall' of communism a star didn't seem appropriate anymore ..."
Newsgroups: comp.arch
From: simon@mallard.edec.locus.com (simon R)
Subject: Re: AST on UNIX
Organization: Digital Equipment Corporation - Nashua, NH
X-Newsreader: Tin 1.1 PL4
Date: Mon, 28 Dec 1992 15:49:34 GMT

: >OK, try this. VMS has something called an AST (Asynchronous System Trap) which
: >is similar to a user-mode interrupt. This may occur at any time: for instance,
: >an asynchronous I/O can call an AST routine when the I/O completes. When the
: >AST routine completes, control returns to the code that was executing at the
: >time the AST occurred. (The analogy in NT is the APC, or Asynchronous
: >Procedure Call.)
: >
: >Now, much of the run-time stuff in UNIX is non-reentrant. In particular, the 
: >use of errno springs to mind. If the AST (or APC) was introduced into the
: >UNIX model, how can I use these non-reentrant routines safely in an AST
: 
: While you are at it, don't forget to include a separate 32-bit value
: passed to the AST.  The AST is fully queue'd, and if you send 32 ASTs
: before the application executes it's handler the application will still
: see ALL the ASTs with their separate 32-bit value.
: 
: If you can make this work, now port it to AIX, SunOS, Solaris, Ultrix,
: IRIX, and HP-UX.  Those are the only environments I currently would like
: it on, I'm sure there would be more within a few months.
: 
Concurrent Computer (for whom I used to work) have had AST capability
in their real-time version of Unix (based on System V) since (as
MASSCOMP) their first product shipped some ten years ago.
As I recall, error status of the I/O operation was indeed passed as a parameter
to the AST routine. It's major use was to overlap real time data input
with output to disk or whatever. ASTs could be prioritized, buffers 
locked in memory, everything that you needed to do real-time data collection.


_______________________________________________________________________________
Simon Rosenthal:  (simon@bos.locus.com)
Locus Computing Corporation
Burlington, MA 01803
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: wbeebe@bilver.uucp (Bill Beebe)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: W. J. Vermillion - Winter Park, FL
Date: Sat, 26 Dec 1992 00:18:27 GMT

In article <1992Dec20.164501.291@rlgsc.com> gezelter@rlgsc.com writes:
>In article <mcdonald.624@aries.scs.uiuc.edu>, mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:
 
>> The Unix way has proven to be the best way; its one of the biggest
>> reasons VMS is a current sales disaster.
>> 
>> The doc for your own ISAM is maybe 2 pages long.
>> 
>And the doc for each of the other ISAMs written because "mine is 
>better" is also two pages long, leading to thousands of pages of 
>documentation covering equivalent facilities with small 
>differences.

VMS is a sales disaster because the VAX is a sales disaster.
DEC has always maintained that its business is selling software. And
having lived and coded under both environments, I find that VMS is no
better or worse than Unix. Both require high performance hardware
to run adequately, both require lots of system resources to run
adequately, and both have equal numbers of vociferous bigots.

-- 
William H. Beebe, Jr. - wbeebe@bilver.UUCP
                 UUCP - {ucf-cs,peora,uunet}!tarpit!bilver!wbeebe
                      - bilver Public Access Unix, Orlando FL
                      - (407)644-8327  2400/9600  24 hours  8N1
Newsgroups: comp.arch,comp.sys.intel
From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin)
Subject: Re: Superscalar vs. multiple CPUs ?
Organization: College of Marine Studies, U. Del.
Date: Wed, 23 Dec 1992 16:17:13 GMT

In article <PCG.92Dec23144916@decb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>On 21 Dec 92 13:45:31 GMT, solman@athena.mit.edu (Jason W Solinsky) said:
>
>solman> At any rate, I would claim that improvements in processor
>solman> performance should only be concerned with apps which are
>solman> presently processor limited, and many of these general purpose
>solman> codes just aren't.
>
>Uhm, memory is so cheap that many "general purpose" applications
>nowadays can be made entirely core resident, and a core resident program
>is 100% CPU bound.  for example I see most compiles on my machine are
>CPU bound; except for reading in the source and writing out the code
>there is no IO activity whatsoever.

I disagree with this distinction.  A core resident program can be very
seriously *memory* bound if the processor is spending most of its time
locked down waiting for cache misses to be filled.   Many "cpu-bound"
programs spend half or more of their time in this state, and it is very
easy to accidentally build a program which spends 90% of its time
waiting for cache line refills.

Common applications such as text editting of large files (i.e. files
significantly larger than cache) could benefit considerably from
decreasing cache latency and would often benefit from having wider
memory-to-cache buses.

Although I don't think it was ever done, the world's fastest text
editor could probably have been written for the ETA-10, which had a
bewildering variety of instructions for copying and searching chunks of
its bit-addressable memory at vector speeds.   The Cray machines could
be competitive, but the lack of byte addressability makes working with
text awkward and relatively slow.
-- 
--
John D. McCalpin                        mccalpin@perelandra.cms.udel.edu
Assistant Professor                     mccalpin@brahms.udel.edu
College of Marine Studies, U. Del.      John.McCalpin@mvs.udel.edu
Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: Xenix Support, FICC
Date: Wed, 23 Dec 1992 16:23:38 GMT

In article <1992Dec22.142358.188@indyvax.iupui.edu> imhw400@indyvax.iupui.edu writes:
> > 	pipes
> got it

$ DIR | SORT
%DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters

> > 	make
> got it

When did that show up. I once spent a week writing make for VMS because it
wasn't there.

> > 	transparent networking
> Hahahahaha.  Got it.  Had it years earlier.
> > 	network file sharing
> got it

You mean, like you have to put your login name and password in the file
name, in quotes, to access files on a remote system. Nice security
feature. Ever hear of shoulder-surfing?

> > 	choice of shells
> got it

Damn, can't seem to find any but DCL.

> > 	machine independant, choice of vendor freedom
> VMS runs on two architectures now, maybe more later

Doesn't run on my PC.

> > 	simplicity
> got it

OK, quick, without looking it up. Is it

	delete queue/entry=
or
	delete entry/queue=
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
From: n303bn@tamsun.tamu.edu (Jason Rosson)
Newsgroups: comp.sys.sgi
Subject: CDROM Problems
Date: 21 Dec 1992 22:25:27 -0600
Organization: Texas A&M University, College Station, TX
Distribution: world
NNTP-Posting-Host: tamsun.tamu.edu

  I've got a problem with a CDROM and an Indigo Elan.  The drive is a
 Texel DM-3024 Internal drive, it's SCSI-2 compatible.  My kernel got
 corrupted and I'm trying to reinstall IRIX 4.0.4, the only one I've
 presently got.  I hit <Esc> to perform system maintenance.  Then
 use option 2 : Install System Software.  At this point the
 problem occurs :

  dks0d3s8: Drive not ready
  error on vh read
  dksc(0,3,8)sashIP12: is not a bootable file
  Unable to load dksc(0,3,8)sashIP12: no such device

 I also tried using option 5 : Enter Command Monitor.  I then boot to
 the sash on dksc(0,1,8) (I assume that's where it's booting from), and
 use the install command.  I get this :

  Copying installation program to disk
  dks0d3s8: SCSI driver error 1
  efs read error, bad count
  dks0d3s8 Drive not ready: Medium not present
  error on vh read
  Read failed, offset = 0x0

 I'm fairly certain the cable I made works ok, hinv reports the CDROM
 being present and a 1/4" QIC drive (which I don't have the correct
 tapes for) that I borrowed from a friend reads just fine.  I once had
 the opportunity to use a CDROM drive from SGI (when I first installed)
 and it worked like a charm.  My question is, is there something special
 about SGI's drive that allows it to work ok, but not my Texel?  Thanks
 for any help, I desparately need it!

 - Jason
   n303bn@tamsun.tamu.edu
Newsgroups: comp.sys.sgi
From: Philip Machanick <philip@concave.cs.wits.ac.za>
Subject: new groups?
X-Xxdate: Wed, 23 Dec 92 11:55:51 GMT
Organization: Computer Science Dept, Wits University
X-Useragent: Nuntius v1.1.1d12
Date: Wed, 23 Dec 1992 10:02:00 GMT

So far only comp.sys.sgi.admin has reached this site. How many other
new groups should I be looking out for?
--
Philip Machanick
Computer Science Dept, Univ of the Witwatersrand, 2050 Wits, South Africa
philip@concave.cs.wits.ac.za  phone: 27 (11) 716-3759  fax: 339-7965
Newsgroups: comp.sys.sgi
From: ib@ivan.asd.sgi.com (Ivan Bach)
Subject: Re: How to Determine Model
Keywords: SGI, model, getinvent 
Organization: Silicon Graphics, Inc., Mountain View, CA
Date: Fri, 1 Jan 1993 16:40:19 GMT

In article <AJ3U.93Jan1102020@larch.cs.virginia.edu> aj3u@larch.cs.virginia.edu
(Asim Jalis) writes:
> Is there a way to determine online what the version of my SGI
> machine is?
If by 'online' you mean within a program, your program can call getinvent
to get information on hardware, and it can call getgdesc to get information
on graphics.  

You can use commands such as:

    hinv
    /usr/gfx/gfxinfo
    xdpyinfo
    uname -a

to display the information about hardware and graphics on your SGI machines.
The command uname can be used to display, among other things, the type of CPU
board installed in your SGI machine, such as IP6.

Ivan Bach, ib@sgi.com
From: ies@access.mbnet.mb.ca (Integrated Engineering Software)
Subject: My recent posting regarding SGI support...
Organization: University of Manitoba, Winnipeg, Canada
Date: Thu, 31 Dec 1992 21:17:03 GMT

Hi,
    In a recent posting a few days back I vented my
    frustration at the support staff of SGI not 
    not having sent me(us) an invoice to upgrade to 4.0.5.

    As part of the maintainence I received the upgrade
    yesterday for Irix 4.0.5F. I am thankfull to the SGI
    staff for it and consider the issue closed.



Thanks

Girish
IES
From: did@kepler.unh.edu (Dusan I Dragovic)
Newsgroups: comp.sys.sgi
Subject: WANTED IRIS INDIGO 33MHz
Date: 28 Dec 1992 04:23:55 GMT
Organization: University of New Hampshire  -  Durham, NH
Distribution: USA
NNTP-Posting-Host: kepler.unh.edu


Newsgroups: comp.sys.sgi
From: senseman@ricky.brainlab.utsa.edu (David M. Senseman)
Subject: UNIX vs NT
Organization: University of Texas at San Antonio
Date: Thu, 31 Dec 1992 21:23:46 GMT

Forget VMS vs UNIX -- VMS is a dying a slow painful dead (like Digital)
so who cares if it's good or bad. Dead is dead.

The REAL competition in the 1990's will be Windows NT vs UNIX.
What makes this very interesting is that Novell has just offered
to buy USL (Unix System Labs) for $350 M. 

In the real world (=business world) Novell is the de facto network
operating system. Now that Novell has bought USL, maybe UNIX
can finally make serious inroads in the business sector. If
SGI plays its cards right, maybe every secretary in the Western
Hemisphere will be able to play Battlezone during coffee breaks :-)

What I would like to know is what direct effect, if any, does Novell
buying USL have on future incarnations of IRIX? Does SGI license
UNIX from USL or from At&T?

Thanks and Happy New Year!



-- 
David M. Senseman, Ph.D.     | A man who has never gone to school may steal 
(senseman@lonestar.utsa.edu) | from a freight car; but if he has a university
Division of Life Sciences    | education, he may steal the whole railroad.
UT San Antonio               |             Theodore Roosevelt (1858-1919)
From: clarke.stevens@gtri.gatech.edu (Clarke Stevens)
Newsgroups: comp.sys.sgi
Subject: FAX software for SGI
Date: 1 Jan 93 23:28:43 GMT
Followup-To: comp.sys.sgi
Organization: GTRI/AERO

Does anyone know of some good FAX software for the SGI?  I would prefer
something GUI-based that can send graphics or text.  Shareware/PD or
regular software is fine.  I'm just looking for a solution.

Thanks in advance,
Clarke

------------------------------------------------------------------
J. Clarke Stevens               |  Georgia Tech Research Institute
clarke.stevens@gtri.gatech.edu  |  (404) 528-3254
Newsgroups: comp.sys.sgi