HDTenEightyP/NetNews huggingface dataset:
From: smith@sctc.com (Rick Smith)
Subject: Re: Proposal: Computer History Project
Keywords: software, history, computer
Organization: SCTC
Date: Mon, 27 Jul 1992 15:26:57 GMT

I think this is a really interesting idea, but I caution people not to
expect this to happen overnight. Let's pause for a moment and ponder
the significance of what we're proposing. The way I understand it,
the project intends to identify and preserve the logical functioning
of historic computers and historic software systems.

In other words, the documented behavior of the systems shall be
replicated in these emulated environments.

I've been casually interested in early developments of automatic
programming systems (A2, early Fortran, MIT's Comprehensive System,
Generalized Programming, etc). I' not. even sure if any digital
representation of any of these still exists. 

I've been waiting for someone to say "Let's come up with a generalized
representation for architectures and drive the emulation from that."
Sounds good in theory, though performance might be just a bit piggy.
On the other hand, a complete and accurate notation for representing
architectures would make it much easier to preserve the ones that no
longer exist, whether they work in real time or not. ISP/PMS? AHPL?
VHDL? Lisp? C? BASIC? ... ?

Rick.
smith@sctc.com    arden hills, minnesota

Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Scheduling in Shared Memory Multiprocessor Systems
Organization: Intel Corp., Hillsboro, Oregon
Date: Fri, 24 Jul 1992 05:56:49 GMT

Gould PN machines used a simple affinity algorithm:

    The run queue was divided into 32 priorities (each a single chain)
    - the classic BSD run queue.

    Find the highest priority group that had runnable processes.

    From this highest priority group, execute the first process that
    had most recently run on the CPU being scheduled (or the first process
    encountered, if no process found that had recently run on the
    CPU being scheduled).


--

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)
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: 22 Jul 92 16:39:56 MDT
Organization: Utah State University

In article <Brsx7o.G69@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes:
> Item 3 can still be
> an issue, particularly on old architectures with clunky interrupt handling,

What do you mean by "clunky interrupt handling"?

Roger Ivie
ivie@cc.usu.edu
From: haw30@macaw.ccc.amdahl.com (Henry A Worth)
Newsgroups: comp.arch
Subject: Re: MVC and MVCL (was Re: RISC Mainframe)
Date: 29 Jul 92 18:53:11 GMT
Organization: Amdahl Corporation, Sunnyvale CA

In article <1992Jul24.190506.6168@PA.dec.com> ed@pa.dec.com writes:
> > And since most of the code is written in assembly language to begin
> > with, compiler optimizations are moot.
> 
> I don't think this necessarily follows.  For example, one of the compiled
> languages for Alpha is Macro-32, i.e., VAX Assembly.  It's unusual to think
> of what started out as an assembly language to be run through a compiler,
> but there's nothing magic about it.
> 

   Except that a lot of old assembly code dates from an age when being	
self-modifing was a virtue... 

--
Henry Worth
No, I don't speak for Amdahl... I'm not even sure I speak for myself.
Xref: sparky comp.arch:8439 alt.folklore.computers:11464 comp.benchmarks:1216
From: mitch@novavax.UUCP (Mitch Silverman)
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
Subject: Re: dinosaur horsepower
Date: 29 Jul 92 21:56:49 GMT
Reply-To: mitch@novavax.nova.edu (Mitch Silverman)
Organization: Nova University, Fort Lauderdale, Florida

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?)
>
>Rick.
>smith@sctc.com        arden hills, minnesota

What kind of spool do you take me for?  8-)

Mitchell L. Silverman
Student, New College of the University of South Florida
mitch@cfraix.cfr.usf.edu
mitch@novavax.nova.edu
 
Newsgroups: comp.arch
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: Looking for Trace Driven Simulator
Organization: Digital Equipment Corporation
Date: 28 JUL 92 09:46:43    


In article <1992Jul27.174007.2892@tamsun.tamu.edu>, osborne@cs.tamu.edu (Aaron Osborne) writes...
>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.
> 
See:

Pnevmatikatos, D.N. and Hill, M.D. Cache Performance of the
Integer SPEC Benchmarks on a RISC. ACM Comp. Arch. News 18, 2 (June
1990), pp. 53-68.
From: ak@ananke.stgt.sub.org (Andreas Kaiser)
Newsgroups: comp.arch
Subject: 64-bit CPU vs 2 x 32-bit CPUs 
Distribution: world
Date: Tue, 28 Jul 92 04:15:41 GMT
Organization: ananke


In article <13754@auspex-gw.auspex.com> guy@Auspex.COM writes:

  > Unless, for example, your shared libraries are built in
  > position-independent form; SunOS 4.x/SVR4 shared libraries don't require
  > system-wide unique virtual addresses, for example.

How does SunOS handle references between different shared libraries?
Vector tables in memory local to the process?
  
  > Shared memories don't necessarily require them, either.

Of course systems can be designed to go without having the same virtual
memory address for shared memory (maybe Unixes are designed that way),
but it makes handling much more difficult, since you cannot put any
pointer in it. You have to use a position independant method to access
that memory, whereas usual C programming highly depends on pointers.

In OS/2, shared memory it is somewhat less magic than in Unix - whether
a DLL data area uses the same instance for all invocations of the DLL
or there is separate data for each, is no more than a bit in the
definition. Such a transparent method changes ones view of shared
memory. But it is hard to implement without globally assigned virtual
addresses for shared memory. Unless however, you define your own
programming language for the system.
  
  > Umm, the machine running on my desk has a 32-bit virtual address space,
  > and the OS on that machine supports memory-mapped files.

  > I would not be surprised if a movable mapping window like that weren't a
  > pain, though.

Easier as moving to 64-bit addresses (well, 43 ot 55 bits or whatever
is implemented in the first chips)?
  
:::::::::::::::::::: subnet:  ak@ananke.stgt.sub.org
:: Andreas Kaiser :: fidonet: 2:241/7220.9
::::::::::::::::::::
Newsgroups: comp.arch
From: tmm@dvnspc1.Dev.Unisys.COM (Tim McCaffrey)
Newsgroups: comp.arch
Subject: Re: What's in a name?
Date: 29 Jul 92 16:56:21 GMT
Organization: Unisys Corporation, Devon Engineering Offices

Interesting remark about CDs and backward compatibility.  I remember
several people making comments that CDs were a dumb idea because
they couldn't play them on their turntables.  There was even a letter
to Stereo Review from this guy who was looking for an adapter so
he could play CDs on his turntable.  He was also wondering if he
needed a special needle of some kind, because he wasn't getting any
sound...

				Tim McCaffrey
Newsgroups: comp.arch
From: zstern@adobe.com (Zalman Stern)
Subject: Re: 64-bit CPU vs 2 x 32-bit CPUs
Organization: Adobe Systems Incorporated
Date: Mon, 27 Jul 1992 16:27:34 GMT

In article <1992Jul26.044548.356@PA.dec.com> ed@weir.pa.dec.com (Ed Gould)  
writes:
> > Since the DEC 21064 Alpha chip only supports 43-bit effective virtual
> > addresses, the cost is approximately 43-32=11 pins.
> 
> According to the data sheet I have, the 21064 implements 43-bit virtual
> addresses (even though all 64 bits are checked), but only 34-bit
> physical addresses.  Hence, it's only *two* pins.  I can't imagine that
> that's particularly significant.
..And if I recall, the R4000 implements 40 bits of virtual and 36 bits of  
physical. Go figure... One reason these chips do this is because at straight  
32 bit virtual and physical their "high performance" nature becomes suspect.  
That is, its a product differentiation feature. And for some things its, a  
very important. For others its useless. I saw this disscussion during the  
16/32 bit microprocessor transition and I'm sure it came up during the 8/16  
bit one as well. A big difference now may be commercial multiprocessor  
software existing for microprocessor architectures. (And one of the most  
important pieces of such software probably won't go to 64 bits for a good  
while.)
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: Request Info Re Bus Trends & Intel 486s
Keywords: Intel 486 Bus
Reply-To: peter@ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Date: Fri, 24 Jul 1992 15:39:47 GMT

