HDTenEightyP/NetNews huggingface dataset:
From: peter@ferranti.com (peter da silva)
Subject: Re: A theory for Big & Little Endian's origin
Organization: Xenix Support, FICC
Date: Tue, 12 Jan 1993 15:03:49 GMT

In article <1993Jan11.192019.2922@lsl.co.uk> snail@lsl.co.uk writes:
> Little endian sucks if you're an assembly freak (such as I was for many years)
> an you look at memory dumps for multi-byte values like addresses, the nibbles
> are all in the wrong order:-

> 	Big Endian	: $1234
> 	Little Endian	: $3412

So print your dumps backwards. DEC's VAX macro-assembler does something
like this:


               HEX        ADDR        CODE
7 6  5 4  3 2  1 0
         1234 00EC        0100        INSTR  #1234
                90        0104        INSTR

Just a DEC hardware junkie.
-- 
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: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: reentrant
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Mon, 11 Jan 1993 03:14:16 GMT

In article <1993Jan4.095245.1@zodiac.rutgers.edu>, leichter@zodiac.rutgers.edu
writes:

|>In article <C08qF4.Knz@news.iastate.edu>, john@iastate.edu (John Hascall)
|>writes:
|>> }>The OS world is moving towards multithreading...
|>> 
|>> ...
|>> Perhaps the research world has been...
|>> But as far as (popular) commercially available OSes, it would seem not:
|>> 
|>>   MS-DOS:  not a chance
|>>      VMS:  nope
|>
|>The story for VMS is complicated, and an excellent illustration of why
|>"yes/no" questions can be misleading.

|>There's a spec for a supported true threads package for VMS (and OSF); I
|>don't think it's officially out yet for VMS, but it's been promised.

Well its been in the bookreader for ages, not yet got arround to giving it a
try. There is no instalation guide for it, so it looks like its in the basic
O/S.

Most of the routines are fully re-entrant, but for some C run time library stuff
you have to call a jacket routine (presumably it just sets up a mutex or
something).

|>
|>All of which makes Mr. Hascall's distinction:
|>
|>>      VMS:  nope
|>>     UNIX:  not yet
|>
|>rather curious.
|>
|>(BTW, the earliest thread package, complete in the modern sense, that I know
|>of in a commercial operating system was in VAX ELN, a real-time OS for VAXes
|>that DEC has sold since about 1983.)

Threads is going to be the stick that breaks Novell. AT&T dumped UNIX on them
because they knew they couldn't keep up. If you go for serious object oriented
stuff then threads are pretty well essential. Comparing OSF/1 and UNIX I can't
see much future for UNIX without a hell of a lot of work in a damn short time.


--

Phill Hallam-Baker
From: gupta@prlhp1.prl.philips.co.uk (Ashok Gupta)
Newsgroups: comp.arch
Subject: Lecture in London
Date: 8 Jan 93 15:11:53 GMT
Reply-To: gupta@prl.philips.co.uk
Organization: Philips Research Laboratories, Redhill, UK



                          The British Computer Society
                      Parallel Processing Specialist Group

                                   (BCS PPSG)

                                Public Lecture:


                      HIGH PERFORMANCE PARALLEL COMPUTING:
                                    A REVIEW

                             by Professor John Gurd


                                Wed Jan 13 1993
                              6.15 pm for 6.30 pm

                            Fleming Lecture Theatre
                           University College London
                                Torrington Place
                                   London WC1

                        (entrance directly opposite main
                         entrance to Dillons book shop)

                       This is a free public lecture open
                                to one and all.

                         No prior booking is required.

                      Membership of the BCS or of the PPSG
                                is not required.


                                       **
                    ** PLEASE CIRCULATE THIS ANNOUNCEMENT **
                                       **
Newsgroups: comp.arch
From: achim@mips1.info.uqam.ca (Achim*Marcel)
Subject: SPARC architecture
Summary: Need info
Organization: Universite du Quebec a Montreal
Date: Sun, 10 Jan 1993 15:48:35 GMT

Hi,

   I'm preparing a course on computer architecture and I'm looking for
references about SPARC architecture, namelly caching and VM support.

Thanks
Marcel Achim
achim@info.uqam.ca
Newsgroups: comp.arch
From: preston@dawn.cs.rice.edu (Preston Briggs)
Subject: Re: FP-number cache? Unclocked VLSI design.
Organization: Rice University, Houston
Date: Wed, 6 Jan 1993 02:45:29 GMT

