HDTenEightyP/NetNews huggingface dataset:
From: craigdo@microsoft.com (Craig Dowell)
Subject: Yanks vs. Brits
Date: 17 Dec 92 23:45:09 GMT
Organization: Microsoft Corporation

In article <1992Dec16.171133.2856@lsl.co.uk> snail@lsl.co.uk writes:
>The above aside, I'm always puzzled as to how the American date convention
>started: Mont/Day/Year is neither LSB or MSB, where as Day/Month/Year and
>Year/Month/Day have obvious reasoning behind them.

Here we go again ...
From: masticol@cadenza.rutgers.edu (Steve Masticola)
Newsgroups: comp.arch
Subject: RISC assemblers question
Date: 17 Dec 92 15:16:37 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

Hi,

I've met a couple of people who have attempted to write assemblers for
RISC machines, who say that it's a difficult job. Can someone give me
an inkling as to why?

I'm not saying that it isn't; the reason just isn't obvious to me
right now.

Thanks,
- Steve (masticol@cs.rutgers.edu).
Newsgroups: comp.arch
From: stripes@pix.com (Josh Osborne)
Subject: Re: RISC assemblers question
Organization: Pix Technologies -- The company with no adult supervision
Date: Sat, 19 Dec 1992 00:19:06 GMT

In article <lj2h6hINNikj@exodus.Eng.Sun.COM> nand@not-and.Eng.Sun.COM writes:
[...]
>A couple of things make it a *little* harder :
>
>1) Branches with delay slots (you have to be able to represent them and
>   deal with them).

If the assembler isn't attempting to re-order code then it doesn't need
to know about this (except for #4).

>2) In general, chip workarounds are done in the assembler, and this code
>   is just yuckier to deal with

I don't know.  I think it is yucker to deal with
MOVE.L D0,(A0+D1*4+12)		# Sort of a 68020 instruction
(move D0 to Mem[A0 + D1*4 + 12], and worse addressing modes exist!)
Or the fact that ADD AX,anything is diffrent from ADD (non-AX-reg),anything.
And that only some addressing modes are available on some OPs.

Or at least about as yucky.

>3) branches have limited scope (on SPARC, you get only 22 bits in the branch
>   instruction). It is reasonable to leave a check in the assembler to detect
>   branches to targets that are larger than the displacement will allow.

Branches on most boxes have limited scope.  However JUMPs and CALLs on
RISCs have limited scope (for the immediate mode instructions) if you need to
deal with external linkage then this could be a problem.  If not it is no
harder then the Bcc OPs on the 680x0 (or 6502!).

>4) Code to check architectural correctness (try doing something illegal
>   with the SPARC assembler - if it sqawks, then someone had to write the code 
>   to do the check). This is very important, because the machine will not always
>   execute "arbitrary assembly language". 

Yes, but it is also hard for CISC assemblers to support a whole family of
similar CPUs (68020 has more addressing modes then the 68000, the 80386
supports WAY more instructions in 32bit mode then the 8086...).  However I
think the CISC assemblers do this easyer then RISCs do #4.

>There may be others, these are the only ones that come to mind right now. 

Could be, however I think that unless you try to make the RISC assembler
optimise they are both about as hard to write (and if you make the CISC
assembler opt. also, then I don't know which is simpler!).
[...]
-- 
           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
Newsgroups: comp.arch
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: IBM AS/400 is the world's slowest computer
Date: Sun, 20 Dec 1992 23:55:19 GMT
Organization: University of Iowa, Iowa City, IA, USA

From article <1992Dec18.165950.15013@webo.dg.com>,
by lewine@cheshirecat.webo.dg.com (Donald A. Lewine):
> 
> 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.
> 
> 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.

1) As IBM has known since the 1950's, it isn't technology that sells, it's
    salesmanship.

2) The AS400 runs RPGII.  I don't care about RPG, you probably don't care
    about RPG, but there are some big important applications that use it.

3) The AS400 is a capability based tagged architecture.  It offers security
    like nothing else on the market.  That's not to say that it's perfect,
    but while all us RISCy folks have been off worrying about MIPS, IBM has
    noticed that tools providing incredibly tight control over access to
    information are crucial in many markets.  Try writing an AS400 virus!

					Doug Jones
					jones@cs.uiowa.edu
From: jackc@vermont.mti.sgi.com (Jack Choquette)
Newsgroups: comp.arch
Subject: Re: Any use for Branch if Even/Odd ?
Date: 11 Dec 92 20:12:25 GMT
Organization: Mips Technologies, Inc.
NNTP-Posting-Host: vermont.mti.sgi.com

