HDTenEightyP/NetNews huggingface dataset:
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: Re: One Instruction Computers
Organization: Nanyang Technological University - Singapore
X-Newsreader: Tin 1.1 PL4
Date: Sat, 3 Oct 1992 01:58:21 GMT

mash@mash.wpd.sgi.com (John R. Mashey) writes:
: 
: From the description, I don't think that most people would call that
: a 1-instruction computer, for the same reason that opcode-counting is
: generally difficult to do in a sensible way.  AS discussed before:
: Machine A:
: 	Load 32 bits
: 	Load 16 bits signed-extended and load-16-bits-zero-extended
: 	Load 8 bits signed-extended and load-16-bits-zero-extended
: 	I.e., 5 opcodes
: Machine B:
: 	Load ... plus a 3-bit qualifier field that says 32, 16s....
: 	I.e., 1 opcode
: Any arguments based on Machine B being simpler than A, based on having 1

What do you do when "Loading 32"?
	send address to external memory, 
	send address to register array,
	enable appropriate control signals to reg array and ext. mem
	increment program counter.

: opcode rather than 5, are just plain silliness.  It's simply an encoding
: issue.

It is not just an  encoding, rather the exploitation of finer grain parallelism.
How many "micro" instructions you want to execute in parallel.
	a multiplication instruction is more complicated than an addition
instructioin because it can be made to be viewed as being made up of a lot
of additions but it can execute faster than addition, using parallelism at
bit levels. See shlomo wasserman and flynn.
	To call it plain silliness is silly. I cannot call it plain because
a lot of people do not seem to see this, maybe because of all the brain
washing. 


--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet
From: moss@cs.umass.edu (Eliot Moss)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 5 Oct 92 14:54:25 GMT
Article-I.D.: CRAFTY.MOSS.92Oct5095425
Reply-To: moss@cs.umass.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)

The questions was: Why 36 bit words instead of 32 or 48? One respondent
mentioned that 6 bit character codes were popular at the time, so multiples of
6 were popular (versus the current "standard" of multiples of 8 and/or powers
of 2). Octal was also popular, so multiples of 3 were around, but I doubt that
was a strong reason. Rather, based on the earlier heritage of 18 bit machines,
I suspect there was a feeling that 18 bits of address space was large enough,
and the 36 bit machines were built partly so that one word could hold one Lisp
cons cell (car and cdr both an address in size, hence 2 x 18 = 36 bits). By
the time of the DECSystem 20 the address space was getting tight, but the
architecture came from many years before. These days we might see some folks
use 64 bit words in a similar way ....
--

J. Eliot B. Moss, Associate Professor	Visiting Associate Professor
Department of Computer Science		School of Computer Science
Lederle Graduate Research Center	Carnegie Mellon University
University of Massachusetts		5000 Forbes Avenue
Amherst, MA  01003			Pittsburgh, PA  15213-3891
(413) 545-4206, 545-1249 (fax)		(412) 268-6767, 681-5739 (fax)
Moss@cs.umass.edu			Moss@cs.cmu.edu
From: mshute@cs.man.ac.uk (Malcolm Shute)
Newsgroups: comp.arch
Subject: Re: No special branch/jump formats?
Date: 29 Sep 92 10:17:44 GMT
Organization: Dept Computer Science, University of Manchester, U.K.

In article <id.8VFT.LOG@ferranti.com> peter@ferranti.com (peter da silva) writes:
>The 1802 is a "pseudo-risc" chip. The instruction set was very riscy, but
>apparently for aesthetic reasons. The implementation blew a lot of cycles
>and I'm not sure why. I suspect it had a major internal bandwidth problem.

Yes, I've often wondered why, too.
I've also often pondered why the thing was so infuriating at times to program
in assembler.  I think my then boss was right: "it was in need of one more
sensible addressing mode"

