HDTenEightyP/NetNews huggingface dataset:
From: Josef Moellers <mollers.pad@sni.de>
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: Thu, 30 Jul 1992 07:16:42 GMT
Organization: Siemens Nixdorf Info.Sys. AG, Paderborn, Germany

In <nn2q62k@zuni.esd.sgi.com> tarolli@tenno.boston.sgi.com (Gary Tarolli) writes:

>In article <13v76qINN1ap@rodan.UU.NET>, avg@rodan.UU.NET (Vadim Antonov) writes:
>|> Did anybody thought that bcopy has nothing to do with the central processor?
>|> I'd prefer to have a machine which thinks of it as of a pair of DMA-s.
>some people think DMA is a dirty word....

>|> It makes the whole system more "consistent" from the OS point of view.
>|> There is no need to pump unchanged words through all those CPU
>|> data caches effectively flushing them. 
>how do you then keep your data caches consistent with memory (in case some
>of the bcopy's destination bytes were in the cache)?  If you flush or invalidate
>your data cache, its not any different than pumping those words thru the cache.

But if Your cache does bus snooping, it is!
Just imagine You have a 4K cache filled with data totally unrelated to
the stuff You want to transfer in Your 4K bcopy!
-- 
| Josef Moellers		| c/o Siemens Nixdorf Informationssysteme AG  |
|  USA: mollers.pad@sni-usa.com	| Abt. STO-XS 113	   | Riemekestrasse   |
| !USA: mollers.pad@sni.de	| Phone: (+49) 5251 835124 | D-4790 Paderborn |
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Request Info Re Bus Trends & Intel 486s
Organization: Intel Corp., Hillsboro, Oregon
	<1992Jul20.075331.18759@PA.dec.com>
	<1992Jul21.001901.29582@theus.rain.com>
Date: Fri, 24 Jul 1992 03:27:55 GMT

>>[Burkhard Neidecker-Lutz]
>>Can you explain which *desktop* applications need peer-to-peer communication ?
>>I.e. what is wrong with going through main memory ?
>
>[John Theus]
>To use today's favorite buzz word: multimedia.
>
>If I want to do HDTV in a window that comes in from a disk or some outside hose,
>why burden main memory with something it doesn't need to be involved in. Plus
>the added complexity of scheduling it so you don't miss the frame rate
>requirements.

First you'll put video on your screen.

Then you'll want special effects: things like zooming in on a
particular speaker (or the papers on his desk) in a video conference,
things like cropping speakers from different video inputs and
superimposing them into a virtual conference room.

I'm not sure what effects will be most popular, but I am sure that the
effects will be used, if systems can provide them.

And the wheel will keep on turning:

    Nonstandard video on coprocessors.

    Standard software video on the CPU.

    Coprocessors to accelerate the video standards.

    New features and special effects added that will only run on 
    	non-standard video coprocessors.

    Standard special effects in software only on standard CPUs.

    Coprocessors to accelerate the standard video special effects.

    ...

    
--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
Newsgroups: comp.arch
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Solaris (was: Sun 600MP Benchmark Anomaly)
Date: Sun, 26 Jul 1992 00:32:54 GMT
Organization: U of Toronto Zoology

In article <nodh0gc@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>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.
>    ... 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...

Analogies to this occur in software too.  In the early days of C News,
we (specifically, Geoff) experimented briefly with fine-grain locking for
the control files.  We discarded it immediately when we saw what it did
to performance.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
From: cmr@world.std.com (Charles M Richmond)
Subject: Re: dinosaur horsepower
Organization: Integrated International Systems Corp. One Longfellow Place, Suite 3309, Boston, Ma.
Date: Thu, 30 Jul 1992 00:18:17 GMT

kludge@grissom.larc.nasa.gov ( Scott Dorsey) writes:

>In article <Bs5L03.3tH@exnet.co.uk> dhd@exnet.co.uk (Damon) writes:
>>In article <1992Jul28.155852.23608@sctc.com> smith@sctc.com (Rick Smith) writes:
>>>I was a fan of papertape myself. (5 points: can you spot the pun?)
>>
>>No, but I'm sure I'll burst out laughing when you list out the hole joke.

>What an uncultured chad.
>--scott

Damn, when you all Hollerith , you are the Baudest.


Charlie

I used to play with a "Bull" serial card punch (sold by NCR Model 576)
that had a logic "0" that ranged from 0 volts to 6.5 volts... the logic "1"
was anything from 7 volts to 40 volts and the friction drive print 
mechanism!!!! I seem to remember that they could punch about 900 cards per
hour.


-- 
*****************************************************************************
*  Charles Richmond 	Integrated International Systems Corporation        *
*  cmr@world.std.com	(Temporary) crichmond@mr4dec.enet.dec.com           *
*  Specializing in UNIX, X, Image Processing, and Communications.           *
From: jarrad@vax1.mankato.msus.edu
Newsgroups: comp.arch
Subject: comp.arch
Date: 22 Jul 92 13:48:22 GMT
Article-I.D.: vax1.1992Jul22.074822.2050
Organization: Mankato State University

subject:  REGISTER RENAMING
    I am looking for material regarding register renaming.  I am a graduate
student and I need all the information I can get.  Please send mail.
.......
E_MAIL ID:  MKVAX1
USER ID:  JARRAD
Newsgroups: comp.arch
From: osborne@cs.tamu.edu (Aaron Osborne)
Subject: Looking for Trace Driven Simulator
Keywords: trace driven cache simulation
Organization: Computer Science Department, Texas A&M University
Date: Mon, 27 Jul 1992 17:40:07 GMT

Hi All,

I am looking for a trace driven simulator to do performance 
evaluation of various cache configurations on a RISC type machine.  
Any pointers to where this type of simulator might be found will 
be greatly appreciated.  Thank you very much.

Aaron Osborne
osborne@cs.tamu.edu

From: daryl@hpcuhe.cup.hp.com (Daryl Odnert)
Date: Tue, 21 Jul 1992 21:45:46 GMT
Subject: Code Repositioning on MIPS Systems?
Organization: Hewlett Packard, Cupertino
Newsgroups: comp.arch

Could someone please send me or post a high level description of
the profile-based optimization capabilities of the MIPS compilers/linker.

For example, I believe the MIPS system can support code repositioning
based on application profile measurements to reduce I-cache misses
and branch penalties.  Can someone verify this?  Any pointers to
published documentation on these optimizations would also be appreciated.

Thanks,
Daryl Odnert     daryl@cup.hp.com
Hewlett-Packard
California Language Lab
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: BUSES
Date: 24 Jul 92 13:18:37 GMT
Organization: Purdue University Statistics Department

In article <BrusoI.2so@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <1992Jul23.092211.18462@nuscc.nus.sg> eletanjm@nuscc.nus.sg (TAN JIN MENG) writes:

			.......................

>>Also, if I get my file within 0.5 sec as opposed to 1.0 sec, will I
>>notice enough to pay for the hardware? 

>If you get a hundred files in 50 seconds as opposed to 100, you will notice.

If you do not notice the difference in getting your file in .5 sec, you have
an unusually slow reaction time.  With a useful window system, this is a
real major nuisance.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
From: jvm@hpfcso.FC.HP.COM (Jack McClurg)
Newsgroups: comp.arch
Subject: Re: VAX MIPS (was Re: Proposal: Computer History Project)
Date: 30 Jul 92 03:20:51 GMT
Organization: Hewlett-Packard, Fort Collins, CO, USA

> >Aren't SPECmarks computed relative to a VAX 780? Is there still one of these
> >machines somewhere that gets powered up every year or so to run a new set of
> >tests?
> 
> Of course, there is a VAX 11/780 at the Bureau of Standards, kept under a
> big bell jar filled with inert gas kept at a constant temperature; and
> they turn it on every time somebody needs to compare their VAX 11/780 MIPS
> against the official standard.
>     :-), just in case...
> 