In article <GJR.92Dec10233620@chamarti.ai.mit.edu>, gjr@zurich.ai.mit.edu (Guillermo J. Rozas) writes:
|> In article <1g8ub1INN8it@agate.berkeley.edu> jbuck@forney.berkeley.edu (Joe Buck) writes:
|> 
|> |   From: jbuck@forney.berkeley.edu (Joe Buck)
|> |   Newsgroups: comp.arch
|> |   Date: 11 Dec 1992 02:27:45 GMT
|> |
|> |   They are used heavily in VMS, since it encodes error status returns
|> |   that way (the LSB determines whether there is an error or not).  The
|> |   Vax had an instruction that could do this, so so must the Alpha for
|> |   efficient VMS implementatation.
|> 
|> Isn't this in fact how booleans are represented in BLISS, the language
|> in which a lot of VMS was/is written?


Since many programs use boolean variables for control flow but use integers
as the boolean variable, I could see how this could be useful.  However,
if a int value is being used as a single boolean variable it would make
more sense to use/have an instruction like branch on zero.  It's more general
purpose and useful.  You can use it to test boolean values as well as
count down (to zero) loops.

/jack
From: haddad@pa.dec.com (Ramsey Haddad)
Newsgroups: comp.arch
Subject: Re: Any use for Branch if Even/Odd ?
Date: 15 Dec 1992 22:50:48 GMT
Organization: DEC Western Research Lab, Palo Alto, CA
NNTP-Posting-Host: haddad.pa.dec.com

In article <1992Dec14.203631.16388@CSD-NewsHost.Stanford.EDU> andy@SAIL.Stanford.EDU (Andy Freeman) writes:
>Does anyone know why they preferred even/odd to >=0/<0?  Sometimes one
>has to test the sign bit, so why not use it whenever one can use any
>bit to split things into two classes?

The Alpha AXP architecture has 8 different conditional branches:
 BEQ:  Branch if Register Equal To Zero
 BGE:  Branch if Register Greater Than or Equal To Zero
 BGT:  Branch if Register Greater Than Zero
 BLBC: Branch if Register Low Bit Is Clear
 BLBS: Branch if Register Low Bit Is Set
 BLE:  Branch if Register Less Than or Equal To Zero
 BLT:  Branch if Register Less Than Zero
 BNE:  Branch if Register Not Equal to Zero

These same 8 conditions are available for conditional move instructions.

-- 
Ramsey Haddad <haddad@decwrl.dec.com>
speaking for myself.
Newsgroups: comp.arch
From: dhd@exnet.co.uk (Damon)
Subject: Re: <None>
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Sun, 13 Dec 1992 00:25:22 GMT

In article <1992Dec9.193616.2813@lsl.co.uk> snail@lsl.co.uk writes:
>So: Where can you get hardware that runs SunOS?

Cray Superservers?
Thinking Machines (thinly disguised)?
Solbourne?
Hyundai/Axil?

etc

Or am I missing a point here?
-- 
Damon Hart-Davis                          Internet: dhd@exnet.co.uk, d@hd.org

Public-access UNIX (Suns), news and mail for UK#5 per month.  FIRST MONTH FREE.
[1.35] Cheap Sun eqpt.  UUCP news/mail feeds.  Tel/Fax: +44 81 755 0077.
From: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: comp.arch
Subject: Whatever happened to govt. std. peripheral interface?
Date: 11 Dec 1992 19:12:02 GMT
Organization: University of California; Santa Cruz
Distribution: na
NNTP-Posting-Host: hobbes.ucsc.edu


I remember some years ago the U.S. govt. was getting set to require all
vendors selling to the government to use a standard peripheral interface
so they could have competition in the peripherals market.  The standard
was going to be the IBM channel-to-control-unit interface because there was
already competition in peripherals for IBM 360 systems.  The other
mainframe makers were against it because (a) they didn't want competition,
wanted to keep their proprietary interfaces, (b) they didn't want to redesign
products to use a different interface, (c) they thought their own interfaces
were better (like not being limited to 8 bits wide).  The minicomputer makers
didn't like it because it was very costly to implement, compared to what
they were offering.  Even IBM didn't want it (a) because they wanted to
be able to change the interface to thwart the plug-compatible peripheral
vendors, and (b) because they didn't want to be bound to an interface
that was showing its age even at the time.

Whatever happened - did the standardization effort die from lack of 
support?  Or was it enacted and then so many exemptions were given
that it became meaningless?
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Ya can argue all ya wanna, but it's dif'rent than it was!"
"No it aint!  But ya gotta know the territory!"
        Meredith Willson: "The Music Man"