It had a 16 bit address bus, but only an 8 bit data bus.  It therefore had
8-bit immediate mode, and 16-bit indirect-register mode (from its 16bit gprs).
It needed either: (a) absolute mode 16-bit addressing; (b) 8-bit indexed
addressing (displacement mode, for VAX enthusiasts); (c) 8-bit paged mode
addressing; (d) 8-bit segment addressing; OR (e) absolutely anything else
of equivalent utility.

The reason I mention this is that it would seem to make an ideal subject
for a 'how to design a RISC' illustration.
If it really is as unbalanced in this respect as it feels... students should
have no difficulty in spotting that imbalance using a H&P-style analysis
of its instruction usage.

Has anyone tried this?
Does anyone still use the chip in their home computer?
Did anyone have any decent HLL compilers working on it... and if so, did
the 'missing' addressing mode dirty its code significantly?

Just a thought.
--

Malcolm SHUTE.         (The AM Mollusc:   v_@_ )        Disclaimer: all



--

Malcolm SHUTE.         (The AM Mollusc:   v_@_ )        Disclaimer: all
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Multi uP P5 systems
Date: 6 Oct 92 13:32:55 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1272@taniwha.UUCP>, paul@taniwha.UUCP (Paul Campbell) writes:

| Unix somewhat gets around this limitation by having much cheaper (and easier
| to use) processes than VMS - so you can do something like 'cu' using one
| process going in each way. These days 'threads' sort of solve the problem
| by making 'processes' even cheaper. The VMS AST is of course almost the
| ultimate in lightweight processes since it carries just enough context with
| it to get the job done.

  But it doesn't really solve the problem that an i/o completion should
be treated (or at least treatable) as an interrupt (aka signal).

| Well actually I think that leaving out ASTs and providing cheaper processes
| probably made it EASIER to program Unix because most people were presented
| with a LCD system interface - let's face it read() is way easier to program
| than $QIO - omitting system support for internal file structures was a
| great idea - although they should have provided record locking from the
| start. 

  True, but you can build a blocking read over an ansync read easily, so
I don't see any joy to the "easier to use" point, true though it is.

  In fact, when we wrote the research os here in 1968 (or so) that was
the model, with the i/o call specifying the status block and the trap
processor. Then the trap processor ran whenever the i/o completed.

  If I were doing it again (and I would dearly love to) I would initiate
the i/o and have a control block with a major status, perhaps a byte to
show good/bad, minir status to show either failure reason or transfer
length, a void* pointer to user defined data (such as id info if using
the same procedure to process many i/o requests), and i/o buffer address and
length to allow retry on volume change, etc.

	[ ... ]
