HDTenEightyP/NetNews huggingface dataset:
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Translating ML (was Re: MVC and MVCL)
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Thu, 30 Jul 92 06:15:39 GMT

In article <1992Jul27.170228.10737@ryn.mro4.dec.com> leonard@ricks.enet.dec.com () writes:
>
>As I remember, EX on the IBM S/370 is normally used to supply variable arguments
>for some instructions.  A machine-language compiler should replace the EX not
>with a direct emulation of EX, but with a check that the executed instruction was the expected one (move string, for example), and code that either
>simulated the effects directly (doing a variable-length move) or calling the
>run-time simulator (for the unusual case where the instruction has actually been
>modified).
>
>It may be that self-modifying code is actually a problem for compilers of /370
>machine language, but the existence and frequent use of EX is not sufficient
>evidence.

EX and Self-modifying code is NOT just a problem for S/370 compilers;
They were the ONLY sane way to perform variable-length operations on
the S/360-S/370 line. Any variable length mover, comparer, etc
(Move x to y for n items) suffered from one of these problems.

EX was particularly nasty even in S/370 days, because you could write 
a long move/compare routine using EX or SMF(Self-Mod- Code) which ran
TWICE as fast as the same routine using MVCL, CLCL. Plus, the 
hand-coded routine would let you do overlapped moves or compares, 
which were verboten in the xxxL familar of instructions.

Bob

Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
Newsgroups: comp.arch
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 24 Jul 1992 05:58:49 GMT

In article <GLEW.92Jul23183353@pdx007.intel.com>, glew@pdx007.intel.com (Andy Glew) writes:
>     ...
>                      .  How about other worlds?  Which is more common,
> cache coherent or cache incoherent I/O?  I believe John Mashey already
> noted that on the R3000 I/O was non-coherent, but on the R4000 I/O is
> coherent.


Without intending to contradict John, since I don't recall what he
wrote, please note that not all currently shipping R4000 systems have
coherent I/O.

The two I'm aquainted with (one may not be quite shipping yet--I don't
know) have 128-byte wide, write-back caches that must be explicitly
flushed and/or invalidated by driver software.


Vernon Schryver,   vjs@sgi.com
From: mjohnson@netcom.Netcom.COM (Mark Johnson)
Newsgroups: comp.arch
Subject: Re: Code Repositioning on MIPS Systems?
Date: 26 Jul 92 15:39:35 GMT
Organization: Netcom Online Communications Service

