HDTenEightyP/NetNews huggingface dataset:
From: preston@cs.rice.edu (Preston Briggs)
Newsgroups: comp.arch
Subject: Re: Thesis projects
Keywords: thesis
Date: 29 Sep 92 15:09:23 GMT
Article-I.D.: rice.BvCI3n.9qx
Organization: Rice University, Houston

rg9538@ehsn5.cen.uiuc.edu (Ronald E Garnett) writes:

>I am a brand new graduate student in computer 
>architecture (Electrical Engineering)

>What I need is a good idea for a thesis-level project.

>give me some ideas that may at least inspire me to come up
>with a topic

What you need is an advisor.
Seriously.  You go to grad school, you do research to support
your advisor.  After you're done, you get grad students tosupport your
goals.

If you don't have an advisor yet, start interviewing the professors.
Rather than telling them all the stuff you're interested in, ask
them what they work on and what they'd have for you to do.  Ideally,
you'll find someone whose interests intersect yours in a big way.

Look for someone that has grant money to support you (mercenary, but
we're being realistic) and who will support you in faculty meetings
and such.

I think you'll find that most prof's have far more work than people
and most are glad to have new students.  Of course, if everyone would
follow Steve Simmons good advice, they'd all have advisors by the time
they were admitted.

Preston Briggs
From: cho@balboa.eng.uci.edu (Jae Cho)
Subject: info wanted on parallel machines
Newsgroups: comp.arch
Organization: University of California, Irvine
Date: 29 Sep 92 04:35:59 GMT

I am looking for the articles describing the hardware
architecture of the parallel machines listed below.
Please E-mail me the postscript files or the bibliography.

	Intel's Paragon
	Thinking Machine's CM-5
	Kendall Square
	

Thank you in advance.

Jae Cho
cho@balboa.uci.edu
University of California, Irvine
Newsgroups: comp.arch
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Reply-To: jinx@zurich.ai.mit.edu
Organization: M.I.T. Artificial Intelligence Lab.
	<1992Sep28.201033.24532@csrd.uiuc.edu>
Date: Mon, 28 Sep 1992 23:51:56 GMT

In article <1992Sep28.201033.24532@csrd.uiuc.edu> grout@sp90.csrd.uiuc.edu (John R. Grout) writes:

|   davew@willow03.cray.com (Dave Wagner) writes:
|
|   >Check address spaces in Alpha though.  Alpha (21064) has only a 43-bit virtual
|   >space, and a 34-bit physical space.  I think a 'real' 64 bit processor should
|   >provide more (64bits) of both.
|
|   It depends on how you define 'real'... the Alpha ISA requires the use of
|   64-bit virtual and physical addresses, which means that any unimplemented
|   high-order bits on a given processor are reserved for future expansion and
|   must be zero (and this is _enforced_).  Given this, an ISA subset on a
|   specific Alpha processor chip (e.g., the 21064) can be a win (a valid
|   cost-benefit tradeoff) without being a first-implementation artifact which
|   loses the ability to compatibly implement full 64-bit physical or virtual
|   addresses later.

This is not quite correct.

A virtual address on the 21064 must be a valid sign extension of a
(signed) 43-bit value.  In other words, the high bits must be all 0 or
all 1.  I don't know what the restriction is on physical addresses,
but clearly it is generally much less severe since few (user,
application) programs have any control over their physical address
space.

Note that the restriction on virtual addresses is visible to software
in the presence of an OS (like Mach 3.0) which allows flexible control
over a program's (or task's or thread's) address space so that
programs can map "memory objects" to arbitrary virtual addresses.

The range of virtual addresses allowed differs with implementation,
and there are tricks you could (legally) use on a _full_
implementation that cannot be used with the partially implemented
virtual address space.
Newsgroups: comp.arch
From: solman@athena.mit.edu (Jason W Solinsky)
Subject: Re: Best Grad Schools for Computer Engineering?
Organization: Massachusetts Institute of Technology
Date: Tue, 29 Sep 1992 02:12:56 GMT

In article <2AC797D2.28964@news.service.uci.edu>, jtien@balboa.eng.uci.edu (Joe Tien) writes:

|> How does one get a copy of that Gourman Report?

Buy it. They have a copy in most college book stores. It conforms more or less
with conventional wisdom in EECS areas but you won't find a fine enough division
between areas to distinguish good parallel processing schools from good
microprocessor architecture schools.

Jason W. Solinsky
From: eb@felix.Sublink.Org (Enrico Badella)
Newsgroups: comp.arch
Subject: What was the intended advantage of using 36bits CPU?
Date: 3 Oct 92 16:11:56 GMT
Organization: Soft*Star s.r.l, Torino, Italy

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
Newsgroups: comp.arch
From: richk@grebyn.com (Richard Krehbiel)
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Organization: Grebyn Timesharing
Date: Thu, 1 Oct 1992 01:17:55 GMT

In article <1671@idacrd.UUCP> desj@ccr-p.ida.org (David desJardins) writes:
>John R. Mashey <mash@mash.wpd.sgi.com> writes:
>> Since there may not be anything *after* microprocessors, maybe we'll
>> have learned from our previous sins.
>
>I can't tell if this is a joke.  You aren't seriously suggesting that
>modern microprocessor design incorporates all of the design principles
>that will be needed until the end of time??

He was classifying the computer mistakes into mainframes,
minicomputers, and microprocessors.  The mainframes came first, so of
course they would make design mistakes.  The minis and micros came
well after, but because their implementations were
hardware-constrained (minis existed solely to be smaller and cheaper
than mainframes; micros were created when someone realized that just
enough transistors would fit into a silicon wafer to make a
rudimentary CPU) they had the same short-sighted design compromises
that the earlier machines made.

I think we can expect that when the next hardware-constrained CPU
technology comes along (perhaps the optical CPU) we can expect to see
some of the same mistakes again.

>I can just imagine those computer designers in the year 2100 or so
>saying, "Yeah, single instruction streams with superscalar execution,
>that's the ticket."  Not.

They might well say that if that's all they can afford to implement in
their new reverse-temporal technology.  And we might all be delighted
to have it, too.
-- 
Richard Krehbiel                                 richk@grebyn.com
OS/2 2.0 will do for me until AmigaDOS for the 386 comes along...
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Organization: Intel Corp., Hillsboro, Oregon
	<1992Sep28.201033.24532@csrd.uiuc.edu>
	<1992Sep29.095212.24225@odin.diku.dk>
	<1992Sep29.185157.14497@odin.corp.sgi.com>
Date: Wed, 30 Sep 1992 14:33:27 GMT

    In article <1992Sep29.095212.24225@odin.diku.dk>, torbenm@diku.dk (Torben
    AEgidius Mogensen) writes:

    |> >IBM found out the hard way that if you don't _enforce_ "reserved
    |> >and must be zero", you lose the ability to grow later... because
    |> >the 360 architecture allowed the high-order byte of address
    |> >fullwords in memory and GP registers

Requiring reserved bits to be zero, and trapping if they are not,
can be a good thing. It prevents programs running on the old implementation
setting the reserved bits, and not being able to run on a new implementation.
I.e. it encourages forward compatibility.

On the other hand, I've been caught the other way more than a few
times.  I've defined new features that are are "hint-like": code that
has the feature turned on would run correctly with the feature turned
off, although the converse may not be true (code that has the feature
turned off may not run correctly with the feature turned on).

If the reserved bits had not been checked for zero in the old
implementation, new code with the feature turned on would have run
correctly on the old implementation. This would have permitted
backwards compatibility.

Which is more important, forward compatibility or backwards
compatibility?  Probably backwards compatibility, but only barely.
Running old programs is a definite competitive advantage. But being
able to say that new programs using a new feature will run on old
machines is a big advantage if you want to encourage software
developers to use your new feature.

During the FUTUREbus+ definition, there was some attempt to formalize
this sort of thing:

Implementation:
a)    Reserved, Value Zero, Trap on Writing Non-zero
b)    Reserved, Value Zero, Silently Ignore Writing Non-Zero