| good stuff (and bad stuff) in both, despite the ragging VMS gets (mostly for
| it's user interface) the guys who wrote it did a good job - I'm sure they will
| do better on future systems.

  I sure hope so. Any o/s which puts file types in the o/s instead of
the program is really creating problems for the user, and I find that
more of a problem than the user interface. If programs really want a "$
delimited left handed nybble swapped hexadecimal" file type, let it be
done in the program or shared library, and not at a level when all
user-written file transfer and backup programs have to deal with it. As
my youngest says "yucky-poo!"

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
Newsgroups: comp.arch
From: shubu@cs.wisc.edu (Shubhendu Mukherjee)
Subject: Re: SPLASH
Organization: Univ. of Wisconsin @ Madison, CS Dept.
Date: Wed, 30 Sep 1992 05:51:33 GMT


>>>>> In article <748@hrlgw92.hrl.hitachi.co.jp>, morioka@hrlgw92.hrl.hitachi.co.jp (Michio Morioka) writes:

MM> Does anyone know where the Stanford SPLASH benchmark programs are?
MM> Let me know the IP address (real address like a 133.11.11.11) 
MM> of the ftp-site.

{mojave.stanford.edu, 36.22.0.120}:/pub/splash

Luck!
-Shubu
--
-------------------------------------------------------------------------
Shubhendu Sekhar Mukherjee       University of Wisconsin @ Madison, C.Sc.
Net:shubu@cs.{wisc,utexas}.edu   [W]:(608) 262-1012   [H]:(608) 255-6322
-------------------------------------------------------------------------   
Newsgroups: comp.arch,comp.lang.misc
From: izahi@bsc.no (Raul Izahi Lopez Hernandez)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Organization: Bergen Scientific Centre, Bergen, NORWAY
Date: Mon, 5 Oct 1992 07:41:15 GMT

In article <1992Sep29.232852.22456@CS.ORST.EDU> crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
>>This is one of the problems with the current HLLs, the inability to use
>>"mathematical" type notation.  I admit that I have not used these aspects
>>of C enough to have the syntax right.
>
>I argue just the opposite.  One of the _advantages_ of current HLLs is the
>inability to use "mathematical" type notation.  Mathematical notation is
>ambiguous and highly dependent on context.  Current HLLs don't have this
 ^^^^^^^^^ ?????????
>problem.  Furthermore, we don't want to introduce ambiguity and bizzare
>context into HLLs.

   Can you show me how Mathematical notation can be ambiguous and highly
dependent on context?
   As far as I know anybody with a good high school training knows what
to do when she sees this:

   n=10
         n
	----
        \
         \
   A=    /    i*i
        /
        ---
       i=1
   What would you like to use? Flow diagrams? LISP? BASIC?
   Maybe I don't understand what you meant.
-- 
         -----> All opinions expressed here are my own, not IBM's <-----
Raul Izahi Lopez	Izahi Engineering
izahi@bsc.no		IBM Bergen Environmental Sciences and Solutions Centre
			Thormoehlensgate 55, 5008 Bergen, NORWAY (47-5)54-4653
Newsgroups: comp.arch,comp.lang.misc
From: blj@crhc.uiuc.edu (Bob Janssens)
Newsgroups: comp.arch
Subject: sparcstation cache
Date: 28 Sep 1992 23:00:30 -0500
Organization: Center for Reliable and High-Performance Computing, University of Illinois at Urbana-Champaign
NNTP-Posting-Host: castor.crhc.uiuc.edu

I would like to find out the exact organization of the cache(s) in the
various workstations of the SPARCstation family.  On-chip, off-chip, or
both?  Split or combined data/instruction?  Direct-mapped?  
Write-through or write-back?  Any information or any pointers to
references would be dearly appreciated.

Thank You,

Bob Janssens		blj@crhc.uiuc.edu
University of Illinois, Urbana
From: roger@gimli.inmos.co.uk (Roger Shepherd)
Subject: Re: Fully associative cache
Organization: INMOS Limited, Bristol, UK
Date: Thu, 1 Oct 1992 08:50:17 GMT

In article <lck75mINNlei@spim.mti.sgi.com>, you write:

|> Paul's explanation probably wasn't detailed enough.
|> The data cache is split into two parts, the tag side and the data side,
|> that can be read/written independently.
|> For a read, both the tag and data sides are read at the same time.
|> For a write:
|>  the tag side is read to check for a cache hit/miss,
|>  the data for the write goes into a couple-deep store buffer,
|>  the oldest pending write in the store buffer is written
|>  to the appropriate line in the data side.
|> In addition to retiring store buffer contents under a subsequent write,
|> the store buffer will also retire a write in any cycle that
|> the data cache isn't being accessed (i.e. any instr that isn't a load/store).
|> The store buffer is non-trivial to build and get right, but not using
|> two cache cycles for stores was a sufficient win to make it worthwhile.

Ah.. I understand now. Very clever. 

I've just checked, and what I said originally was that with a fully
associative cache ``writes easily get performed in one cycle'' - I think your
comment that ''The store buffer is non-trivial to build and get right'' 
justifies my use of the word ``easily''.