Are there any such tools available on Hewlett Packard
systems?  MIPS's "cord" is part of the standard no-extra-cost
software shipped (& has been since about '87); how about HP's?

It's easy to imagine that the single-level caches of the HPPA
implementations would benefit quite well from such a thing.
Is HP-cord available now?  (I have access to a Snake model 710 and
"man -k" on that machine didn't reveal anything resembling
cord.  But maybe I missed it...)
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Request Info Re Bus Trends & Intel 486s
Date: 23 Jul 92 18:41:45 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <MKAHN.92Jul22091003@hopi.sedona.intel.com>, mkahn@hopi.sedona.intel.com (Mitch Kahn) writes:

| The P5 will have very significant performance advantages over the 486 family.
| I would expect a similar 486->P5 migration as we are seeing now with the
| 386->486. But it won't happen until about 1994. (My opinion)

  For what it's worth, _Computer Retailer News_ had an article which
said that the 586 (by whatever name) would be about $150 more than the
486, and half of the original price of the 486.

  It also indicated that applications would run twice as fast as a 486
without modification, and another factor of two with recompilation. I
read that as meaning in 16 bit MS-DOS mode and normal 32 bit protected
mode. Since the slowest chip is stated to be at 66MHz, if that was twice
as fast as a 486-33 I wouldn't be impressed.

  This info is only as good as the rumor mill, but if the price is
really that low, the change from 486->586 will occur as fast as Intel
can deliver chips. Double the power for 5% or less of the system price
sounds good to me.

  I think the headline was "Intel running scared" or some such.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
	It never ceases to amaze me that otherwise rational people, able to
	understand calculus, compound interest, and the income tax form, can
	continue to believe that poker is a game of chance.
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.arch
Subject: Re: Solaris (was: Sun 600MP Benchmark Anomaly)
Date: 25 Jul 92 19:04:32 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Jul25.142435.9821@athena.mit.edu>, jfc@athena.mit.edu (John F Carr) writes:
> In article <14pkdrINN5ni@uk-news.UK.Sun.COM>
> 	adrian.cockcroft@uk.sun.com writes:
> 
> >I have run a two processor S600MP with a Solaris 2 beta release with
> >both CPU's at over 95% system time (to show that it can be done).
> 
> How much of the 95% is spent in the locking code?  How much is spent
> waiting for locks?
> --
>     John Carr (jfc@athena.mit.edu)


Ouch!

You must have see some of the some MP UNIX kernel implementations, and
wondered how they get anything done what with all of the locking and
P'ing and V'ing.

It is an odd fact of human nature that once an organization has
access to multiprocesses, two things invariably happen:

    (1) about half of the people (inside and out; all of customers,
	marketing, and implementors) get bent out of shape if anything
	in the system is not fully semaphored with tiny grains.  These
	people want "pre-emption points" every dozen lines in critical
	sections.  They want every instance of every data structure to
	have its own lock, and sometimes 2 or 3 per data structure to
	fix the consequent effects of having lots of tiny overlapping
	critcial sections.

    (2) about the other half of the same universe of people get bent
	out of shape if they cannot "dedicate" or "allocate" or
	"reserve" a CPU for a single kind of work or process or user.
	These guys are the sort who demand the ability to put reserve a
	CPU for the disk controller, the terminal serial I/O code,
	Fortran compilations, or whatever else they think most
	important.


I'm in the third group, and have argued with both groups seemingly
continuously since the first symmetric MP system I worked on in the
late 70's.  It gets boring after awhile


Vernon Schryver,   vjs@sgi.com
From: bobeson@nonskid.Eng.Sun.COM (Robert Ellefson)
Newsgroups: comp.arch
Subject: Re: burst mode
Date: 30 Jul 92 20:06:30 GMT
Organization: Sun Microsystems
Distribution: world
Reply-To: bobeson@nonskid.Eng.Sun.COM
NNTP-Posting-Host: nonskid.eng.sun.com

In article Ln0@acsu.buffalo.edu, chen-m@acsu.buffalo.edu (Mingteh Michael Chen) writes:

>What is the burst mode of the Micro channel architecture?
>and what makes it to be superior than other approaches? (maybe DMA?) 
>I have some vague idea that it transfers a whole memory "block"
>instead of a memory word individually. But as long as the bus bandwidth is
>fixed, each memory "word" still needs to be transferred sequentially...
>

As I remember, the Streaming Data Mode (which I am assuming is
what you mean by 'burst mode') allows for block transfers to occur
without needing to setup the address for each word, so that the clocking
for each data word after the start of the block is much faster.
(Normally, you setup the address before you clock the data, because different
portions of the address space have different access times, which requires different
wait state assertions.) Also, there is now (with the RS/6000, at least)
a 64 bit streaming data mode, which uses both the address and data busses
for data transfer.  

Other than the 64 bit transfer option, I'm not sure that the microchannel
approach is significantly better than others. (Nubus at least has a comparable
block transfer mode (not 64 bit)).  Maybe someone more recently familiar with 
the other existing bus protocols can give a better comparison, though.



Xref: sparky comp.arch:8463 comp.os.linux:7039
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch,comp.os.linux
Subject: Jump tables for shared libraries
Date: 30 Jul 92 15:13:01 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Followup-To: comp.arch
Organization: GE Corporate R&D Center, Schenectady NY


  A recent post to comp.os.linux indicated that there would be a change
to jump tables for the shared libraries in the next release. WHile I
understand the convenience features of jump tables, it would seem that
there would be a better way to avoid relinking programs, which would
avoid the overhaed of the indirection.

  Two thoughts come to mind. The first is to have some form of runtime
loader, which would do the linking at image activation time, rather than
at image store time. This would cause startup overhead, but would avoid
runtime overhead due to the indirect. The second would be to have the
jump table in unmapped memory, and have the o/s catch the call, modify
the image in memory to use the real address, and then restart the
program at the point of the call. This moves stuff down into the kernel,
and imposes a trap for each point in the image at which a library call
occurs.

  My personal preference is to not have the jump table, and if I have to
relink programs when I upgrade my library, so be it. It's not that big a
deal, and programs without source (not in the linux world) could be
distributed as archives of objects and linked by the end user. This can
be automated with a tiny shell script.

  Is there newer and/or better thinking on this problem? I estimated the
overhead at up to 5%, and the original poster mentioned that he actually
measured 2-4% on programs. While that makes me feel good about my
estimating skills, I'm not overjoyed at the thought of a 2-4% drop in
performance. Hopefully someone will suggest an alternative method which
I can pass along for consideration.

  I x-posted this, follows are directed to comp.arch for any Linux-ers
who want to follow it.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
	It never ceases to amaze me that otherwise rational people, able to
	understand calculus, compound interest, and the income tax form, can
	continue to believe that poker is a game of chance.
From: lycmit@X1SUN6.CCL.ITRI.ORG.TW (Yin-Chih Lin)
Newsgroups: comp.arch
Subject: Could I compete the low-end CM5 with multiple SPARCstations?
Date: 23 Jul 92 06:13:45 GMT

Greetings:

We have many Sun's SPARCstations (from 1, 1+, IPC, to 2, 670MP and 
SPARCstation 10 in the near future), and the new-version multi-thread
OS (SunOS 5.0) will be installed on these computers.