Of course.  This machine is known as the Platinum VAX.

Jack McClurg
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: Graphics Systems
Date: 30 Jul 92 10:42:50 MDT
Organization: Utah State University

In article <1392@dms.agames.com>, albaugh@dms.agames.com (Mike Albaugh) writes:
> the sort of feel that makes one chuckle at
> comp.arch postings that talk about "real time" in terms of sub _milli_second
> interrupt latencies :-)

On the subject of interrupts, it seems to me that it's the _modern_
processors that have clunky interrupt handling. Consider:

1965, PDP-8: Processor disables interrupts,
             Saves program counter,
             and jumps to a fixed location to execute code to figure out what 
             caused the int.
             The first thing this code has to do is save the accumulator and
             processor status.
             For complex systems, the code to figure out which device
             caused an interrupt can be quite lengthy (it is usually 1/3
             unconditional skips)
1970, PDP-11: Processor fetches a vector telling it what caused the int,
              Saves program counter,
              Saves processor status,
              Fetches new processor status (giving it updated IPL),
              Fetches new program counter,
              and jumps to the interrupt service routine.
              The interrupt service routine still has to save registers
              it uses.
1978, VAX: Adds a separate stack pointer for processing interrupts so
           that non-interrupt code doesn't have to worry as much about
           how much stack space is used by interrupts (a lot under VMS).
           The interrupt service routine still has to save registers it
           uses.
