HDTenEightyP/NetNews huggingface dataset:
From: Bob_Beckwith@NeXT.COM (Bob Beckwith)
Newsgroups: comp.arch
Subject: Re: Machines with cond. assignment instruction?
Date: 24 Jan 93 21:22:35 GMT
Reply-To: Bob_Beckwith@NeXT.COM (Bob Beckwith)

In article <1993Jan21.163607.31684@watson.ibm.com> pradeep@watson.ibm.com  
(Pradeep Dubey) writes:
> Are there announced machines (specially micros) with
> some conditional assignment instruction.  I mean
> instruction such as the following:
> 
> MovCond R1, R2, R3 /* if (c1) R1 <- R2 else R1 <- R3 */
> 
> where, c1 refers to some result of some previous compare.
> 
> Any pointers to such machines or any quantitative evaluation
> of usefulness of this instruction in the specific context
> of some machine would be appreciated.

Unless I'm mistaken, the Multiflow Trace machines had conditional assignment  
instructions. While you certainly wouldn't classify them as micros, they're  
there (or at least were, at one point :-( ). Any ex-Multifloyd's out there  
(DBP? PKR?) might be able to provide more information.

  --Bob

Bob_Beckwith@NeXT.COM
Digital Hardware Engineering
NeXT Computer, Inc.
900 Chesapeake Drive
Redwood City, CA 94063 USA
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.arch
Subject: Re: Machines with cond. assignment instruction?
Date: 22 Jan 93 11:19:31 GMT
Organization: Department of Computer Science, U of Copenhagen

pradeep@watson.ibm.com (Pradeep Dubey) writes:

>Hello Everyone,
>Are there announced machines (specially micros) with
>some conditional assignment instruction.  I mean
>instruction such as the following:

>MovCond R1, R2, R3 /* if (c1) R1 <- R2 else R1 <- R3 */

>where, c1 refers to some result of some previous compare.

>Any pointers to such machines or any quantitative evaluation
>of usefulness of this instruction in the specific context
>of some machine would be appreciated.

On the ARM processors all instructions are conditional, so you can
have a MOV<C> R1,R2, which will move R2 to R1 if the condition is
true. To simulate the 3-argument MOVCond you describe, the sequence

	MOV    R1,R3
	MOV<C> R1,R2

or

	MOV<C>  R1,R2
	MOV<~C> R1,R3

can be used. In present ARM implementations these are equally fast.

Digitals Alpha RISC also have conditional moves, as does the proposed
new generation of SPARC. HPs PA-RISC allows some instructions to
conditionally nullify the next instruction. So a 3-argument
conditional move can be implemented with something like

	--- 	  skip if C	\ previous instruction that determines C
	MOV R1,R3 skip always
	MOV R1,R2

with a disclaimer about notation. The idea is that when C is true, the
next instruction is nullified, so MOV R1,R2 is executed. When C is
false, MOV R1,R3 is executed and the MOV R1,R2 nullified.

The designers of these processors obviously felt that it was worth the
effort. It is especially interesting to see that conditional moves are
added to the new SPARC architecture even though they were not part of
the original design. It is difficult to give a good quantitive measure
of the usefulness, but one could try to count the frequency of such
instructions in optimized code.

	Torben Mogensen (torbenm@diku.dk)
Xref: sparky comp.arch:12407 comp.sys.hp:15325
From: crusoe@cs.tu-berlin.de (Andre' Zehl)
Newsgroups: comp.arch,comp.sys.hp
Subject: HP-PA softw. virtual addr. translation HOW ?
Date: 27 Jan 1993 17:37:53 GMT
Organization: Technical University of Berlin, Germany
NNTP-Posting-Host: zaphod.cs.tu-berlin.de
Keywords: HP-PA

I'm working on a preparation on the HP-PA RISC Architecture.I'm desparately
trying to figure out, how you administer the virtual to physical address
translation. 

Unfortunately HP's description of this translation is very vague. They
describe, that the virtual page number is hashed, thus providing a pointer
in a hashtable (the PDIR INdex) which provides a pointer in the physical
page directory (to chained PDIR-Entrys), where the page attributes are
stored (NOT the physical page number).

The physical page number (ppn) is identical with the index from the
hashtable. But this only makes sense, if it's not the virtual page number (vpn)
which is hashed, but the physical page number, coming out of the
hardware translation? IS THIS SO ? Is the PDIR Index of the hashtable vpn 
the hashed ppn or the hashed ?

I need help _very_ urgently, so evry little hint is appreciated _very_ much!
Thank you very much in advance! Please e-mail reply.
-- 
Andre'_________________________________________________________________________
							 crusoe@cs.tu-berlin.de
Newsgroups: comp.arch
From: nrr@sei.cmu.edu (Neal Reizer)
Subject: Multiported RAM arbitration
Organization: The Software Engineering Institute
Date: Fri, 22 Jan 1993 16:27:59 EST


I have two questions regarding multiported RAMs:

1)  At what point does the arbitration for access to the RAM occur, outside
the RAM, or at the actual address bit?

2)  How are simultaneous accesses to the same addresses handled in the:

	a) read-read case

	b) read-write case

	c) write-write case,