I find that the Think Machines Corp.'s latest MPP machine CM-5 is also
adopted the SPARC processors (22 MIPS per processor) as its nodes.
According the "Parallel Processing" Oct. 1991 issue, the price of 32-node
CM5 model will sell at about $1.4 million.

I am curious, if I connect 32 SPARCstation 10 model 30 (33MHz, SuperSPARC
module with 86.1 MIPS - Sun Micro adverted!?) computers (loosely-coupled
MIMD multicomputers?) either by Ethernet, ISDN or FDDI with the multi-
thread OS and might use facilities from Linda-like distributed data
structures. Is it possible for me to obtain the reasonable performance
when compared with the 32-node TMC CM5 (SIMD machine)?

I will be highly appreciated for receiving any comments. Please direct
your opinion (or abuse) to me by email. so the news bandwidth won't be
wasted (except this one!).

Thanks,

P.S. I would also like to know, is there any one config their SPARCstations
to a message-passing MIMD multicomputers rather than just merely LAN-
based networking workstations?

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Yin-Chih Lin                            Industrial Technology Research
email: lycmit@x1sun6.ccl.itri.org.tw    Institute  (ITRI)
phone: 886-35-917331
fax:   886-35-917503                    Computer & Comm. Research Labs.(CCL)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Newsgroups: comp.arch
From: willmore@iastate.edu (David Willmore)
Subject: Re: What's in a name?
Organization: Iowa State University, Ames IA
Date: Tue, 28 Jul 1992 23:35:25 GMT

mcvey@mpr.ca (Iain McVey) writes:
>The only thing CD's have done for sound reproduction is removed media
>noise.

Also, the lack of several playback and recording related distortions,
i.e. flutter.

>brick wall filtering introduces annoying harmonics, and your ear does
>hear quantization noise.

That's why I'm glad it hasn't been used in even the cheapest CD player 
for several years.  If you music is *very* quiet and you *really* crank
up the volume, yes, you can hear it.  Sheesh....

>Don't get me wrong, I own a CD player and love the crisp sound you get
>every time, and the fact that I don't have to wipe down the discs each
>time I play them.  I also realize that a $200 CD player will definitely
>out perform a $200 turntable.

This is where the comparison comes.  I smaller amount of money can give
better performance when used to produce a RISC processor than it could
to produce a CISC processor.  This is only true on the low end.  When 
you get to the high end, anything goes.

>                There is a warmth that comes from vinyl that is very
>difficult to produce from a CD player.

Most of this "warmth" can be reproduced on a CD by taking the low level
signal likes out of the CD player and placing them near AC power lines.

>People tend to attack the cpu in DOS boxes, and worry over backwards
>compatiblity.  Perhaps we should look to improve the rest of the system
>as well.

Running DOS, there has been little stress on thest other components until
recently.  Now that people demand diffenent things from their systems,
i.e. Windows performance, it is no suprise that systems long since tuned
for DOS use would not be the best machine for a completely different OS
environment.  Is there suprise here?

