HDTenEightyP/NetNews huggingface dataset:
From: craigdo@microsoft.com (Craig Dowell)
Subject: Re: big + little endian (was: Comparison of Alpha, MIPS ..)
Date: 05 Jan 93 20:30:58 GMT
Organization: Microsoft Corporation

In article <markg.79.726169747@county.lmt.mn.org> markg@county.lmt.mn.org (Mark Gilbert) writes:
>I have identified the root of this whole big-endian/little-endian debate.  
>The conflict is is between text and numbers.  We read left to right.  But, 
>if you were to number the digits of an integer, you would do it right to 
>left.  The one's digit would be 0, the ten's digit, 1, etc.
>
>This should never have been the case.  We adopted our number system from the 
>Arabs, and the Arabs read right to left.  For them, the direction of reading 
>text and numbers is CONSISTENT.  The whole problem arose because we failed 
>to reverse the numbering system when we borrowed it from the Arabs.
>
>I propose that we now correct this historical oversight.  Let us write 
>numbers least significant digit first.  The bang symbol can be used to 
>replace the decimal point, in order to distinguish little-endian numbers 
>from big-endian.  The integer six hundred and fifty four should now be 
>written !456.  Sixteen dollars and twenty five cents is now $ 52!61.

I never know if they're serious or not.  Is this post missing a giant
smiley at the end?  The problem is not of inconsistency and the fact that
ones processor of choice is little endian (inconsistent if viewed as
sub-units L->R), its that the processor is right and the conventions of 
western language and mathematics are wrong?

-- Craig

(3991, 5 naJ) or is it (3991, 5 Jan) or is it (9193, 5 anJ)
From: tve@crackle.CS.Berkeley.EDU (Thorsten von Eicken)
Newsgroups: comp.arch
Subject: Re: FP-number cache? Unclocked VLSI design.
Date: 6 Jan 1993 01:55:20 GMT
Organization: University of California, Berkeley
NNTP-Posting-Host: crackle.cs.berkeley.edu

In article <1993Jan5.212451.23482@twisto.eng.hou.compaq.com> tipley@solo.eng.hou.compaq.com (Roger Tipley) writes:
>In article <1993Jan5.170446.15655@Princeton.EDU> awolfe@moo.Princeton.EDU (Andrew Wolfe) writes:
>My bookshelf has many ACM SIGARCH Computer Architecture News publications.
>They all have papers published in them, and 
>most of them have so few articles it makes me wonder why I subscribe to it.  I
>would lay odds that that publication would relish a whole host of "failure 
>stories", if for no other reason than to justify its existence and make it
>more interesting to read.

You should probably just throw them into the trash can :-) (after reading!)

I have stopped reading these papers. Almost all of them are of such a
low quality that it's simply not worth my time. If they were better,
they would appear in one of the good conferences, journals or
magazines.  I am very happy that the SIGARCH CAN have become slimmer
over the last year or so, rememeber: pages cost money! I think that the
role of the CAN should be to publish things which don't fit into other
media: news about SIGARCH, announcements, and things which simply have
no other forum. For examples, take a look at the SIGPLAN notices which
publish language manuals, bibliographies, netnews digests (yes, CAN
does as well). What's the point of publishing technical papers which
should have either appeared in a reviewed forum or landed in the
trash?
	Thorsten von Eicken
From: jgj@ssd.csd.harris.com (Jeff Jackson)
Newsgroups: comp.arch
Subject: Re: big + little endian (was: Comparison of Alpha, MIPS ..)
Date: 8 Jan 93 13:00:52
Organization: I would rather be windsurfing.
	<3623363@zl2tnm.gen.nz><WAYNE.92Dec30093950@backbone.uucp><markg.79.726169747@
	county.lmt.mn.org>
	<1993Jan6.171242.2895@lsl.co.uk><RABIN.93Jan7132015@nuthatch.CS.Yale.Edu>
	<FY.93Jan7111925@hardwick.lucid.com>
	<CARLTON.93Jan7171924@scws1.harvard.edu>