-- 
Roger Shepherd, INMOS Ltd   JANET:    roger@uk.co.inmos 
1000 Aztec West             UUCP:     ukc!inmos!roger or uunet!inmos-c!roger
Almondsbury                 INTERNET: roger@inmos.com
+44 454 616616              ROW:      roger@inmos.com OR roger@inmos.co.uk
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.arch
Subject: Re: Power consumption
Keywords: power
Date: 28 Sep 92 11:04:44 GMT
Organization: Department of Computer Science, U of Copenhagen

badri@rags.rutgers.edu (Br Badrinath) writes:

>5. What is the power consumption of the CPU (per n cycles or so)?

That is very much dependent on what processor you use. A DEC Alpha
uses 30Watts, but an ARM610 (as used in Apple's Newton) uses inly a
few milliwatts.

	Torben Mogensen (torbenm@diku.dk)
Newsgroups: comp.arch
From: sarr@sinshan.citi.umich.edu (Sarr J. Blumson)
Subject: Re: What was the intended advantage of using 36bits CPU?
Organization: University of Michigan, CITI
Date: Tue, 6 Oct 1992 13:08:59 GMT

In article <1992Oct6.000652.9871@dartvax.dartmouth.edu> mac@coos.dartmouth.edu (Milton A. Colvin) writes:
>>I was wondering what was the advantage of having 36 bits instead of 32
>>or other 8*n (n>4) architecture.
>
>So a word can hold 5  7-bit ASCII characters with a bit left over for the
>garbage collector.

No, the extra bit is to screw things up when you try to do word
comparisons on long strings.  Another decision made when memory
(rotating and otherwise) that many innocents had to suffer for.  As
noted earluer, the hardware supported characters of _any_ size.

>
>Everything was once a multiple of 6 - 60 bits, 36 bits, 12 bits, 24 bits.
>Except for the DDP-19 which had 19-bit words.

Or the GE-2x5 (can even people at Dartmouth have forgotten them?)
which had 20 bit words.

(Sarr Blumson)
From: maf@hpfcso.FC.HP.COM (Mark Forsyth)
Date: Mon, 5 Oct 1992 15:31:55 GMT
Subject: Re: Multiplication on your favorite CPU (summary)
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.arch

> 
> 
> Hewlett-Packard PA-RISC 1.1 (PA7[01]00):
> 
>   32x32 -> 64:      XMPYU
>     source:         <fp-register> x <fp-register>
>     destination:    <fp-register>
>     latency:        3 (PA7000)                      2 (PA7100)
>     pipelined:      every other cycle (PA7000)      fully (PA7100)
>     independent:    yes                             yes (superscalar)
>     comment:        one must go through main memory to get operands from
                                  ^^^^^^^^^^^^^^^^^^^
>                     the <int-register>s into the <fp-register> and back.

Actually, the preferred method is to go through cache to transfer operands.
On the 7100, assuming no cache misses, this will take an average of 3 cycles
per operand, or 2 cycles average if useful non-cache instructions can be
executed in the clock cycle between the STORE and LOAD. The LOADs and STOREs
can also be simultaneously issued with flop or integer instructions so the 
transfer time can be shared with other useful work.  Avoiding or minimizing
cache misses is important - there are a number of ways to do this for most 
cases.  

- Mark Forsyth (my opinions, not HP's)
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Date: 27 Sep 92 15:35:40 GMT
Article-I.D.: cs.Bv8tzG.Kv1.2
Organization: School of Computer Science, Carnegie Mellon


In article <14813@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>There's an interview with Roger Ross ...
>	The only real 64-bit processor out there is Alpha.  The MIPS
>	chip is not a 64-bit machine -- not the way I measure it.

I count four:
- Alpha  (which is about to be named VRX or some such??)
- R4000
- Ncube-2 node processor, I think
- KSR-1 node processor (actually they only implemented 40 bits)

plus in the works
- SPARC
- POWER

and the players that definitely should have unrevealed plans are
- x86
- HP

The "rest of the world" includes
- Hobbit and other chips aimed at low power
- transputers
- DSP
- the mortally wounded like the 88k
- captives like the Clipper
- embedded control

Of the last, high-end embedded control might feel the most pressure,
particularly if the R4000 runs Postscript particularly well. Does it?
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
From: paul@taniwha.UUCP (Paul Campbell)
Newsgroups: comp.arch
Subject: Re: Multi uP P5 systems
Date: 29 Sep 92 08:13:41 GMT
Organization: Taniwha Systems Design

In article <1248@falcon.is> brb@falcon.is (Bjorn R. Bjornsson) writes:

>Much as I like Unix, I would kill to have a decent signaling system
>(known as ASTs - Asynchronous System Traps in RSX-11 and VMS) instead
>of the rotten kludges everyone has to put up with in the (various)
>Unix systems.  I've been gnashing my teeth for ten years over the fact
>that there was a chance to put this right when BSD was implemented.

I agree - the real problem is a basic system design one - one that was made
in the early Unix systems - I/O context lives in a fixed place
in a process's kernel context while in RSX/VMS et al I/O context lives in
a dynamically allocated block that is allocated for each I/O (and is queued
to a device driver of some kind). This means that a Unix process can only have
one outstanding I/O request at any one time - while a VMS one can have many.

Unix somewhat gets around this limitation by having much cheaper (and easier
to use) processes than VMS - so you can do something like 'cu' using one
process going in each way. These days 'threads' sort of solve the problem
by making 'processes' even cheaper. The VMS AST is of course almost the
ultimate in lightweight processes since it carries just enough context with
it to get the job done.

>I think it would be hard to measure how costly this deficiency
>in Unix really is, not to mention the several subtly and not so
>subtly incompatible implementations.  In case you don't know what
>the costs are: Programming time and design constraints.

Well actually I think that leaving out ASTs and providing cheaper processes
probably made it EASIER to program Unix because most people were presented
with a LCD system interface - let's face it read() is way easier to program
than $QIO - omitting system support for internal file structures was a
great idea - although they should have provided record locking from the
start. 

So - I don't see a clear winner - I've been both a VMS and a Unix kernel
hacker (hell I once ported a Unix kernel to run in supervisor mode in
place of DCL under VMS - each user got lots of little Unix processes running
in one VMS process ..... now I design chips, but that's another story) there's
good stuff (and bad stuff) in both, despite the ragging VMS gets (mostly for
it's user interface) the guys who wrote it did a good job - I'm sure they will
do better on future systems.

	Paul

-- 
Paul Campbell    UUCP: ..!mtxinu!taniwha!paul     AppleLink: CAMPBELL.P
	
       	So far the Republican's economic policy is best described
		     as "C'est la vie Capitalism"
Newsgroups: comp.arch,comp.parallel
From: kaushik@godzilla.cis.ohio-state.edu (shivandan kaushik)
Subject: References Wanted: Polling systems for Modeling Bus-Based Systems
Keywords: Polling Systems, Bus-based Systems
Organization: The Ohio State University Dept. of Computer and Info. Science
Date: Wed, 30 Sep 1992 15:35:42 GMT

Hi,

	I'm looking for articles describing the use of polling systems
	for modelling bus based systems. Polling systems are used for
	serving requests by several ( possibly buffered ) users in 
	a cyclic order with generally nonzero switchover times between
	users. Thanks in advance.


*********
Shivnandan Kaushik | e-Mail: kaushik@cis.ohio-state.edu
From: parke@star.enet.dec.com (Bill Parke)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 5 Oct 92 17:20:59 GMT
Article-I.D.: nntpd.1992Oct5.172059.28618
Reply-To: parke@star.enet.dec.com
Organization: DIGITAL - VMS Engineering


In article <869@felix.Sublink.Org>, eb@felix.Sublink.Org (Enrico Badella) writes:
|>Path: nntpd.lkg.dec.com!news.crl.dec.com!deccrl!decwrl!sdd.hp.com!swrinde!gatech!rutgers!modus!dyna!osra!felix!eb
|>From: eb@felix.Sublink.Org (Enrico Badella)
|>
|>Recently I came hold of and old paper that described the TENEX Operating
|>System for old DEC Systems 10 and 20; I never used or saw such beasts but
|>I was wondering what was the advantage of having 36 bits instead of 32
|>or other 8*n (n>4) architecture.
|>Was is just a hardware problem because 48 bits was to difficult to 
|>manufacture at that time.
|>
|>On the DEC Systems 10 and 20 subject, why did they fade away in those
|>days when nobody news what Open Systems were?
|>
|>-- 
|>Enrico Badella				Internet: eb@felix.sublink.org
|>Soft*Star s.r.l.			          eb@icnucevx.cnuce.cnr.it
|>Via Camburzano 9			Phone:    +39-11-746092
|>10143 Torino, ITALY			Fax:      +39-11-746487
|>

4 (decimal) , 12, 18 and 36 bit computers from DEC, IBM and others (including
the ones complement UNIVAC 11xx series) predated 32 bit and 16 bit machines
by a number of years.

In that context, TENEX is a relativly "modern" operating system (to which
some have yet to catch up).  The ancestor of U*X MULTICS ran on a GE
processor which I believe was also a 36 bit machines.

None of these had anything to do with Open systems at the time (late 50s
to early 70s).  Open and portable at that time was a good FORTRAN/COBOL/
LISP/... compiler.

Bill Parke 			parke%star.enet.dec@decwrl.dec.com
VMS Development			decwrl!star.enet.dec.com!parke
Digital Equipment Corp		parke@star.enet.dec.com
110 Spit Brook Road ZK01-2/D59, Nashua NH 03063

The views expressed are my own.
Xref: sparky comp.arch:9856 comp.lang.misc:3220
From: doconnor@sedona.intel.com (Dennis O'Connor)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 6 Oct 92 22:27:39 GMT
	<BvF75z.GBA@mentor.cc.purdue.edu> <1992Oct5.074946.600@newsroom.bsc.no>
Organization: Intel i960(tm) Architecture


izahi@bsc.no (Raul Izahi Lopez Hernandez) writes:
]   What we need to introduce in the computer industry is Modular Architectures.
]   If for a certain application you need more buffer space, you add one or
] two more 'buffer chips'. If you need more registers you add more 'register
] chips', if you need another floating point unit, say a true 256-bit
] multiplier, you call the salesman and ask for a '256-bit FP multiplier chip'
] ...