In article <1992Jul20.003506.23290@theus.rain.com> john@theus.rain.com (John Theus) writes:
> However, Futurebus+ is a backplane bus, not a desktop bus. [...]

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?
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: 21 Jul 92 13:10:48 GMT
Article-I.D.: mentor.54638
Organization: Purdue University Statistics Department

In article <l6mlr0INN7tu@spim.mips.com> mash@mips.com (John Mashey) writes:
>In article <1992Jul20.205209.28863@boole.uucp> John@boole.uucp (John Ahlstrom) writes:

>>Did anyone at work do a study of the utility of address modes independent 
>>of the speed of any particular implementation of them?  I doubt that an
>>ex post study of the implementated speed of modes is a good way to 
>>decide which ones are valuable to have.  Valuable to use in a give
>>compiler perhaps, but not valuable to have in an architecture.

>There have been plenty of papers that have addressed this over the years,
>usually in the form of:
>	a) Take a given CPU architecture+compiler pair, and analyze the
>	distribution of address modes.

The sensibility of this assumes that we have good languages/compilers.

>	(Note that this has implicit use of performance, i.e., you might
>	assume that agonizingly-slow modes might be avoided.)
>	On the other hand, if you find modes that are reasonably fast
>	(as fast as any equivalent sequence), and don't get used,
>	either:

>		1) The compilers can't figure out how to use them often.

We keep hearing that compilers can do as well as humans.  Now if a
human can figure out how to use these modes, don't blame the mode,
blame the compiler if it cannot figure out how to use it efficiently.

>	or	2) Most realistic code doesn't lend itself to the mode.

What is realistic code?  I will code differently if there is hardware
auto-increment for addresses.  I expect any good programmer to do as
well; I am not a professional programmer.

>	Hennessy & patterson have some discussion of this topic.

>	b) Of course, simple analysis of existing modes may tell you ones
>	that are not very useful, but they won't point out ones that
>	aren't present in the example, but would be useful.  That is,
>	to decide that auto-increment of some kind might be useful,
>	you have to do more detailed analyses of code sequences to see.

In other words, the programmer has to think about using the machine
capabilities, or there has to be in the compiler enough so that the
compiler will try out these capabilities.

			...................