NNTP-Posting-Host: rcx1.ssd.csd.harris.com
In-reply-to: carlton@scws1.harvard.edu's message of 7 Jan 93 17:19:24

> > Of course, how were numbers done in ancient Greek.  It was written in
> > boustrophedon:  the lines alternated left-to-right and right-to-left.
>
> Some rather old writings were written boustrophedon, but I wouldn't
> present it as the norm.

Order of the line wouldn't have mattered.  They didn't use positional
notation.  Instead (I'm using roman leters here for convenience) they
use letters for numbers thusly:

     a=1      j=10     s=100
     b=2      k=20     t
     c=3      l=30     u
     d=4      m=40     v
     e=5      n=50     w
     f=6      o=60     x
     g=7      p=70     y
     h=8      q=80     z
     i=9      r=90     %=900

What they did for bigger numbers I don't know.

--
============================================================================
Jeffrey Glen Jackson  _|_Satan jeered, "You're dead meat Jesus, I'm gonna
jgj@ssd.csd.harris.com |     bust you up tonight."
x5120                  | Jesus said, "Go ahead, make my day."
                   ~~~~~~~~~ -- Carman, "The Champion"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
My parents gave me a cold for Christmas.  What did you get?
From: snail@lsl.co.uk
Newsgroups: comp.arch
Subject: Re: Def of a workstation (a lark)
Date: 7 Jan 93 11:23:00 GMT
Organization: Laser-Scan Ltd., Cambridge

In article <id.16HW.512@ferranti.com>, peter@ferranti.com (peter da silva) writes:
> In article <1iarmrINNk28@news.cerf.net> davsmith@nic.cerf.net (David Smith) writes:
>> 1. You don't send Bill Gates any money when you buy a workstation
> 
> Check your list of copyrights on Solaris. It's based on System V, and System
> V includes Xenix code.

Exactly, you don't send Bill Gates money if you use a workstation... (think
about it). (hint: it's a :-) ).
-- 
snail@lsl.co.uk      

"Washing one's hands of the conflict between the powerful and the powerless
 means to side with the powerful, not to be Neutral."
                                                     Quote by Freire.
                                                     Poster by OXFAM.
From: jackc@vermont.mti.sgi.com (Jack Choquette)
Newsgroups: comp.arch
Subject: Re: A theory for Big & Little Endian's origin
Date: 8 Jan 93 17:48:46 GMT
Organization: Silicon Graphics, Inc.
NNTP-Posting-Host: vermont.mti.sgi.com

In article <1iinltINNi0l@darkstar.UCSC.EDU>, haynes@cats.ucsc.edu (Jim Haynes) writes:
|> 
|> In article <1iig7aINNtc@spim.mti.sgi.com> jackc@vermont.mti.sgi.com (Jack Choquette) writes:
|> >For reasons explained in previous posts, humans (who read left to right)
|> Well, now, some of them do and some of them don't.  How about Big Endian
|> for the West, and Little Endian for the East (starting at Israel and
|> the Arab nations and going to Japan)
|> -- 
|> haynes@cats.ucsc.edu
|> haynes@cats.bitnet
|> 
|> "Ya can talk 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"

You are correct about all humans not reading left to right.  I should have
said the humans who were developing and building those computers read left
to right.

As for Endianess matching the way cultures read, you may be partially correct.
I don't know the prefered Endianess in the computers used in those foreign
nations.  However that wouldn't explain why computers in western countries
use both Big and Little Endian, computers that were developed for western 
markets that read left to right.

/jack
Newsgroups: comp.arch
From: othman@ntrc25.ntrc.ntu.ac.sg (othman (EEE/Div 4))
Subject: branch prediction vs loop
Organization: Nanyang Technological University - Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Mon, 11 Jan 1993 05:15:11 GMT


branch prediction usually works if we know where we are going to branch to.
About 80%(?) of predictable branches occur in loops, so why don't we just
implement loops?

The major problems with loops is the provision for compiler support but
the most common branch prediction technique( prediction bits) also need
compiler support.

We can remove any need for loops if we use loop-unrolling but we can also
remove any need for branch prediction if we do branch-rolling, the trade-off
being more code to be stored. So both techniques are just ways of reducing
code size without making any significant processing power improvement.

I'm more in favour of using loops because they are easier to implement in
hardware and very useful for my target application-signal processing.

Brach cache will be able to handle the more unpredictable (the 20% conditional
branch cases) but it will incur more hardware support. The advantage is that it
can handle more branch cases but is it worth the trouble? Shouldn't loops be
sufficient?
	Can we adopt the loop technique(special case jump hardware) for the
other cases? We can do that if we can identify the special branch cases.

Once the conditional branches become more frequent(80%) as the case for 
super-intelligent software, should we abandon pipelining altogether?
After all the branch-prediction techniques are designed to reduce pipeline
flush penalty. 

--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet

Newsgroups: comp.arch
From: fy@lucid.com (Frank Yellin)
Subject: Re: big + little endian (was: Comparison of Alpha, MIPS ..)
Organization: Lucid, Inc., Menlo Park, CA
	<WAYNE.92Dec30093950@backbone.uucp>
	<markg.79.726169747@county.lmt.mn.org> <1993Jan6.171242.2895@lsl.co.uk>
	<RABIN.93Jan7132015@nuthatch.CS.Yale.Edu>
Date: 7 Jan 93 11:19:25


In article <RABIN.93Jan7132015@nuthatch.CS.Yale.Edu> rabin@CS.Yale.Edu (Dan
Rabin) writes: 

>  It's interesting to note that the digital notation passed through
>  Arabic-speaking culture on its way from its Hindu origins to its
>  adoption by Europeans.  Since Sanskrit is written from left to right,
>  this probably means that the perceived endian-ness has flipped twice.

Of course, how were numbers done in ancient Greek.  It was written in
boustrophedon:  the lines alternated left-to-right and right-to-left.

I wonder if numbers reversed from line to line, too.

-- Frank Yellin
   fy@lucid.com
Xref: sparky comp.arch:12231 comp.sys.intel:3001 comp.benchmarks:1925
From: mash@mash.wpd.sgi.com (John R. Mashey)
Newsgroups: comp.arch
Subject: Re: 100 Mips Intel NeXT (processor comparison)
Date: 6 Jan 93 01:54:58 GMT
Organization: Silicon Graphics, Inc.

In article <1992Dec31.022317.17674@wam.umd.edu>, rsrodger@wam.umd.edu (Yamanari) writes:
|> In article <1992Dec31.013141.132685@zeus.calpoly.edu> mneideng@thidwick.acs.calpoly.edu (Mark Neidengard) writes:
|> >I think that the way of getting around this bottleneck is to use EXTENSIVE


|> >Don't be surprised if CPU's start coming out with 1 meg of onboard cache
|> >within the next year...
|> 
|> 
|> 	Is this really likely, given the complexity (according to 
|> 	net rumor) already involved in fabricating the Alpha?

There are already reasonable numbers of *workstations* out there with 1MB
of cache on the motherboards (i.e., SGI Crimsons, in 1Q92; MIPS Magnums
& Milleniums; SGI Indigo 4000s; Sun SS10-41s (just recently); etc.

If the comment meant 1MB of cache on the CPU chip, expect to wait a while....

-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090
USPS:   Silicon Graphics 7U-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311
From: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: comp.arch
Subject: Re: A theory for Big & Little Endian's origin
Date: 8 Jan 93 21:40:32 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: hobbes.ucsc.edu


In article <1993Jan8.100549.28792@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
>In article <C0JE18.8Mp@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>
>>Also, when Hebrew texts use the traditional representation of numbers
>>by Hebrew letters, it is definitely Big Endian.  To my knowledge, this
>>seems to be universal
>
>To my knowledge too.  At least, I can confirm that Egyptian, Babylonian,
>Greek, Roman and Mayan numbers were big-endian.

Well I wasn't talking just about numbers. Endian-ness also applies to 
text strings stored in computer words.  If you go Big-Endian then
text strings read left to right when you print out the characters in a
word from left to right.  If you go Little-Endian then you need to
print a core dump in hex or octal left to right and in characters
right to left.
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Ya can talk 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"
Newsgroups: comp.arch
From: schouten@sp95.csrd.uiuc.edu (Dale Schouten)
Subject: Re: Def of a workstation (a lark)
Organization: Center for Supercomputing R & D
	<1993Jan04.155544.18325@eng.umd.edu> <1993Jan4.224018.16370@netcom.com>
	<1993Jan05.004806.14107@news.mentorg.com>
	<1993Jan5.151054.12967@crd.ge.com>
Date: 5 Jan 93 13:44:51

In article <1993Jan5.151054.12967@crd.ge.com> davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
>   For my money, if it runs UNIX (or POSIX) and supports TCP and NFS it's
> a workstation. Otherwise it's a something else.

I'd have to roughly agree here.  I know it seems superficial, but when
it comes down to it, the main thing I associate with a workstation
that I don't find on PC's (aside from the decent sized screen) is a
multi-user, multi-tasking (i.e. `real') operating system (so I can
have lots of pretty windows) and relatively transparent connection
to a network (i.e. NFS, file access without caring where the actual
file is).

Dale Schouten
schouten@uiuc.edu
Newsgroups: comp.arch
From: wong@rkna50.riken.go.jp (Wong Weng Fai)
Subject: Re: SPARC Simulator ...
Organization: Institute of Physical & Chemical Research (RIKEN) Saitama,Japan
Date: Mon, 11 Jan 1993 07:18:32 GMT


Hello,

	Thanks to everyone who responded. Unfortunately, it appears that my
search is in vain. There were more mails saying "Yeah ! I want that too ! So
keep me posted of anything you got" than those offering help. Those who did
offer help spoke of the two trace tools for the SPARC available on the public
domain : SPA and Shade/Shadow - both of which I have. What I wanted was to
be able to modify the instruction set in an (fairly) arbitrary way. A trace 
tool can't do that. Thanks anyway !

	Well, the bottom line seems to be - there aren't any ! Its probably
not too difficult to hack one up but the problem is to support all those
nasty system services properly - especially stuff like malloc which requires
detailed information about the memory (which wouldn't be the same for a
simulator and an actual execution).

	A suggestion though ... if anyone do come up with such a simulator,
may I suggest that in line with SPIM, one should name it "SPARC" spelled
backwards, i.e.

		C R A P S   ! ! !

:-):-):-)

	Thanks again !

Regards,

W.F. Wong.

Newsgroups: comp.arch
From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: Def  of a workstation (a lark)
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Mon, 11 Jan 1993 02:57:25 GMT

In article <1993Jan3.235327.13718@qb.rhein-main.de>, vhs@rhein-main.de (Volker
Herminghaus-Shirai) writes:

|>A decent workstation has IMHO *at least* the following items of which the
|>software can and does take advantage of:
|>	a high-resolution screen
|>	a pointing device
|>	an ethernet connection (or token ring if your management was bribed ;-)
|>	a UN*X operating system with TCP/IP support and a C compiler
|>	a boot prom that allows for interactive diagnosis etc.
|>	a decent amount of RAM and hard disk space
|>	a tape drive for backups and data exchange as opposed to floppy disk
|>	other items I may have forgotten (it's already tomorrow...;-)

Oh so my Alpha 3000/500 isn't a workstation becaus I run VMS? Well well...

By any resonable definition the old VAX-2000 was a workstation, mouse, high res
screen, windows. Only too damn slow to do anything sensible on.

They were great for about 6 months after they came out. Then people started
hammering them as the windows stuff allowed you to do more with the machine. I
wouldn;t thank someone for giving me a 2000 to use as a workstation today.

So far I haven't felt the lack of a tape drive. I have a CD ROM but no tape,
just the net.


IMHO a workstation should have the following:-

High Res Screen + Mouse (Pref Sony Trinitron...)
FDDI
Secure Multiprocessing O/S with threads.
Lots of RAM, lots of disk avaliable.
Full Online Documentation 


For home use I fail to see the need for multiuser. For use at work I would
want:-

FDDI and Ethernet
Multiuser

Either way I would want POSIX to be avaliable.


--

Phill Hallam-Baker
Newsgroups: comp.arch
From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: Def of a workstation (a lark)
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Mon, 11 Jan 1993 23:12:50 GMT

In article <1993Jan04.155544.18325@eng.umd.edu>, sysmgr@king.eng.umd.edu (Doug
Mohney) writes:

|>In article <1i5vdmINN3ek@cs.widener.edu>, YOUNG@tattoo.cs.widener.edu (Rob
|>Young) writes:
|>>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.

I think you will notice a big difference between the seriously nice PXG graphics
on the TURBOchannel and the PC weanie version. 

|>Hm. Does this mean the HP Workstations, which use EISA, are really PeeCees
|>in disguise? :-)

Probably the reason for DEC marketing making the distinction.

|>Actually, a "workstation" would have the following vague and fuzzy
|>definitions,
|>according to the book of Moo:
|>
|>	A) One big f@#$ing screen, which is nearly as expensive as the CPU.
|>	   Don't bother braggin' unless it's 17" or better.

Lots of PCs seem to be appearing with the SONY Trinitron monitor, a niiccceee
peice of kit.

|>	B) Designed to be seamless-ly intergrated into Internet and can run
|>	   news. :-) PC's don't count here because you have to:
|>		1) buy an Ethernet card 
|>		2) Add drivers to run TCP/IP

Which throws out VMS again since TCP/IP is an add on, since Multinet etc started
up DEC would have a lawsuit on their hands if they bundled UCX.

Mind you ont thing that peeves me. Have you noticed all the pc portables that
don't have an ethernet card? To get a portable Pc that plugs into the net I
would have to by something costing almost as much as a workstation, Also the
expansion boxes for those beasties are a rip off, most only seem to have two
slots - after you have plugged in your ethernet card you have to chose between
the frame grabber for dirty pickys, the SCSI bus interface, the hi res display
card...


--

Phill Hallam-Baker
From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Newsgroups: comp.arch
Subject: Re: AST on UNIX
Date: 9 Jan 93 22:25:17 GMT
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA

In article <1992Dec28.154934.25582@decvax.dec.com>, simon@mallard.edec.locus.com
(simon R) writes:

|>: >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.
|>

The AST functionality is in any case to a large degree superceeded by POSIX
threads. The addition of threads to VMS has been one of the most useful of the
recent additions. Of course if you have ASTs then it is quite easy to add on the
threads.


--

Phill Hallam-Baker
Newsgroups: comp.arch
From: firth@sei.cmu.edu (Robert Firth)
Subject: Re: A theory for Big & Little Endian's origin
Organization: Software Engineering Institute
Date: Fri, 8 Jan 1993 10:05:49 EST

In article <C0JE18.8Mp@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

>Also, when Hebrew texts use the traditional representation of numbers
>by Hebrew letters, it is definitely Big Endian.  To my knowledge, this
>seems to be universal

To my knowledge too.  At least, I can confirm that Egyptian, Babylonian,
Greek, Roman and Mayan numbers were big-endian.

One interesting exception is the mediaeval conceit of embedding a roman
number in a name or phrase, which of course works because the roman
numerals aren't positional.  For example, the phrase

	et in arcadia ego

encodes the number DCII, or 602.  You'll find some mediaeval buildings
dated in this manner.