>- Iain -

David Willmore
willmore@iastate.edu
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: What's in a name?
Date: 31 Jul 92 14:10:24 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <josef.712480693@uranium>, mollers.pad@sni.de (Josef Moellers) writes:

| There's more to this than just the executables. But even then,
| recompilation isn't so very simple. Things that spring to my mind are:
| word size, signed vs. unsigned characters (in case Your compiler changes
| with the hardware, which it usually does), pointer alignment ...
| Then the differences in the operating system that might/will change.
| Perhaps the new architecture doesn't support Your ancient language
| ("Soory sir, wo don't do FORTRAN/IV any more")?

  Hey, I said source. Anything other than ANSI C is some proprietary
object format, right? ;-)
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Yes, in my youth I wrote COBOL. But I didn't compile.
From: mkahn@pima.sedona.intel.com (Mitch Kahn)
Newsgroups: comp.arch
Subject: Re: What's in a name?
Date: 21 Jul 92 17:51:04 GMT
	<1992Jul20.093703.1@zodiac.rutgers.edu>
	<1992Jul20.171724.12893@mips2.ma30.bull.com>
Organization: /eng/eng3/mkahn/.organization
In-reply-to: sullivan@granite.ma30.bull.com's message of 20 Jul 92 17:17:24 GMT

Tsullivan@granite.ma30.bull.com (Marie J. Sullivan) writes:


] In article <1992Jul20.093703.1@zodiac.rutgers.edu> leichter@zodiac.rutgers.edu writes:
] >
] >So, at this time, 80586 MIGHT be registered for future use by Intel.  (The
] >PTO - Patent and Trademark Office - holds such "placeholder" registrations in
] >confidence; if you were to use 80585, it would be up to Intel to tell you to
] >stop.)  It is extremely unlikely that Intel has registered 80686.
] >
]
] I thought the whole issue of Intel using P5 (or some such designation)
] as opposed to 80586 was that it was ruled that a number could _not_ be
] trademarked, so AMD was allowed to use '386' without restriction...
]
]

Yes, this is the right answer...
--
|  Mitch Kahn              | "I hope you know that this will go down on |
|  mkahn@sedona.intel.com  |  your permanent record..."                 |
*************************MY OWN OPINIONS*********************************
From: pauls@apple.com (Paul Sweazey)
Newsgroups: comp.arch
Subject: Re: BUSES
Date: 23 Jul 92 19:19:27 GMT
Organization: Apple Computer

In article <1992Jul23.092211.18462@nuscc.nus.sg> eletanjm@nuscc.nus.sg 
(TAN JIN MENG) writes:
> With all this talk about current and future buses for desktop machines
> (EISA, TurboChannel etc), a lot of concern seems to be on the speed of
> the bus (as opposed to for example interrupt/device management or the
> ability to use different speed devices efficiently).
> 
> It seems to me that many if not most applications do not need 
(relatively 
> speaking) such a high bandwidth.

Over the last decade or so processors, RAM, and disk storage have all 
increased in speed or capacity by two or three orders of magnitude.  Where 
have buses gone during the same period?  Not very far, not in real-world, 
affordable systems.  This imbalance has turned modularity into a myth.  If 
add-in hardware were both blindingly fast and incredibly cheap then 
modular computers might be a much more interesting market.