-- 
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: clw@hprnd.rose.hp.com (Carl Wuebker)
Date: Thu, 23 Jul 1992 15:53:02 GMT
Subject: Re: Productivity != SPECmarks, crap-compatibility - what for? (Was: Re: What's in a name?)
Organization: HP STD Sys Ifc Lab
Newsgroups: comp.arch


> ... this need to constantly purchase "newer, faster, better" processors is 
> created by the media and salescritters... they prey upon the emotions of the
> consumer, convincing him that unless he upgrades his antiquated system, a 
> horrible fate awaits him.  Their chant is well known: "no longer in 
> production", "no longer supported", "too slow to run your software".  The
> bottom line is that the customer is held hostage to the very machine that 
> was supposed to set him free.

     I agree... in some cases.  In my HP location, we have several killer
applications (PC board routing, digital simulation & manufacturing [digital]
test generation) that faster processors really help.  As an example, we had
one PC board route which needed 48 hours with an older machine, but which
completes in 3 hours on a HP9000 s750 [Snakes] system (Disclaimer: I can
demonstrate this one real example, but your speedup may vary :-).  If you 
factor in the PC layout designer idle time and extra "time until the PC board
is done" using the old system, the Snakes system pays for itself very quickly.

Thanks,
    Carl Wuebker * HP Roseville * clw@hprnd.rose.hp.com * (916) 785-4296
From: baxter@clipper.ingr.com (Bill Baxter)
Newsgroups: comp.arch
Subject: Re: Code Repositioning on MIPS Systems?
Summary: Yes there are companies that are repositioning within procedures
Date: 31 Jul 92 16:33:51 GMT
Organization: Intergraph Advanced Processor Division - Palo Alto, CA

In article <32580131@hpcuhe.cup.hp.com>, daryl@hpcuhe.cup.hp.com (Daryl Odnert) writes:
> According to the information I've been sent via e-mail, MIPS has a
> postprocessor tool called "cord" which can reposition the procedures
> within an executable file so that run time cache conflicts will
> be reduced.  The positioning is guided by information in "feedback
> files" which are generated by the "prof" command with the -feedback
> option.
> 
> Does anyone know of any existing tools or planned enhancements to cord
> that will reposition the basic blocks of code within procedures so that
> taken conditional branches are reduced?  Is anyone aware of any tools
> or compilers that perform this optimization on ANY existing architecture?
> 
> Daryl Odnert     daryl@cup.hp.com
> Hewlett-Packard
> Cupertino, California

Daryl,

We published an article in the 1991 COMPCON proceedings and feedback directed
optimizations on the C400 architecture.  We don't exactly implement the
algorithms in that paper, but the affect is pretty much the same.
We use feedback directed optimi- zations to do such things as reorder
conditional branches to reduces the frequency of branches taken, guide
global register allocation, and speculative delay slot filling.  We have
used these optimizations for our SPEC publication, and they generally
available in the compiler.  In addition to the optimizations we currently
perform and ones we will soon be performing, the feedback information is
also valuable for programmer feedback.  We have implemented instruction
frequency analysis tools, call graph analysis tools, and test coverage
generation tools.


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Bill Baxter   Compiler Group: Advanced Processor Division   (415)852-2333
baxter@clipper.clipper.ingr.com  ----  2400 Geng Rd., Palo Alto, CA 94303
Newsgroups: uw.neural-nets,comp.arch
From: ice@skynet.uucp (Ice)
Subject: Instruction sets for neural net chips?
Organization: Industrial Cybernetics
Distribution: uw
Date: Mon, 27 Jul 1992 17:34:53 GMT


Hello.

Does anyone have familiarity with the instruction sets used in neural
net chips?

There must be instructions (perhaps) like:

CLW	->	clear weights
FRZ	->	freeze connections
CMP	->	compare values (presumably for use in a learning rule)


What would DEFINITELY be necessary control instructions that a neural
net chip should have to be useful and flexible?
From: dafuller@sequent.com (David Fuller)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Organization: Sequent Computer Systems Inc.
Date: Thu, 23 Jul 92 19:34:48 GMT

In article <2105@devnull.mpd.tandem.com> rrt@amadeus.UUCP (Robert Teisberg) writes:
>In article <2369@nic.cerf.net> davsmith@nic.cerf.net (David Smith) writes:
>>All CPUs I have seen to date (not every CPU by any means - if you know
>>of counter examples, please post) cannot do asynchronous address
>>generation.
>
>The CDC 6600 and its descendants did this (why does it seem that every
>clever idea in machine architecture was invented many years ago by
>Seymour Cray :-).  To load from memory, you stuffed an address in
>register A1, A2, A3, A4 or A5 and sometime later the contents of that
>address appeared in the corresponding X register.  To store, you
>stuffed an address in A6 or A7 and eventually the contents of X6 or X7
>found its way to memory at that address.  As I recall (do any other
>old CDC hands know better?), the only reason the CPU stalled due to
>memory access was a scoreboard conflict or a memory bank conflict.  If
>your memory access pattern was either sequential and contiguous or
>random, bank conflicts were rare, since the 6600 used interleaved
>memory just as davsmith recommends elsewhere in his article.

What I recall:

The PPUs had first access to memory, then the CPUs.  The PPUs could hold the
CPU out of main memory if they tried hard enough.
-- 
Dave Fuller		 	All opinions expressed are my own and not
Sequent Computer Systems	those of Sequent Computer Systems, Inc.
dafuller@sequent.com
Newsgroups: comp.arch
From: pchris@dcc.uchile.cl (Chris Perleberg)
Subject: SparcStation Questions
Originator: pchris@pehuen
Date: Thu, 23 Jul 1992 16:34:23 GMT
Reply-To: pchris@dcc.uchile.cl
Organization: Universidad de Chile, Depto. de Ciencias de la Computacion


Looking through the /usr/include/sun4/param.h file on some Sun Sparcs, I came
across a few things I could use some help on:

> /
>  * Define VA_HOLE for machines that have a hole in the virtual address space.
>  */
> #if defined(SUN4_260) || defined(SUN4_110) || defined(SUN4_330)
> #define VA_HOLE
> #else
> #undef VA_HOLE
> #endif SUN4_260 || SUN4_110 || SUN4_330

What size is this virtual address hole on the Sparcs listed above?  Does this
mean these Sparcs do not have a full 32 bit address space (and others do), so
some programs will run on some Sparcs and not on others?

> /*
>  * Define BCOPY_BUF if we could run on machines that have a bcopy buffer.
> */
> #ifdef SUN4_470
> #define BCOPY_BUF
> #else
> #undef BCOPY_BUF
> #endif SUN4_470

What does this bcopy buffer on the 470 look like?  What size is it?

> /*
>  * Define IOC if we could run on machines that have an I/O cache.
>  */
> #ifdef SUN4_470
> #define IOC
> #else
> #undef IOC
> #endif SUN4_470

What does this I/O cache on the 470 look like?  What size is it?

> /*
>  * Define the MMU_3LEVEL symbol if we could run on a machine with
>  * a three level mmu.   We also assume these machines have region
>  * and user cache flush operations.
>  */
> #ifdef SUN4_470
> #define MMU_3LEVEL
> #else
> #undef MMU_3LEVEL
> #endif SUN4_470

What does this 3 level mmu on the 470 look like?  What does the normal mmu
on the other Suns look like?

Thanks for any help,

	Chris Perleberg
	pchris@dcc.uchile.cl
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Finding which bit set in a bit-string.
Keywords: Bit-counting.
Date: 28 Jul 92 16:01:58 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Jul27.212607.26361@infonode.ingr.com>, aaronb@suhana.analog.ingr.com (Aaron B.) writes:

| I posted this on "comp.compression":
| 
| >Given a bit-string of any size print out the bits set starting with the
| >least significant bit.

  Doing it in C, you don't want a bit by bit test, you want a branch
table. A byte is too slow with a switch, so use a procedure vector:

	void (*showbits[256])();

Then write 256 procedures which each print all the bits set in one
particular bit pattern. If you want offset from bit zero add it as a
global variable (passing as arg is slower).

  I did a CPU emulator using this once, and it's *fast*, but complex.
Much faster than any bit by bit operation. Of course you can extend this
to do 16 bits at a time, or even 32 when you get your 64 bit micro with
a TB of memory.
-- 
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: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: BUSES and other things
Date: 26 Jul 92 16:09:25 GMT
Organization: Purdue University Statistics Department

In article <13742@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>>>Besides speed, what else do you think is important in a desktop bus?

>>For the hundreds of thousands of users (this is a conservative estimate
>>based on observations at a few universities) who do mathematical typing,
>>an extremely important thing to have would be a large variety of characters
>>available for simultaneous display on the screen,

>Well, the machine on *my* desktop can display quite a variety of
>characters...

>...because the hardware doesn't know beans about characters; the
>software can turn pixels on and off as it chooses.  It's the *software*
>that's responsible for having the characters available.

At what speeds, and with how large a source file?  Certainly, at some
point the coded characters have to be translated into pixels; even the
dumbest terminals did this.

>(And if you're going to argue that "bitmapped displays are the wrong
>answer", you'll have to explain why your favorite solution is better;
>I'm sure not going to simply take your word for it....)

Now I am not quite sure how much is software and how much is hardware;
I suspect that it varies considerably between machines.  But I would
prefer a dumb terminal with a downloadable character set of size 2^10,
and which is easily user-modifiable, to the clumsiness of something
like TeX.  And I want an easily readable source file, not like those
clumsy messes on the Macs.
-- 
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)
Xref: sparky comp.arch:8431 alt.folklore.computers:11451 comp.benchmarks:1215