tve@crackle.CS.Berkeley.EDU (Thorsten von Eicken) writes:

[about SIGARCH Notices]

>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?

Yeah, I've thought this about a lot of the papers in SIGPLAN Notices.
On the other hand, there _are_ useful papers, submitted by people who
are concerned about timely publication or wide distribution.
Also by people who are less concerned about building a case for
tenure!  A nice example is the whole series that Henry Baker has been
knocking out recently.  He's single handedly raising the tone of the
publication.

As Tipley suggests, CAN might place to publish otherwise unpublishable
papers.  Overcoming the (natual) reactions of von Eicken will be the
challenge.

And then there's comp.arch :-)

Preston Briggs
From: daryl@bovill.auspex.com (Daryl Starr)
Newsgroups: comp.arch
Subject: Quad Design
Date: 12 Jan 93 00:26:00 GMT
Organization: Auspex Systems

I'd be interested in conversing with anyone that has experience with
either XTK or Motive. I am particularly interested in the accuracy of
the tools and the availability and quality of the models.

Send email to dstarr@auspex.com.

Daryl
From: ajc@pa.dec.com (AJ Casamento)
Newsgroups: comp.arch
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Date: 4 Jan 93 07:37:19
Organization: Digital Equipment Corporation
	<AJC.93Jan1182933@thendara.pa.dec.com>
	<1993Jan3.134441.26055@dvorak.amd.com>
NNTP-Posting-Host: thendara.pa.dec.com
In-reply-to: tdbear@dvorak.amd.com's message of Sun, 3 Jan 93 13:44:41 GMT




In article <1993Jan3.134441.26055@dvorak.amd.com> tdbear@dvorak.amd.com 
(Thomas D. Barrett) writes:

In article <AJC.93Jan1182933@thendara.pa.dec.com> ajc@pa.dec.com (AJ Casamento)
writes:

 >However, my point was that COMPAQ could also provide a common interface ASIC,
 >equivalent to the TcIA, that would provide a very cheap cut and paste logic 
 >for Option card vendors that would provide a lowest risk path for migrating 
 >their current designs to this new interconnect. 

>Good point AJ... but having the design and the simulation of the
>design shared by more of the members would insure the openess and help
>get the ball rolling faster.  Mind you, though, I'm not volunteering
>unless you folks want a DABL model :)

Tom,

  You're right of course (must have been Holiday senility on my part). Having
access to a common model (Verrilog, VHDL, or some such) for the ASIC would be
a real plus. Actually, a bus transactor model would be a win as well. It would
certainly tend to cut down on the issues of platform compatibility that seem
to plauge a lot of the third party option world. Given a reasonably thorough
model, there should be a lot less chance of having an option card work on one
system platform and not on another one (I don't expect there to be any absolute
solutions to this problem of course; I'm idealistic, not foolish ;-) and there
are simply too many folks who will choose not to verify their designs).

  So add such a model to my list of items that should be supplied for this new
interconnect.

Still just my own 2 cents (which will hopefully be worth more in a 93 economy).

				Thanx,
				  AJ


      **********************************************************************
      * AJ Casamento			"The question is not whether or    *
      * Digital's TRI/ADD Program	 not the opinions are mine; but    *
      * 529 Bryant Ave. PAG-2		 rather, which of my personalities *
      * Palo Alto, CA 94301-1616	 do they belong to?"		   *
      * 415.617.3460							   *
      * ajc@pa.dec.com  						   *
      **********************************************************************
From: snail@lsl.co.uk
Newsgroups: comp.arch
Subject: Re: A theory for Big & Little Endian's origin
Date: 11 Jan 93 19:20:19 GMT
Organization: Laser-Scan Ltd., Cambridge

In article <16294@auspex-gw.auspex.com>, wally@Auspex.COM (Wally Bass) writes:
> In article <willmore.726511292@help.cc.iastate.edu> willmore@iastate.edu (David Willmore) writes:
> Given that Intel x86 started as narrow data flow stuff, it's
> not surprising that it ended up with low-byte-first.

It's quite interesting that Intel did get it right on one (and only one, I
think) of their chips. I can't remember the number of it, but I think it was 
before the 8080, and I don' think it was a 4004 or 8008, but could be wrong,
but one of their chips was big-endian - then they changed their minds - was it
an 8051 or something like that.