1992, Alpha: See PDP-8, except there is no processor status to save.
             In addition to figuring out what caused the interrupt, the 
             code executed must figure out the new interrupt priority
             level; this was simple on the -8, since there are only two
             (enabled or disabled).

I realize that Alpha machines will have instruction caches and the RISC
guys generally consider instruction fetches to be free, but I don't think
the interrupt-handling code will generally be in cache; if it is, the
system is probably spending too much of its time processing interrupts.
At least the CISC machines generally have the decency to figure out which
device caused the interrupt and go directly to the service routine without
a lot of fuss and bother.

Roger Ivie
ivie@cc.usu.edu
From: tomw@orac.esd.sgi.com (Tom Weinstein)
Subject: Re: Request Info Re Bus Trends & Intel 486s
Reply-To: tomw@esd.sgi.com
Organization: Silicon Graphics Inc.
	<id.TJRR.XR8@ferranti.com>
Date: 25 Jul 92 17:40:38

In article <id.TJRR.XR8@ferranti.com>, peter@ferranti.com (peter da silva) writes:

> Why is it that backplanes aren't more common on the desktop? Even for
> the PC world, they're available (under the ugly name "passive
> motherboard"), and until the IBM-PC came out they were the norm for
> multi-board systems (you had either single-board CPUs or S100 or
> equivalent). The only exception was the Apple II, and then the IBM-PC.
> Is it just tradition or is there something that makes a motherboard
> system inherently better?

I think the important word here isn't "better", it's "cheaper."  With
motherboard, it's easier to put your system in a smaller box, use less
board space, and fewer connectors.  All that adds up to lower production
costs.

--
Love is a conveyor belt of   |   Tom Weinstein  tomw@orac.esd.sgi.com
warmth  -- Jackie Chan       |                  tomw@bears.ucsb.edu
Newsgroups: comp.arch
From: pettengill@cvg.enet.dec.com ()
Subject: Re: 64-bit CPU vs 2 x 32-bit CPUs
Reply-To: pettengill@cvg.enet.dec.com ()
Organization: Digital Equipment Corporation
Date: Sat, 25 Jul 92 05:59:44 GMT

In article <l7133mINN75s@spim.mips.com>, mash@mips.com (John Mashey) writes:

|>2) A few applications exist where pushing 64-bit integers around
|>conveniently might have good gains, either due to 64x64->128
|>multiplies, or just puhsing data 2X faster conveniently.

Not all 64-bit integer operations involve numbers.  I don't know about
other architectures, but the Alpha architecture includes an instruction
or two that allows character compares and related operations to be done
8 octets at a time.  In particular, CMPBGE does 8 bytewise compares in
parallel.

I'm sure that there are a number of other places where 64-bit registers
can be put to good use even when the address space and the integers in
general only use 32 or maybe even 16 bits.  (I've been thinking about
the design of a PDP-11 emulator, and one option is to put all the general
registers in two 64 bit registers...)

mulp
DEC
Newsgroups: comp.arch
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Symmetric MP
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 23 Jul 1992 18:14:31 GMT

In article <josef.711890540@uranium>, mollers.pad@sni.de (Josef Moellers) writes:
> ...
> In the early days of UN*X, source code flowed quite freely between
> interested parties (modtly universities and other ersearch institutes),
> because there was no commercial interest. Nowadays every single idea to
> "enhance" UN*X spells "$$$", so everyone wanting to do MP will have to
> roll their own dice.