Architecture:
1)    Reserved - programmer must always write value last read into reserved bits.
2)    Reserved - programmer may always write a safe value(0) into reserved bits.

There are a few obvious variants of the above. The problem with
silently ignore is programmers who don't know how to mask off reserved
bits. However, I have observed many times that hardware designers who
complain about programmers' misuse of reserved bits, have not clearly
defined which of rule 1) or 2) is architecturally supposed to apply.
{Sometimes the rule varies bit-by-bit in a control register!}



--

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: fpj@ingrina.inesc.pt (Fernando Pereira Jesus)
Subject: Re: implementing random replacement
Organization: INESC (Inst. Eng. Sistemas e Computadores) Lisboa, Portugal
	<FPJ.92Sep30160228@ingrina.inesc.pt> <BvEMG3.4z0@metaflow.com>
Date: Thu, 1 Oct 1992 08:22:38 GMT

In article <BvEMG3.4z0@metaflow.com> rschnapp@metaflow.com (Russ Schnapp) writes:

>   |> The time to scan all lines in the cache is (more or less) 10ns * N
>   |> N is the number of lines in the cache. If N is, say, 100, it will take
>   |> 1us to scan all lines. 
>
>   Perhaps I misunderstood your design.  I thought you said you were using
>   a feedback shift register to generate the random replacement pointer.
>   If so, then as far as I know, you cannot _guarantee_ that all N lines
>   will be visited until you have visited all the states in your shift
>   register.
>
>   For example, if you use a 16 bit shift register and an optimal feedback
>   network, there are 2**16 states.
>   ...
Ok, I'm sorry, I shouldn't have call it a feedback shift register
without explaining:

Suppose you have a N-stage shift register with outputs (o1, o2, ...,
oN). At power up o1 is seted and all others reseted, so only one
output is active at a time (this is the important point I haven't
mentioned). So, at time 0 the state of the shift register is 100...,
after about 10ns the state is 0100..., after 10ns more, 00100..., and
so on. After 10ns * N we have the initial state again (because the
last stage of the shift register feeds back to the first one). So we
have exactly N possible states (not 2**N). With one stage of the shift
register for each line in the cache, we have as many possible states
as lines in the cache.

>
>   |>                       If this time is to high, or if N is a large
>   |> number, you can have two levels of counters: (a tree of counters) the
>   |> ...
>   This doesn't help ensure that all lines are visited in less time.  It
>   can also decrease the liklihood of selecting an unused line.
You can stop the root shift register (maybe I shouldn't have call it a
counter) if it steps to a stoped second level shift register.

>   |> ...
>   |> scanned in a finite amount of time, and since it runs assynchronously,
>   |> it will be faster than a simple counter.
>   A counter can be run asynchronously, and as fast as an FSR.  
The number of transistors involved in one step is less than 15 (I
don't remember the exact number now). About 1/2 of this transistors
are pass gates which are allmost always "on" or "off".  A counter is
more complex, because of the carry, so I don't beleave that (with the
same technology) a counter can run as fast as this shift-register.

>   |> ...
>
>   Now I'm sure I don't understand what your design is, since an FSR can't
>   ...
I hope this is more clear now.
--
   _____                  _ __   ___            
    /  '             /   ' )  ) '  /            Fernando Pereira Jesus
 ,-/-_ _ _  _  _  __/__   /--'  __/-_ _     _   Telef : +351.1.3100282