Little endian sucks if you're an assembly freak (such as I was for many years)
an you look at memory dumps for multi-byte values like addresses, the nibbles
are all in the wrong order:-

	Big Endian	: $1234
	Little Endian	: $3412

At least it'd be easier if little endian had the bits the right way round - but
thats only a concept, so on a little endian machine I could look for:-

     $4321, yes bizarre idea, and just as well no one ever did it!

but searching for $3412 when I want address $1234 is painful to say the least.
No I program in C and Modula 2, so it isn't really a problem for me anymore.

That $ just brought another thing in, I hate Intel syntax.

	$65 is better than 65H because I know it's hex before I read it.
	$A is better than 0AH because AH is illegal, and I know it's hex before
           I read it, and I don't need a leading zero to make it legal.

	Same goes for binary %00010001 as against 00010001B

        I can't remember the Octal syntax, but ....

Yes, I'm just a Mostek/Motorola junkie.

Looks good on the outside, but
     Intel inside.
-- 
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.
Newsgroups: comp.arch
From: schumanm@Informatik.TU-Muenchen.DE (Matthias Schumann)
Subject: i860XP peak performance
Originator: schumanm@sunbode10.informatik.tu-muenchen.de
Organization: Technische Universitaet Muenchen, Germany
Date: Tue, 5 Jan 1993 14:12:22 GMT


Hi there,

in most papers the PEAK performance of the 50MHz i860XP is given as 75 MFLOPs
(double prec.) and 42 MIPs. The 75 MFLOPs are pretty clear to me but where are
the 42 MIPs are coming from. IMHO the 50Mhz chip should have a PEAK performance
of 50 MIPs.                                                    ^^^^
Is there anyone who knows ?

Bye,
      Matt
--
| Matthias Schumann       Department of Computer Science/SAB       TU-Muenchen |
| schumanm@informatik.tu-muenchen.de                              Arcisstr. 21 |
| Phone: +49 89 2105 2036                                      8000 Muenchen 2 |
From: spackman@disco-sol.dfki.uni-sb.de (Stephen Spackman)
Newsgroups: comp.arch
Subject: Partial endian solution
Date: 8 Jan 1993 21:52:35 GMT
Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken
	<willmore.726511292@help.cc.iastate.edu> <16294@auspex-gw.auspex.com>
Reply-To: stephen@acm.org
NNTP-Posting-Host: disco-sol.dfki.uni-sb.de
In-reply-to: wally@Auspex.COM's message of 8 Jan 93 20:02:07 GMT

The argument for little endian is: term n of the polynomial representing
a number is at offset n. That should save some effort now and then and
makes more conceptual sense to those of us who think in these terms
(rather than paper notations which, as discussion here shows, are
totally arbitrary).