Maybe not, if the very-cheap BSDI and the completely free Jolitz versions
survive the paniced AT&T-USL legal attack.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.arch
From: uad1077@dircon.co.uk (Ian Kemmish)
Subject: Re: Graphics Systems
Date: Thu, 23 Jul 1992 18:25:30 GMT

rthomson@mesa.dsd.es.com (Rich Thomson) writes:

>In article <4398@rosie.NeXT.COM>
>Of course, everything is also as slow as the CPU.  Isn't this the kind
>of system that caused people to create graphics accelerators in the
>first place (i.e. the central CPU was the bottleneck)?  What does NeXT

It seems time to remind people about that marvellous paper, ``The
Computer Graphics Wheel of Re-incarnation'', that charted the
history of people moving graphics in and out and in and out of
special purpose h/ware (and it was written sometime around the end
of the sixties!).  I *think* Ivan Sutherland was the author, but
I wouldn't swear to it (*especially* on the net).

Mind you, if SGI could produce an affordable Reality Engine, that would
kee p me happy for a few months:-)

-- 
Ian D. Kemmish                    Tel. +44 767 601 361
18 Durham Close                   uad1077@dircon.co.uk
Biggleswade                       uknet!dircon!uad1077
Beds SG18 8HZ United Kingdom
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: What's in a name?
Date: 28 Jul 92 15:33:47 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Jul27.214015.4138@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) writes:

| The segmentation scheme is crucial to the chip; you can, for example, have a
| task with 16-bit and 32-bit segments.  I.e., there isn't a "32-bit mode,"
| instead, there are 32-bit *segments*.
| 
| The chip would have been far worse had they come up with two seperate modes
| for the '386.

  Please clarify what you mean by this one. If you mean data access
modes, I seem to remember using 32 bit prefixes to select 32 bit data
access operation (real mode), so it's not that. Does that mean a 16 bit
segment is a data segment and data accesses in it are 16 bit, or that
addresses relative to that segment are only 16 bit offsets, or that I
have 16 bit code segments where addresses and data access both behave
differently, or what?

  I will have to see if I can find my processor manual, because this
doesn't fit with anything I remember about the chip. Bear in mind I only
did assembler for this chip for a few months until a 32 bit o/s came out
(about 1987).
-- 
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: amf@amfent.Gwinnett.COM (Andy Feibus)
Newsgroups: comp.arch
Subject: Re: What's in a name?
Date: 21 Jul 92 14:07:02 GMT

leichter@zodiac.rutgers.edu writes:
> Speaking only for US law, a trademark becomes protected by use "in trade".  I
> is not even necessary to register it, though that may be useful in certain
> circumstances.  Trademarks are marked "TM"; registered trademarks are marked
> "R in circle".  If you look around, you'll see that many common trademarks
> have not been registered - like Unix, for example.
If you haven't already heard from USL lawyers, UNIX is a registered trademark
of UNIX System Laboratories, Inc.  Has been for a long time.

-- Andy.
Newsgroups: comp.arch
From: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: comp.arch
Subject: VAX MIPS (was Re: Proposal: Computer History Project)
Keywords: software, history, computer
Date: 27 Jul 92 21:05:09 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: hobbes.ucsc.edu


In article <1992Jul25.214508.4312@fasttech.uucp> zeke@fasttech.uucp (Bohdan Tashchuk) writes:
>Aren't SPECmarks computed relative to a VAX 780? Is there still one of these
>machines somewhere that gets powered up every year or so to run a new set of
>tests?

Of course, there is a VAX 11/780 at the Bureau of Standards, kept under a
big bell jar filled with inert gas kept at a constant temperature; and
they turn it on every time somebody needs to compare their VAX 11/780 MIPS
against the official standard.
    :-), just in case...

-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle
Newsgroups: comp.arch
From: jeff@endeavor.ColumbiaSC.NCR.COM (Jeff McElroy x6996)
Subject: Re: Sun 600MP Benchmark Anomaly
Reply-To: Jeff.McElroy@ColumbiaSC.NCR.COM
Organization: NCR Multiprocessor Systems Business Unit
Date: Thu, 23 Jul 92 14:55:01 GMT