where read-read implies two processors reading from the same location, etc.



Thanks for your help


Neal Reizer				nrr@sei.cmu.edu
Software Engineering Institute		(412) 268-2854
From: tremblay@flayout.Eng.Sun.COM (Marc Tremblay)
Newsgroups: comp.arch
Subject: Re: TFP announcement from SGI?
Date: 28 Jan 1993 18:04:54 GMT
Organization: Sun
NNTP-Posting-Host: flayout
Keywords: sgi arch tfp mips

Has SGI given any "real" numbers on the TFP (aka SPECfp92 *and*
SPECint92). All I have seen in the announcement are peak MFLOPS
for one processor and peak MFLOPS * number of processors for MP systems...
Also, not much was said on integer performance, I suspect that it is
probably because it is below the R4400's SPECint92 number.

- Marc Tremblay
Sun Microsystems.
From: stever@anago.cse.ogi.edu (Steve Rehfuss)
Newsgroups: comp.arch
Subject: DSP chip design
Date: 27 Jan 93 23:20:39 GMT
Article-I.D.: ogicse.49154
Distribution: world
Organization: Oregon Graduate Institute - Computer Science & Engineering

DSP chips are optimized for a certain class of algorithms, relative to
general purpose microprocessors.  What's a good reference on the architectural
tradeoffs being made vis-a-vis the class of algorithms targeted?

Thanks in advance,
Steve Rehfuss
stever@anago.cse.ogi.edu

Newsgroups: comp.arch
From: jan@vesta.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen)
Subject: Re: Known hardware bugs.
In-reply-to: ferriere@gr.osf.org's message of 20 Jan 93 15:09:08 GMT
Organization: Inst. f. Neuroinformatik, Ruhr-Universitaet Bochum, FRG
Date: 21 Jan 93 14:38:27

In article <9301147@comp.compilers> ferriere@gr.osf.org 
(Francois de Ferriere) writes:

   I'm looking for known hardware bugs.

Do microcode bugs count as well?
If so, then there was (and I expect there still is) a nice one in the
implementation of the REI instruction on the VAX11/780. Briefly, when
returning from an AST, which is (among other things) done by REI, it is
confused when just at that time another AST is queued, and restores wrong
stack pointers into some registers (disclaimer  all from ageold memory...).
This bug lay hidden for at least five years, until a lot of people suddenly
had unexplained and irreproducible crashed in standalone BACKUP, which works
almost entirely with ASTs and exercises the system...The fix was to add a
sanity check to the AST delivery code that would readjust one of pointers
if it contains an "impossible" value to something valid. Maybe somebody
with access to the VMS source CD could check whether that fix is still in?
How about OpenVMS on AXP :)??

	Jan