The argument for big endian is: sort orders work out to be the same for
integers and strings. (This is the place where the "order of writing"
really matters - though it's really pure coincidence that they coincide).

IMO, the sort order argument is weaker than it looks, because the
topology of strings is rational and not integral - so it's sort of
natural that they should be different.

That last observation prompts me to suggest that bytesex inconsistency
should be handled *not* by having byteswap operations, but rather by
laying out structures and arrays (including strings) in a
**negativegoing** direction on whatever you deem to be the "hostile"
architecture (as you might guess from the above, I vote for bigend as
"hostile"). Except in the case of machines that use inconsistent bit-
and byte-sex (68000 case in point) this lets you use the *same* layout
logic for *both* genders.

You can even share structures between the two architectures if one of
the sharers negates its addresses (whether in software or in hardware).
----------------------------------------------------------------------
stephen p spackman    +49 681 302 5288(o) 5282(sec)    stephen@acm.org
      dfki / stuhlsatzenhausweg 3 / d-w-6600 saarbruecken 11 / germany
----------------------------------------------------------------------
From: wally@Auspex.COM (Wally Bass)
Newsgroups: comp.arch
Subject: Re: A theory for Big & Little Endian's origin
Date: 8 Jan 93 20:02:07 GMT
Organization: Auspex Systems, Santa Clara

In article <willmore.726511292@help.cc.iastate.edu> willmore@iastate.edu (David Willmore) writes:
>The other way fixes the load problem.  Say you want to read an 8
>bit value starting at address 0.  The first byte read goes in the
>low order part of the register, the rest is cleared.  To load a
>16 bit value, address 0 is placed in the low byte of the register
>and the next byte at address 1 is placed in the next higher byte
>of the register.  That way, a 32 bit or more number can be at a
>fixed location and you can optionally load 8 bits, 16 bits, or the
>full 32 bits without having to adjust your address register.

Actually, I think that it's not the 'load' problem so much as it is
the 'add' problem. When you are going to do an add on a machine with
1 byte adder, you want the low order bytes of both operands first,
and the high order bytes last, because that is the direction in
which the carry propagates.

Noting that a great many of the operands to the adder are literals
in the the instruction stream (i.e., both literal constants and
memory address offsets), on a machine with a narrow data path,
one would like to arrange things such that, at least for constants
in instructions, normal instruction prefetching encounters
low order bytes first. Once you chose that format in the I-stream,
doing it for other data follows for all kinds of reasons.

Given that Intel x86 started as narrow data flow stuff, it's
not surprising that it ended up with low-byte-first.

For architectures which weren't so biased by a narrow data flow in
their earlier years, high byte first makes more sense, if only to
allow arithmetic values in dumps to be read more easily. (This
indeed, may vary according to the native language in use, but the only
languages which enter into the question are the native languages
of the early developers who first established the conventions, and
I think these were primarily of European/USA origin.)

Wally Bass

Newsgroups: comp.arch
From: tg@utstat.toronto.edu (Tom Glinos)
Subject: Re: Def  of a workstation (a lark)
Organization: University of Toronto, Dept. of Statistics
Date: Wed, 6 Jan 1993 14:06:37 GMT

In article <1993Jan5.152453.13303@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>  I can remember installing V7 on a PDP-11, and it startet with toggling
>the boot so the paper tape could be read to boot the magnetic media...
>we have made progress in the last few decades.

But just barely. 

Yes, I too booted and installed V6 and V7 many times over the years.
Booting V7 (minus toggles) and going multi-user took about 30 seconds.
You would be hard pressed to do that today with your common workstation.

After a period of time, I was able to turn a stock '11 into
a production system in a morning. I find it still takes me a morning
to turn today's modern machines into something close to production.

Packaging of distributions, until quite recently, has been awful.
With V7 you would get one tape that was easily readible and accurately
documented. You would get boot images and tar files. You extract what
you wanted. You knew EXACTLY what you were getting. You could
COPY the distribution tapes. Can you easily do that with a distribution
from any of those 3 letter computer companies today.

CD's help, but they are ugly because their inherent structure was geared 
toward serving the DOS market.
-- 
=================
Man MUST reach for the stars,		| Tom Glinos @ U of Toronto Statistics
otherwise, he will wither, and die.	| tg@utstat.toronto.edu
From: monnier+@cs.cmu.edu (Stefan Monnier)
Newsgroups: comp.arch
Subject: Re: Asynchronous acorn.
Keywords: How do they interface the new asynchronous acorn with the main memory ? Is the cache asynchronous too ?
Date: 8 Jan 93 23:43:26 GMT
Article-I.D.: cs.C0K78E.7AA.2
Organization: School of Computer Science, Carnegie Mellon

I've read about the 'previous' asynchrous processor (but non-commercial 
(especially lacking interrupts)), but I just can't find any report
on the ARM. Is there some source of information about it (I've got
the tiny BYTE article, but that's FAR too general) ?

Or is it too early ?

(I'm especially interested in the way they handle interrupts)

Thanks for any hints,

	Stefan
Newsgroups: comp.arch
From: awolfe@moo.Princeton.EDU (Andrew Wolfe)
Subject: Re: FP-number cache? Unclocked VLSI design.
Originator: news@nimaster
Organization: Princeton University
Date: Tue, 5 Jan 1993 17:04:46 GMT

In article <1993Jan5.085415.19676@klaava.Helsinki.FI>, veijalai@klaava.Helsinki.FI (Tony Veijalainen) writes:
...
|> 
|> On the other hand FPU-units that appear more and more are in modern big
|> CPU:s are quite far conceptually from other operations.  I have
|> suspision that FP-arithmetic tends to cluster quite heavily, and because
|> of traditional efficiency thinking and fixed number arithmetic in
|> business applications some big parts of programs are integer only (not
|> much FP-operations in interupt code for example :-). 
|> 
|> So have somebody researched the havoc FPU-instructions make to general
|> data cache? Is there possible advantage of having FP-number (with
|> separate bus to FPU-register file) and fixnumber caches with advantages
|> outdoing the cost on CPU (like diminiching the general cache size, is
|> this over specialization?). 
|> 
|> -- 
|> Tony Veijalainen	e-Mail: Tony.Veijalainen@helsinki.fi (preferred)
|>  		(finger veijalai@plootu.helsinki.fi for more information)
|> 


My students and I performed this experiment last year.  I thought that it
was a great idea.  In retrospect - maybe it wasn't.

The idea was this:
-------------------

Since FP and Int data are essentially different classes of information and
use different parts of the CPU - (Just like instructions and data) - should
we provide two caches and two paths to cache?  Would this double memory
throughput in FP intensive code?

We modified Mike Johnson's superscalar processor simulator to support two
data caches - one for ints and one for FP.  We also increased the internal
L/S units and the L/S busses to support the extra BW required.  If FP and
integer data exist of the same cache line - a snooping mechanism would
maintain coherency.  

We found that the speedup was no more than 2-3% higher than using a single
cache of combined size.  In non-FP codes, the larger single cache was better.


Explanation:
-----------

We believe that the explanation is that during FP intensive operations, most
programs use only a few addressing integers and keep these in registers.
Therefore, while FP and Integer BW are both important - they are not usually
used at the same time.  Some programs with pointer-based data stuctures may
respond differently. (We used SPEC programs).

I still have hope for multiple caches - but not using FP/Int classifications.


Want more info - Princeton Univ Tech. Rept. CE-A92-2 can be requested from
me.


(Philosophical note.  This experiment also raised the issue of whether or
not the architecture community will accept the publication of negative
results.  We could not locate any recent papers in major conferences that
did not have positive results)

-- 
--------------------------------------
Andrew Wolfe
Assistant Professor
Department of Electrical Engineering
Princeton University
Newsgroups: comp.arch
From: paulk@kpc.com (Paul Kalapathy)
Subject: PCMCIA bus info?
Organization: Kubota Pacific Computer Corporation, Santa Clara, CA
Distribution: na
Date: Thu, 7 Jan 1993 21:08:11 GMT


Where can I find some technical information on the PCMCIA interface?
By technical I mean pinout, timing, protocols, etc.  Is there a SIG, 
or somesuch?  Send me some email and I'll summarize if there is sufficient
interest.  Thanks.

	-Paul
	 paulk@kpc.com
Newsgroups: comp.arch
From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
Subject: Swap byte instruction - how high is the win?
Reply-To: vhs@rhein-main.de
Date: Thu, 7 Jan 93 07:40:52 GMT

Subject line almost says it all. Many modern processors have an
instruction to swap the bytes in a word. Can one quantify the
win of using this instruction vs. the equivalent sequence of
instructions? How much silicon is needed? What applications
win the most and how much? There must be *some* resaon why the
RISC folks put it in, right?

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

Looks good on the outside, but -
	intel inside
Newsgroups: comp.arch
From: johng@cirrus.com (John Geldman)
Subject: Re: PCMCIA bus info?
Organization: Cirrus Logic Inc.
Distribution: na
Date: Tue, 12 Jan 1993 23:39:54 GMT

In <1993Jan7.210811.22360@kpc.com> paulk@kpc.com (Paul Kalapathy) writes:


>Where can I find some technical information on the PCMCIA interface?
>By technical I mean pinout, timing, protocols, etc.  Is there a SIG, 
>or somesuch?  Send me some email and I'll summarize if there is sufficient
>interest.  Thanks.

>	-Paul
>	 paulk@kpc.com

From my latest document order form the specifications are available from:

	Personal Computer Memory Card Association
	1030G East Duane Avenue
	Sunnyvale, Ca. 94086
	Ph: 408/720-0107
	Fax: 408/720-9416

From the latest Document Order Form (11/92), full PCMCIA
specifications cost $250 for non-members (there was a special price of
$195, but I believe it has expired).

This includes:
	PC Card Standard Release 2.01, 
	Socket Services Specification Release 2.0, 
	Card Services Specification Release 2.0, 
	AT Attachment (ATA) Mass Storage Specification Release 1.01, 
	Auto Indexing Mass Sorage (AIMS) Specification Release 1.0 
	and Reccomended Extensions) 

There is also a PCMCIA Resource Reference Book for $12.50 (for non-members).

There is also a BBS, 408/720-9388 (2400 baud) and 408/720-9386 (9600 baud,
V32, MNP5)