In article <l6c2l5INNcds@appserv.Eng.Sun.COM>, limes@ouroborous.Eng.Sun.COM (Greg Limes) writes:
|> In article <l6asqqINNhvm@exodus.Eng.Sun.COM> jackv@orpheus.Corp.Sun.COM (Jack F. Vogel) writes:
|> | Bravo! Guy is, of course, completely correct. I have always objected
|> | to speaking of the 4.1.2 OS as asymmetric. That should, I feel, designate
|> 
|> So, even though the only asymmetricity in the kernel is the fact that
|> it expects "cpu0" (at MID=8) to boot the system, I am not allowed to
|> call SunOS 4.1.2MP a "symmetric" multiprocessing system.
|> 

So, how many processors can take and service interrupts?  


|> 
|> -- Greg Limes [limes@eng.sun.com]
|>    Galactic Space Cadet

-- 
-Jeff McElroy
UUCP:	jeff.mcelroy@ColumbiaSC.NCR.COM   -or-  ncrcom!ncrcae!endeavor!jeff
PHONE:	803.791.6996  - main number at 803.796.9250  -  fax at 803.739.7317
USPS:	NCR MCPD Columbia, 3325 Platt Springs Road, West Columbia, SC 29170
From: scott@electron.amd.com (Scott McMahon)
Newsgroups: comp.arch
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Keywords: interleaved memory systems, processor support
Date: 24 Jul 92 04:59:44 GMT
Organization: Advanced Micro Devices, Austin TX.

In article <2373@nic.cerf.net> davsmith@nic.cerf.net (David Smith) writes:
| In article <BruruF.2E4@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
| >Uh, you are very much behind the times.  Few modern CPUs will block waiting
| >for a memory access unless/until they actually need the data.  Admittedly,
| >a lot of them can't initiate another memory access meanwhile -- or at
| >least, another data access -- but some can, and buses that support multiple
| >simultaneous memory transactions are old news.  
| 
| Sigh...The dangers of simplifying for clarity.  I didn't feel like getting
| into a long discussion of register scoreboarding and so forth.  However,
| if it can't initiate another fetch then as far as the memory system is
| concerned it's hanging on the first one.  That's the critical issue for a 
| using an interleaved memory system.  

The Am29030 and Am29035 microprocessors support a feature called Early
Addressing, which is similar to what you describe (I certainly think
it is a good step in the right direction).

During burst transfers (instruction fetching, or load/store multiple
operations) the processor is capable of providing addresses
independent of the memory system's transfer acknowledge (RDY). Here is
how how it works (an instruction fetch example will be given - the
same applies for data accesses):

  1. The processor drives the REQ (REQuest), A(31:0) (Address), BURST
     (BURST mode access), and other signals indicating an instruction
     fetch is beginning.

  2. Before/during the return of the first instruction, the memory
     system asserts the ERLYA (EaRLY Address) input. This causes the
     processor to drive the address+8 on the next cycle. The only
     other condition for entering the early address mode is that the
     initial address be quad-word aligned (A(3:0) = 0). This is
     *ALWAYS* the case at the beginning of an instruction fetch in the
     Am29030/35. For data accesses not starting at a quad-word aligned
     address, the processor increments addresses by 4 until the
     alignment criteria is met. 

  3. The memory system now controls the incrementing of the address
     bus independent of data transfer. When it returns an instruction
     or data item it asserts RDY; when it wants the next address it
     asserts ERLYA.

This feature was added to assist designers in interleaved memory
systems. The intent is to provide all even-bank addresses as the
memory system requires.

A two-way interleaved system is pretty trivial to design with this
feature.

-Scott
--
	Scott McMahon
	Advanced Processor Development, Am29030 Team
	Advanced Micro Devices
	scott@amd.com
From: jarrad@vax1.mankato.msus.edu
Newsgroups: comp.arch
Subject: Register Renaming
Date: 22 Jul 92 13:54:26 GMT
Article-I.D.: vax1.1992Jul22.075426.2051
Organization: Mankato State University

Please mail me any material you have on register renaming.  I am planning to
write my thesis on REGISTER RENAMING
MAIL to MKVAX1
USER iD : JARRAD
Newsgroups: comp.arch