Paul Sweazey
Internet: pauls@apple.com
AppleLink: SWEAZEY
(408) 974-0253
From: mike@pacsoft.com (Mike Stefanik)
Newsgroups: comp.arch
Subject: Re: Productivity != SPECmarks, crap-compatibility - what for? (Was: Re: What's in a name?)
Date: 21 Jul 92 17:39:19 GMT
Organization: Pacific Software Group, Riverside, CA
X-Newsreader: Tin 1.1 PL4

davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
:
: People upgrade because they don't want to wait. There are limits to
: how fast a computer needs to be *for a given task*, if the output if
: delivered in realtime to a human. That limit is "how fast can the output
: device process the info?"
: 
:   If people feel that they are waiting for output they will want a
: faster machine. Waiting for a computer is not a productive thing to do.

A faster machine does not mean a new machine.  It could mean increasing
the amount or memory, a faster disk, or any number of things.

My point was that this need to constantly purchase "newer, faster, better"
processors is created by the media and salescritters... they prey upon the
emotions of the consumer, convincing him that unless he upgrades his antiquated
system, a horrible fate awaits him.  Their chant is well known: "no longer in
production", "no longer supported", "too slow to run your software".  The
bottom line is that the customer is held hostage to the very machine that was
supposed to set him free.
-- 
Mike Stefanik  mike@pacsoft.com  ...!uunet!pacsoft!mike  (+1 714 681 2623)
Pacific Software Group, Riverside, CA
Newsgroups: comp.arch
From: dow@nova2.stanford.edu (Keith Dow)
Subject: Backplane Information Please
Organization: Stanford University
Date: Wed, 22 Jul 1992 16:09:32 GMT


	Could someone please tell me where to get information on high
performance backplane design?  Thanks.
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: Productivity != SPECmarks, crap-compatibility - what for? (Was: Re: What's in a name?)
Date: 21 Jul 92 18:35:57 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

davidsen@crd.ge.com (bill davidsen) writes:
>  People upgrade because they don't want to wait. There are limits to
>how fast a computer needs to be *for a given task*, if the output if
>delivered in realtime to a human. That limit is "how fast can the output
>device process the info?"
>
>  If people feel that they are waiting for output they will want a
>faster machine. Waiting for a computer is not a productive thing to do.

	Of course, we software people conspire to make sure that as faster
machines become available, we write bigger and more powerful software to
use up that extra speed.  Our latest successful operation was GUI's.
In a few years, the hardware guys may manage to make even X+OL or X+motif
acceptably fast, and we'll either add another layer on top, or add speech
recognition (now there's an infinite cycle suck!), or real 3-d windows, or
VR, or some such until we've put those chip designers back in their places...
We're not sure if object orientation will suck enough cycles to make our
time invested in it worthwhile - maybe we'll have to use more run-time binding
... ;-) ;-)

-- 
"Rev on the redline, you're on your own; seems like a lifetime, but soon it's
 gone..."  Foreigner
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
From: kitchel@moray.dpsi.com (Sidney W. Kitchel)
Subject: Re: Dinosaur noises (was: Re: dinosaur horsepower)
Organization: Data Parallel Systems, Inc
Date: 29 Jul 92 14:32:41 GMT

dpbsmith@world.std.com (Daniel P. B. Smith) writes:

>Along the same lines, I, for one, would certainly pay good money for a
>recording of dinosaur NOISES.
>The waltz-time 407 (kchunk-Pink kchunk-Pink glup kchunk-Pink kchunk-Pink glup)

	Some fairly early computers came with speakers. One of these
was the CDC 1604. Most operators kept the volume way down, but I can
recall going into the machine room at Sunray DX Oil ca. 1965 and
hearing the science-fiction-esque music of the CDC beast.

							--Sid

--
Sidney W. Kitchel  	    kitchel@cs.indiana.edu, kitchel@dpsi.com
Data Parallel Systems, Inc.  ============||  DPSI  ||===============
4617 E. Morningside Drive	                      (812) 334-8100
Bloomington, Indiana,  47408  USA		FAX:  (812) 334-8121
From: lindzey@hal.com (Gardner Lindzey)
Newsgroups: comp.arch
Subject: Re: Graphics Systems
Date: 24 Jul 92 16:49:33 GMT
Organization: HaL Computer Systems, Inc.

In article <1992Jul20.200401.14637@awdprime.austin.ibm.com> repass@futserv.austin.ibm.com (James Repass) writes:
>
>
>CPU <-> Bus <-> Display Adapter (DA)
>CPU <-> Bus <-> DA with memory
>CPU <-> Bus <-> DA with memory and processing (CPU)
>CPU <-> Bus <-> DA with memory and CPU
>CPU <-> Bus <-> DA with memory and CPU <-> Bus <-> Display Adapter
>                                  /                             /
>  /------------------------------/                             /
> /                                                            /
>/                                   /------------------------/
>CPU <-> Bus <-> Display Adapter (DA)
>
>
>Where will it END?
>Where WILL it end?
>
CPU->Monitor

lindzey@hal.com