Newsgroups: comp.arch
From: hyatt@cis.uab.edu (Robert Hyatt)
Subject: Re: Need references on architecural comparison
Organization: University of Alabama at Birmingham
Date: Wed, 27 Jan 1993 01:59:00 GMT

In article <1993Jan26.234628.23217@zip.eecs.umich.edu> ashish@blueridge.eecs.umich.edu (Ashish Mehra) writes:
>
>I would appreciate if the knowledgable amongst you
>can give me some pointers to articles on architectural
>comparisons focusing on context switching overhead and
>interrupt response time. Relevant processor architectures
>are the R2000/3000, SPARC, 68030/40 and 486. Also,
>is there any study done that compared the _relative_
>performance gains of a synchronization instruction
>like test-and-set over pure software mechanisms?
>

What is a "pure software mechanism"???  Assuming you are implementing
a lock for multiprocessors, I haven't seen a pure software approach that
will work.....

-- 
!Robert Hyatt                    Computer and Information Sciences   !
!hyatt@cis.uab.edu               University of Alabama at Birmingham !
Newsgroups: comp.arch
From: kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner)
Subject: Re: Harvard architecture
Organization: University of Kaiserslautern, Germany
Date: Thu, 28 Jan 1993 10:02:06 GMT

From article <1993Jan25.153333.7251@crd.ge.com>, by davidsen@ariel.crd.GE.COM (william E Davidsen):
> 
>   I agree, and I don't have the refference, either.
> 
>   What we had done was bank switching, such that when the CPU did an
> opcode fetch, the M1 cycle, it came from the code bank, and when the CPU
> did any other data access it went in the "data" bank. The program was
> all written in a B offshoot called IMP, so I could easily avoid the self
> modifying code prevalent at that time.
> 
So I wonder:

How was distinguished between the addtitonal fetches ( e.g. address, immediate
operand ) of an instruction, and the true operand accesses ?

It might be done be a decoder who knows about the various instruction lengthes,
but this would be a quite complex piece of hardware. ( appr. halve a processor
or so )

R. Kirchner
Univ of Kaiserslautern, Germany
kirchner@informatik.uni-kl.de
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: ANDF bogosity
Date: 25 Jan 93 14:13:01 GMT
	<1378@taniwha.UUCP>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

>>> On 17 Jan 93 16:42:38 GMT, paul@taniwha.UUCP (Paul Campbell) said:

Campbell> Moreover we all were taught this encryption stuff in
Campbell> undergraduate courses anyway - assuming that people in other
Campbell> countries can't read or understand this stuff is pretty
Campbell> condesending - but then that's the NSA (who I guess assume
Campbell> that the Russians will never think to read the texts :-)

Well, you might have already imagined this, but: the russians have some
of the very best mathematicians around, and they probably are as good as
anything the NSA can get, or even better. Moreover, given the lack of
the immense computer power the NSA has, russian mathematicians have
developed extra ingenuity.

The NSA is concerned about cheap, stupid powers like the yugoslavs or
the iraquis of this world; people who are used to buying weaponry off
the shelf, and then even have some difficulty operating it properly.

The NSA reasoning is that these are 'end-user' powers can get easily
their hands on high quality ready made end-user security tools, then the
NSA has a much harder time monitoring them; if they have to develop
their own tools, the chance of them bungling their design is very much
higher, as is the chance that they will instead be laxer.

Since the NSA detail is surveillance of those powers, they don't give a
damn if restricting the availability of end user quality security tools
also means that private users in the USA or in friendly countries (some
of which, like the UK, have their own impressive record of security
research) get victimized too.
--
Piercarlo Grandi <pcg@aber.ac.uk> c/o Dept of CS
University of Wales, Penglais, Aberystwyth SY23 3BZ, UK
Newsgroups: comp.arch
From: emil@shell.portal.com (emil rojas)
Subject: Re: Harvard architecture
Organization: Portal Communications Company
Date: Tue, 26 Jan 1993 19:18:56 GMT

Nitezki@NiDat.sub.org (Peter Nitezki) writes:

>In article <2B51D662.29834@news.service.uci.edu> jtien@venice.eng.uci.edu  
>(Joe Tien) writes:
>> 
>> Could someone direct me to a good definition of the harvard
>> architecture? Is it dual memory port (each with own set of address and
>> data bus) or is it just dual bus (separate address and data bus used for
>> both instruction and data.)
>> 
>> If possible, I'd prefer some type of reference I can use in my paper,
>> not that I don't trust the infinite wisdom of the net. :-)
>> 

>Basically the second!

>Once it was called Zuse architecture (then von Neumann took over).
>After a while it got a writable control/instruction (as you like it) store  
>and was called Harvard architecture; just to take over in the modern DSP  
>designs.

>Just as a start for argument ;-)


My understanding is that a Harvard architecture consists of two _seperate_
buses, one for data and one for instructions.  I have no references at
hand.  But, Motorola used the term in their lititure describing the internal
buses on the 030 or 040.
--
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Emil Rojas  emil@shell.portal.com (408) 973-0603
Cognisys Software Systems Development
San Jose, CA 95129
Newsgroups: comp.arch
From: tapi9@syma.sussex.ac.uk (Shaun McCann)
Subject: Carnegie Mellon E-Mail Addresses?
Organization: University of Sussex
Date: Wed, 27 Jan 1993 14:32:10 GMT

Hi everyone, just a quickie; can anyone give me the E-Mail addresses of
Andrew Wolfe or John Shen at CMU ?

Many thanks,

Shaun.

------------------------------------------------------------------- 
|       Shaun V. McCann        |                                   |
|VLSI & Computer Graphics Group|mccann_sv@uk.ac.sussex.eaps (JANET)|
|     University of Sussex     |...mcsun!ukc!syma!tapi9 (UUCP)     |
|Falmer  BRIGHTON  BN1 9QT UK  |                                   |
-------------------------------------------------------------------
Newsgroups: comp.arch
From: rsrodger@wam.umd.edu (Yamanari)
Subject: Sales figures on workstation vendors?
Organization: University of Maryland, College Park
Date: Sun, 24 Jan 1993 19:51:51 GMT


	Can anyone give me (or tell me where I might find) the figures
	on workstations sold for Sun, HP, IBM, NeXT, Dec and Data General?

	I'm not sure where else to check.  There is a numbers dispute in
	one of the (of course) advocacy groups.


-- 
	Attempts to lessen the burden of proof in rape trials are an assault 
        	on our civil liberties.  Support equality, not revenge. 
 ---  boycott == coercion == censorship == closed mindedness == cowardice  ---
	Pyramid schemes are illegal unless you're the US government.