From: tdbear@dvorak.amd.com (Thomas D. Barrett)
Newsgroups: comp.arch
Subject: Re: Heat Output of New uPs
Date: 17 Dec 92 14:36:30 GMT
Organization: Advanced Micro Devices, Inc.; Austin, Texas

For some of the new processor chips with those neat looking heatsinks
on top, I'd like to design a desktop which actually has the heatsink
protruding out the top... I could then design a small heat conductive
spill guard and have a nice coffee warmer!

Tom
-- 
| Tom Barrett (TDBear), Sr. Engineer | tom.barrett@amd.com
| AMD PCD / Austin, TX  78741        | v:512-462-6856 / f:512-462-5155
| "No is Yes, and We are All FREE!"  | CO made a #2 no-no... PU!
| My views may not be shared by the organization of origin
From: akhiani@ricks.enet.dec.com (Homayoon Akhiani)
Newsgroups: comp.arch
Subject: Re: RISC assemblers question
Date: 17 Dec 92 21:38:12 GMT
Reply-To: akhiani@ricks.enet.dec.com (Homayoon Akhiani)
Organization: Digital Equipment Corporation


|>
|>masticol@cadenza.rutgers.edu (Steve Masticola) writes:
|>: Hi,
|>: 
|>: I've met a couple of people who have attempted to write assemblers for
|>: RISC machines, who say that it's a difficult job. Can someone give me
|>: an inkling as to why?
|>: 
|>: I'm not saying that it isn't; the reason just isn't obvious to me
|>: right now.
|>: 
|>: Thanks,
|>: - Steve (masticol@cs.rutgers.edu).
|>

To give you an example,
You might want to look at gatekeeper.dec.com /pub/DEC/Alpha/assembler/
There are sources and user guide for an AlphaAxp assembler/Linker.
-done by 2 engineer in a week. 
-Written in protable C 
(meaning the source will compile on PC(GNU C),Mac(THINK C), Mips, Sun, VAX
these are the platforms that we had access to check the protability).

As one of the authors of this assembler, I can assure you that if the 
machine architecture is free from "goofy-ness", writing one is a basic 
programming excercise.
Actually, if you look at the sources you might be able to retarget it to any
other 32bit instruction size architecture.

--
-------------------------------------------------------------------------------
Homayoon Akhiani                               "Turning Ideas into ... Reality"
Digital Equipment Corporation                        "Alpha, The New Beginning"
77 Reed Rd. Hudson, MA 01701            "All Rights Reserved. Copyright(c)1992"
Email: akhiani@ricks.enet.dec.com     "The words are mine, and not my employer"
-------------------------------------------------------------------------------
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.arch
Subject: Re: Any new instructions in a i486?
Date: 14 Dec 92 05:23:42 GMT
Article-I.D.: iecc.9212140023.AA22331
Organization: I.E.C.C.

>Did the '386 have a TLB?

Of course.  You think it looks up every virtual address in a page table in
main memory?

The 386 data sheet says that the TLB is 32 entries, four-way associative.
The 486's TLB is similar but with a cleverer replacement strategy.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl
From: zeke@fasttech.com (Bohdan Tashchuk)
Newsgroups: comp.arch
Subject: Re: Any new instructions in a i486?
Date: 14 Dec 92 13:41:09 GMT
Article-I.D.: fasttech.1992Dec14.134109.3367
Organization: Fast Technology

>>NeXTStep is said to not run on the Cyrix 486 chips because "they are
>>not real 486's".  No one has come up with a reliable reason _why_ NeXT
>>doesn't think they are "real 486's" or why NeXTStep won't run on them.

>I don't have any real data, but I expect the problem is that the Cyrix
>chip doesn't have a floating point unit.  Next's own systems have all
>had standard FPUs, and reviews of NeXTStep say that it won't run on a
>486SX, only a DX.

A 10/21/92 semi-official net posting on NextStep claims it runs on SXs:

   General Requirements:
   CPU - 486 based PC Compatible Computer. This includes 486SX, 486DX,
   486DX/2. Future Intel Microprocessor designs in the x86 family will
   also be supported. ISA or EISA expansion bus. 486DX and 486DX/2's are
   recommended for better performance.

   Will NeXTSTEP 486 run on the Cyrix 486SLC?
   No. The Cyrix chip not a true 486.

I asked for an explanation of "true 486" in comp.sys.intel. A Next person
seemed to imply that Next didn't want to bother resolving the supervisor
state differences between the chips. Nothing very convincing. I had a theory
involving "arrogant propeller-heads", but the Next person didn't agree with it.

My guess is that NextStep is sluggish enough that Next saw no reason to bother
with the Cyrix parts, which are lower performance than Intel 486?Xs.