Except :
	1) crossing chip boundaries is very slow ( 5ns ), sucks power,
	   generate noise and there's only so many pins available

	2) you'd have to recompile to use, for example, more registers,
	   and most people don't have source code

	3) it would cost a bunch : packages are expensive, as is board space

	4) many users would put the "module" chip in the socket backward,
	   even if they had to use a sledgehammer to do so.

The "modular" concept worked okay when the modules where whole
plug-in cards, back when computers were built up out of MSI logic.
It even worked OK when you couldn't fit, say, the FPU on the chip.
It doesn't work well today. Today's "modular" architectures are
like the Intel i960(R), which within it's family product line has
cheap chips, fast chips, faster chip, chips with FPUs, chips
without FPUs, chips with MMUs, et cetera. Some are pin-compatable :
the i960KA and KB for example : the KB has an FPU, the KA does not.
The i960CA and i960CF are pin-compatable but the i960CF has bigger caches.
All i960 processors execute the same core architecture instructions,
while ones with FPUs execute the numeric architecture instructions,
and ones with MMUs execute the extended architecture instructions.

Many other processor families have similar "modular" architectures,
without use several chips. You just choose the chip that has all
the modules you want.
--
Dennis O'Connor			doconnor@sedona.intel.com
Newsgroups: comp.arch