Newsgroups: comp.arch
From: merz@ips.id.ethz.ch (Andreas Merz)
Subject: UNIBUS and/or QBUS interface description?
Organization: ETH Zurich (Swiss Federal Institute of Technology
Date: Mon, 25 Jan 1993 18:16:21 GMT

I am looking for documentation for the UNIBUS and the QBUS interfaces.
Where can i find something? (books, files, etc.)

Any help is much appreciated!
-- 
 ---------------> Andreas Merz  /  Internet: merz@ips.ethz.ch <----------------
 ------> Interdisciplinary  Project  Center  for  Supercomputing  (IPS) <------
 <-------- *THE* ultimate computer virus:  MSDOS - even with updates! -------->
Newsgroups: comp.arch
From: ashish@blueridge.eecs.umich.edu (Ashish Mehra)
Subject: Need references on architecural comparison
Organization: University of Michigan EECS Dept., Ann Arbor, MI
Date: Tue, 26 Jan 1993 23:46:28 GMT


I would appreciate if the knowledgable amongst you
can give me some pointers to articles on architectural
comparisons focusing on context switching overhead and
interrupt response time. Relevant processor architectures
are the R2000/3000, SPARC, 68030/40 and 486. Also,
is there any study done that compared the _relative_
performance gains of a synchronization instruction
like test-and-set over pure software mechanisms?

On a related note, the (context switching) numbers 
reported in the literature are directly related to 
the performance of the memory subsystem. Most comparisons 
report the absolute numbers without commenting on the 
speed/bandwidth of the memory subsytem on which the 
measurements were made. Am I missing something here? 
Shouldn't such factors be normalized out? 

I would appreciate if all responses are sent to
ashish@eecs.umich.edu . If there is sufficient 
interest, I will post a summary on this newsgroup.

Thanks,

Ashish Mehra
ashish@eecs.umich.edu

 
Newsgroups: comp.arch
From: zstern@adobe.com (Zalman Stern)
Subject: Re: HOw many PC's make an Amdahl mainframe
Organization: Adobe Systems Incorporated
Date: Tue, 26 Jan 1993 21:55:41 GMT

In article <1k46ioINNijv@fido.asd.sgi.com> gints@prophet.esd.sgi.com (Gints  
Klimanis) writes:
> An Amdahl CEO in yesterday's San Jose Mercury news claimed there was no
> room in the world that could how enough personal computers to match the
> power of an Amdahl mainframe.  Any guesses  as to the # of PC's and disk
> drives required to match this Amdahl Mount Everest of computing?

How do you define "room"? I'm sure the blimp hangar over at Moffet would do  
it. I expect the average machine room you stuff an Amdahl mainframe in could  
hold enouhg PCs to numerically add up to an Amdahl mainframe. Being  
generous, the Mainframe = 1000 SPECMarks (N way multiprocessor) and 10  
Gigabytes/sec of "I/O bandwidth". At 30 SPECMarks per 486 box, thats 33 PCs.  
At 10 Megabytes per second I/O Bandwidth per EISA 486 (a probably bogus  
number) thats 1000 PCs. Assuming 3 cubic feet per PC that's somewhere  
between 100 and 3,000 cubic feet. You can put 1 or 2 gigs of disk in each PC  
to take care of the disk farm. Then just pile all them PC's up floor to  
celing and you're ready to do some real computin'!

Comments like this indicate that the big iron boys are pretty desperate.  
They are fighting the dynamics of the market. There are *relatively* few  
problems that require "mainframe power." Over time mainframes must either  
become cheaper or more powerful. More powerful is limited because there are  
fewer and fewer problems that require that kind of power and it becomes  
harder and harder to make the machine more powerful. Cheaper is a problem  
because the margins go down and a lot of a mainframe's costs are not  
hardware oriented. (I.e. service, paying for the space and other central  
facilities required.)
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
 "...And I didn't even need pants!!"--Dilbert on The Net (by Scott Adams)
Newsgroups: comp.arch
From: sobczyk@bcstec.ca.boeing.com (Andy Sobczyk)
Subject: RAM Memory Tests
Summary: Sources for RAM Memory Tests
Keywords: RAM Memory Tests
Organization: Boeing Computer Services
Date: Sat, 23 Jan 1993 19:09:33 GMT

I am writing software to perform BIT of DRAM memory.  I am looking for a 
good source of information for software algorithms.  Can anyone tell me the
name of a good text book or magazine articles dealing with this subject?

Thanks

Andy Sobczyk
sobczyk@bcstec.ca.boeing.com
206 6574391
Newsgroups: comp.arch
From: dhess@Xenon.Stanford.EDU (Drew William Hess)
Subject: TFP announcement from SGI?
Keywords: sgi arch tfp mips
Organization: CS Department, Stanford University, California, USA
Date: 27 Jan 93 18:48:55 GMT

The San Jose Mercury News had a small article today re: SGI's announcement
of their new supercomputers.  They also mentioned that the Power Challenge
systems use the TFP, which is, I believe, based on an earlier MIPS design
(R4000, I suppose) but with a floating point unit on steroids.  Has SGI
made any formal announcement of the TFP?  I believe that SGI did most of
the development on the TFP in-house before acquiring MIPS, so is SGI/MIPS
going to make it available to third parties as they do with the Rx000 
series?

On a related note, I thought that the new supercomputers had been dubbed
"Onyx," but the article makes no mention of this name.  Is the family
of supercomputers called "Challenge" and "Power Challenge," and the first
member of the family called "Onyx," or what?  I'm unclear on exactly
what was announced yesterday after reading the SJMN article (wouldn't be the
first time).

-dwh-
dhess@cs.stanford.edu
From: smith@das.harvard.edu (Mike Smith)
Newsgroups: comp.arch
Subject: Re: Harvard Architecture
Date: 26 Jan 93 14:42:51 GMT
Article-I.D.: das.1993Jan26.144251.14989
Reply-To: smith@das.Harvard.EDU
Organization: Harvard University

In article <1k1ljgINNf76@gorn.hal.com>, savel@hal.COM (Bharat Baliga-Savel) writes:
|> hmmm! i was under the impression that it was specifically a separate 
|> Instruction Cache and Data Cache. 

That is how the term Harvard architecture is used today, but as
Hennessy and Patterson discuss in Section 1.8 of their book CA:AQA,
the term originated as a description for the Mark series of machines
built at Harvard by Howard Aiken.  These machines had "separate
memories for instructions and data, ... [and they] were regarded
as reactionary by the advocates of stored-program computers." (p. 25)

For more info, you may want to look up some of H&P's references, or
look through the IEEE Annals of the History of Computers.

Mike Smith
smith@das.harvard.edu
Newsgroups: comp.arch,comp.sys.hp
From: edm@wrs.com (Ed McClanahan)
Subject: Re: HP-PA softw. virtual addr. translation HOW ?
Keywords: HP-PA
Organization: Wind River Systems, Inc.
Date: Thu, 28 Jan 1993 00:36:54 GMT

crusoe@cs.tu-berlin.de (Andre' Zehl) writes:

>I'm working on a preparation on the HP-PA RISC Architecture.I'm desparately
>trying to figure out, how you administer the virtual to physical address
>translation. 

>Unfortunately HP's description of this translation is very vague. They
>describe, that the virtual page number is hashed, thus providing a pointer
>in a hashtable (the PDIR INdex) which provides a pointer in the physical
>page directory (to chained PDIR-Entrys), where the page attributes are
>stored (NOT the physical page number).

>The physical page number (ppn) is identical with the index from the
>hashtable. But this only makes sense, if it's not the virtual page number (vpn)
>which is hashed, but the physical page number, coming out of the
>hardware translation? IS THIS SO ? Is the PDIR Index of the hashtable vpn 
>the hashed ppn or the hashed ?

>I need help _very_ urgently, so evry little hint is appreciated _very_ much!
>Thank you very much in advance! Please e-mail reply.
>-- 
>Andre'_________________________________________________________________________
>							 crusoe@cs.tu-berlin.de

I suspect you are referencing an early PA 1.0 Architecture Reference Manual.

As I recall, those early manuals described a "suggested" VPN->PPN table
structure involving what was then called a Hash Table which pointed to
linked entries in what was then called the PDIR, or Page DIRectory.  This
historical PDIR was indeed indexed by the PPN (Physical Page Number).  Each
entry contained the Virtual Address associated with the corresponding
Physical Address given by the position within the PDIR.  Each entry also
contained a link to the next entry in the PDIR whiched "hashed" to the
same position in the Hash Table.  Hence, to go from PA to VA was a simple
PDIR table lookup.  To go from VA to PA involved applying the "hash function"
to index into the Hash Table, then follow the links into and through the
PDIR until a matching VA was found - the resultant PDIR slot yielding the PA.

All that has changed over the years...  The latter PA Ref Manuals dropped the
"suggested" section mentioned above.  In fact, PDIR is what the old Hash
Table is called now-a-days (in HP-UX).  Would anyone from HP care to comment
on the current mechanisms used in HP-UX, MPEiX, and HP-RT???

Ed "formerly of HP" McClanahan
-- 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  Edward McClanahan
Newsgroups: comp.arch