I've also seen Intel apologists and employees repeat the "not a 486" claim in
various groups. They've succeeded admirably in their primary goal, which is
to sow Fear, Uncertainty, and Doubt as widely as they can. What I haven't seen
yet is an explanation. I'll ask the question again here:

	Please tell me exactly WHY the Cyrix isn't a 486? What is it that
	Intel feels is the essence of a 486?

	Let me say a priori that a response of "made or licensed by Intel"
	isn't sufficient in and of itself.
Xref: sparky comp.arch.storage:852 comp.periphs:1659
From: dtb@adpgate.UUCP (Tom Beach)
Newsgroups: comp.arch.storage,comp.periphs
Subject: Need information on mainframe disks...
Date: 11 Dec 92 20:20:57 GMT
Article-I.D.: treyvan.1797
Followup-To: comp.arch.storage
Organization: ADP Dealer Services R&D, Portland, OR


I'm looking for information on a disk system. 

All I know about it is:

	It's marketed under the name "symmetrix" (spelling ?)
	It's made by a "relatively small new england co."
	It works in a mainframe (IBM) environment.
	The description sounds as though it's a RAID product with
		an IBM I/O channel interface.

Can anyone give me either additional information, a contact for the
manufacturer, or both....

You may either post to this newsgroup or mail to me at address in .sig.

Thanks folks!!

Tom B

 -------------------------------------------------------------------------
|  Tom Beach    :   Sr. Engineer   :     Mass Storage Technology          |
|  ADP Dealer Services                                                    |
|  2525 S.W. 1st Ave.                    phone : (503) 294-1541           |
|  Portland OR, 97201                    email : adpgate!dtb@apple.com    |
 -------------------------------------------------------------------------
Newsgroups: comp.arch.storage
From: zubla@shc.uiowa.edu (Samuel Spade)
Subject: Dual DOS/UNIX tape backup
Date: Tue, 15 Dec 92 1:15:32 CST
X-Received: by usenet.pa.dec.com; id AA03974; Mon, 14 Dec 92 23:15:35 -0800
X-Received: by inet-gw-2.pa.dec.com; id AA07177; Mon, 14 Dec 92 23:15:34 -0800
X-Received: by forte.shc.uiowa.edu (5.57/Ultrix3.0-C)
	id AA13753; Tue, 15 Dec 92 01:15:32 -0600
X-To: comp.arch.storage.usenet
X-Mailer: ELM [version 2.3 PL11]


    I am looking for a backup system that will work for a dual boot DOS/UNIX
i486 pc clone.  This is for my home/school computer, so money is a constraint.
    My machine currently has:
A: 5.25" floppy
B: 3.5"  floppy
C: 40M IDE HD
DOS 5.0, Windows 3.1.  Interactive UNIX in the near future (I hope).

    When I was just using DOS, I was going to purchase a Colorado Memory
Systems Jumbo 120.  Now that I am thinking about installing some brand of
UNIX, I am not so sure that this is a good idea.  The Jumbo 120 ties into
the B: wires somehow.  I do not know if this will work with UNIX, device
drivers, backup software, etc.

    Several people have suggested QIC-02 tape to me.  I've talked this over
with friends who are in charge of university UNIX systems.  They said that,
yes, they do use QIC-02, but wish they had not.  At two seperate sites this
type of backup has overwritten the boot sector on the harddisk.  This is not
a backup feature that I want.  I was told more exact information about one of
the sites.  It uses a Wangtek 60M tape drive.

    The above is the limit of my knowledge in this area.  I never had money
for backups before.  This costs me six weeks in February and March while I
slowly reconstructed FAT tables.  A pleasure everyone can do without.

Oh, yes - I have been considering switching/adding SCSI.  One of my systems
friends says that this will not help my tape backup problem.  He stated that,
sure, SCSI is supposed to be able to handle 7 devices, but that almost every
manufacturer implements SCSI in a slightly different way.  So I should not
think that I will automatically end up with a controller that will drive a
HD and a tape drive.  In any case, SCSI is not a driving factor in my decision
making process - it is just another option.  (Obviously I need more space
for UNIX.  I'm just trying to decide if I should make my next HD a SCSI - if
I can stand the financial pain).

    I would like some advice on brands to look for.  Also any advice or
comments you care to share.  I'm lost without your help.  Thanks!
Newsgroups: comp.arch.storage
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: Hard Disk Mirroring
Organization: Keith's Computer, Hope Mills, NC
Date: Sun, 20 Dec 92 22:27:52 GMT