(_/ (~/ / )(_|/ )(_/(_)  /     / / (~/_)(_// )  e-mail: fpj@inesc.pt
     ___________________/_____(_/___________/
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Fully associative cache
Organization: Intel Corp., Hillsboro, Oregon
	<1992Sep24.100256.23376@inmos.co.uk>
	<WAYNE.92Sep25190429@backbone.uucp>
Date: Sat, 26 Sep 1992 19:40:15 GMT

    How can a fully associative cache possible be smaller than 4-way
    associative cache?

Depends on what is your area limit.

A 4-way set associative cache requires reading 4 (tag,data) tuples out
of your array => 4 times as many wires. A fully associative cache only
requires reading 1 (tag,data) tuple out of the array. So, if you are
wire limited, and the CAMs hide under the wires, a fully associative
cache may indeed be smaller.

All this, of course, depends on your technology *and* your time
constraints.


--

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: alpha@waggen.twuug.com (Joe Wright)
Subject: Re: What was the intended advantage of using 36bits CPU?
Organization: ALPHA, Box 68621, Va. Beach, VA 23455
X-Newsreader: TIN [version 1.1 PL6]
Date: Tue, 6 Oct 1992 16:48:35 GMT

Way back when, IBM determined to decode the Hollerith card's 
twelve rows into six bits for storage into memory.  A memory
word was therefore some multiple of six bits.  As late as 1963
IBM's new (at the time) 7094 had a 36-bit memory word so as to
be six characters wide.  
-- 
Joe Wright  alpha@waggen.twuug.com
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Re: Not using integers
Date: 6 Oct 92 03:53:39 GMT
Organization: Comp Sci, RMIT, Melbourne, Australia

In article <9891@kralizec.zeta.org.au>, mikeh@kralizec.zeta.org.au (Michael Hore) writes:
> rschnapp@metaflow.com (Russ Schnapp) writes:
> >As I recall, the A-series is a tagged architecture, so there would be only one
> >ADD, SUB, etc., instruction despite the data format.  The tag automatically
> >indicates the datatype, and therefore, the kind of operation to perform.  Or
> >didn't the tags go that far?
> 
> If I remember right, there was one tag bit which distinguished numeric
> from everything else, and for numerics the other 47* bits were data.
> Floats and integers weren't distinguished by the tagging.

The A-series machines that I know anything about had
	48 data bits
	 3 tag bits
	 + parity &c
The tags that I can remember are
	 0 single precision (47 bit; the top bit was unused so that the
		B6500 would have the same SP format as the B5500)
	 1 Indirect Reference Word (pointer to location within stack)
	 2 double precision (the ADD instruction could tell single precision
		from double precision by looking at the tag; the general
		rule if I remember correctly was that if the inputs to an
		arithmetic operation were in integer form (exponent 0) and
		the result _could_ be, it _would_ be)
	 3 stack control words and the code tag
	 4 Step Index Control Word (for "DO" statements and Fortran array
		indexing)
	 5 Array Descriptor (memory/disc address; element size; present/
		absent; copy/original; has it been indexed and size (if
		not indexed) or offset (if it has).  Note that "pointers"
		may be either tag 5 or tag 1 depending on whether the
		thing addressed came from an array or not
	 6 Uninitialised (the Pascal compiler used this; it was _great_
		to have programs that used uninitialised variables trapped)
		This was used for something else too
	 7 Procedure descriptor
Odd tag => you can't store into them using ordinary instructions (but it is
a "state of the compiler" flag, not a "state of the processor" flag; the
ESPOL compiler would generate instructions that _could_ overwrite anything).
Even tag => some kind of data.

Writing a garbage collector for this machine was _easy_.  I've always
wondered why Burroughs didn't make more of the "QUEUE" data structure;
the documentation for that part of ESPOL was pathetic, but it looked a
lot as though they were "classes".

-- 
RMIT policy requires the use of Gender Inclusive Language in all publications
and in all information conveyed to students, staff, and potential job
applicants.  Lapses into English are the sole responsibility of the author.
The Constitution of Australia does _not_ guarantee Freedom of Speech.
From: cchd@lucifer.latrobe.edu.au (Huw Davies)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 5 Oct 92 12:55:57 GMT
Organization: La Trobe University

In article <869@felix.Sublink.Org> eb@felix.Sublink.Org (Enrico Badella) writes:
>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.

It was so that the word size was a multiple of 6 (the prevailing
character encoding) 9, 12 (the word size of the PDP-12) and 18 (the word
size of the PDP-15).

As to why the 10s and 20s disappeared, I guess it was a marketing
decision that DEC would be a one architecture (VAX) one operating system
(VMS) company.
-- 
  Huw Davies           | Huw.Davies@latrobe.edu.au
  Computing Services   | Phone: +61 3 479 1500   Fax: +61 3 479 1999
  La Trobe University  | I own an Alfa to keep me poor in a monetary
  Melbourne Australia  | sense, but rich in so many other ways
From: mshute@cs.man.ac.uk (Malcolm Shute)
Newsgroups: comp.arch
Subject: Re: No special branch/jump formats?
Date: 29 Sep 92 10:03:25 GMT
Organization: Dept Computer Science, University of Manchester, U.K.

In article <josef.717144694@uranium> mollers.pad@sni.de (Josef Moellers) writes:
>In <1992Sep21.103245.59031@cc.usu.edu> ivie@cc.usu.edu (CP/M lives!) writes:
>>On the PDP-11, the PC is a general register so you can do this sort of stuff
Not quite...
As I understand it... the PC was *mapped* to R7, as opposed to *being* R7
So the PC was actually a fast special purpose counter embedded in the address
logic, which could be accessed by its R7 alias being trapped by the register
address decoder.

>>with it; MOV #label,PC is the same as JMP @#label. Not all possible JMPs have
>>a MOV synonym, though; the JMP omits a level of indirection because it wants
Strangely, its the other way round.
    MOV #label,PC    <==>    JMP @#label    (as you correctly point out)
    MOV @#label,PC   ~~~>    JMP @label
    MOV label,PC     <==>    JMP @label
                             JMP #label  has no equivalent, and is somewhat
                                         meaningless (a wasted addressing mode)
    MOV @(R3),PC     also has no equivalent, and is enormously useful, especially
                     if you are wanting to build a jump table... in effect you
                     have an address with 3 levels of indirection.

>>to come up with the address of label and not the value in it. The VAX
>>provides a MOVAddress instruction that could be used to get the missing
>>synonyms.

>If I recall correctly, the MOV instruction changed the condition
>codes on the PDP-11. As You wouldn't want to change them with every
>branch/jump, there would have to be a special treatment of the PC.
This is certainly a valid point.

>This is definitely true for arithmetics (ADD to PC) to do relative
>jumps.
--

Malcolm SHUTE.         (The AM Mollusc:   v_@_ )        Disclaimer: all
From: ldr@veritech.mv.com (Lee D. Rothstein)
Newsgroups: comp.arch
Subject: >>>>>> Best Grad Schools for Computer Engineering?
Distribution: world
Date: Mon, 05 Oct 92 08:46:00 GMT
Organization: VeriTech; IEEE Computer Society, NH
Reply-To: ldr@veritech.mv.com


In article <ssimmons.717769562@convex.convex.com>, ssimmons@convex.com provides
excellent advice that I would like to slightly amend:

>Ugh.... Don't choose a grad school!!!! Choose an advisor!!!!!

>Graduate work is not like undergraduate work.  The most important work 
>that you do is the research, not taking tests. 

>Therefore, do the following...

>- Determine your areas of interest. The basic areas are software engineering,
>graphics, architecture, compilers, operating systems, etc... 

>- Go to the library and take out a stack of magazines in these areas. 
>Both ACM and IEEE publish excellent work in this area.

>- Get a list of 10-20 authors doing work in this area.  Usually, one or
>two will grab your interest.  Call each up and explain your interests.  
>Make sure that they are still pursuing this area.  Professors change their
>minds about their interests.  Ask them what they will be doing a year from 
>now. 

>- Talk to their grad students.  See how many have graduated recently.  I
> know of one prof who had students spending 5 years on Master's thesises.
 
What have the prof's students accomplished after graduation? While this is
important, younger professors will not have established a track record, yet
they may still be the best people to work for. 

>- Look at your grades and GREs.  Be sure that you are not too far off from
>the school's requirements.  Getting into grad school is like getting a job.
>Your professor must want to work with you. 

>Thank you. 

>                                                Steve Simmons 

I didn't add much, but most of what Steve says deserves repeating, anyway. 

Lee

  /-----------------------------------------------------------\
 /Lee D. Rothstein                                 603-424-2900\
/ VeriTech: IT Verification & Leadership      Fax: 603-424-8549 \
\ 7 Merrymeeting Drive               Email: ldr@veritech.mv.com /
 \Merrimack, NH 03054-2934            IEEE Computer Society, NH/
  \-----------------------------------------------------------/