In article <BzH9FJ.Ep3@dale.cts.com> ghamlin@dale.cts.com (Garrett Hamlin) writes:
> 
>
>Does anybody know a quick and easy (or even slow and difficult) way to "mirror"
> two large hard drives (either SCSI or IDE) on a Novell fileserver?  The idea 
>is to have a constantly updated backup copy of frequently changing data.  
>Surely there is a number of vendors with solutions to this seemingly simple 
>problem.  Thanks in advance for any advice!
>

Mirroring is built into Novell 3.1.  Upgrade.

Alternately buy a mirroring controller, like the DPT SmartCache Stuff.
-- 
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
Newsgroups: comp.arch.storage
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: Query: Solid State SCSI Systems 
Organization: Keith's Computer, Hope Mills, NC
Date: Thu, 17 Dec 92 03:59:09 GMT

In article <1992Dec1.151630.12076@nntpd.lkg.dec.com> cassidy@memory.enet.dec.com writes:
>|>So what is the average COST/MB on these guys, and where does it
>|>start?
>Evaluation units are $13,500 for the ESP510 (107 MB with integrated data
>retention = $126/MB) and $20,000 for the ESP530 (267 MB with no data retention
>= $75/MB).  Evaluation units will be available in Q1CY93.

[ Dist discounts up to 1/2 possible ... ]

Hmm, With a screamer Mag disk running around $2-3 a meg and this guy
maybe around $50-100 your application is gonna really have to demand Ultra
High speed disk memory to use it...  Of course with the way memory
prices go pricing could drop,  Also with cheap CPU's capable of addressing
Gigs now, and Terabytes in the near future, I'm not sure of the
viability of this technology,  Would seem more prudent to stuff the RAM
on the BUS (or BUSes) directly.  I dunno.
-- 
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
Newsgroups:  comp.arch.storage
From: k202002@tide.DKRZ-Hamburg.DE (Hartmut Fichtel)
Subject: Second UniTree Users' Group Meeting & Symposia.
Organization: Deutsches Klimarechenzentrum GmbH, Hamburg
Date: Mon, 14 Dec 92 11:04:11 GMT

The second UniTree Users' Group Meeting and Symposia will be held in
Hamburg, Germany hosted by DKRZ from March 2-3, 1993.  This message is 
being sent as a first announcement for interested participants and as 
a final call for speakers. 
 
Please reply to "uug@sandia.gov" if you are interested in participation. 
A second announcement will be sent out until Jan 25, 1993 with the meeting 
agenda and hotel information.  There will be no registration fee.
 
We are looking for speakers from installed UniTree sites and vendors 
to present their status.  In addition, we are soliciting talks on 
UniTree-related topics. Please reply to "uug@sandia.gov" if you are
interested to give a UniTree site report or other UniTree related
presentation not later than Jan 11, 1993. A very short abstract (a few
sentences) of the proposed talk would be appreciated.
  
The format of the meeting will be the same as the first meeting that
was held in Baltimore in September 1992.  That would be:
 
 
 Tuesday, March 2, 1993:
  
 * Status Presentations by each represented UniTree site
  
 * Vendor/Developer Presentations
 
  
 Wednesday, March 3, 1993:
  
 * Prepared Presentations on UniTree-Related Topics
  
 * Discussion of Issues
  
 * Business Section for UniTree sites only
  
 
Two other events are being planned around this Symposia.  On Monday,
March 1, 1993, there will be a Mass Storage tutorial with a UniTree 
overview. Speakers for this tutorial will be Dr. Sam Coleman of
Lawrence Livermore National Laboratory and Mike Hardy of DISCOS. There
will be no registration fee for this tutorial. Please indicate with
your registration reply to "uug@sandia.gov" if you wish to attend the 
tutorial.  

On Thursday and Friday, March 4-5, 1993 DISCOS is planning to offer 
a UniTree System administration class. Contact Brenda German of DISCOS 
directly at

  Mail:    Brenda German
           DISCOS, M/S 09-015
           POB 85608
           San Diego, CA 92186-9784 
  Email:   germanb@sds.sdsc.edu 
  Phone:   1-800-347-2678
  Fax:     1-619-455-3795 

for detailed class information including tuition costs.




|--------------------------------|-------------------------------------|
| Hartmut Fichtel                | email:  fichtel@dkrz-hamburg.dbp.de | 
| Deutsches Klima-Rechenzentrum  | Tel. :   49 40 41173 220            |
| Bundesstr. 55                  | Fax  :   49 40 41173 270            |
| D-2000 Hamburg 13              | Telex:   211092 (mpime d)           |
|--------------------------------|-------------------------------------|
Xref: sparky comp.arch.storage:860 comp.periphs.scsi:6101