HDTenEightyP/NetNews huggingface dataset:
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: hardware sorting
Date: Fri, 6 Nov 1992 20:21:27 GMT
Organization: University of Iowa, Iowa City, IA, USA

From article <1992Nov6.165252.21619@infodev.cam.ac.uk>, by swm11@cl.cam.ac.uk (Simon Moore):
> 
> I have a requirement for a hardware sorter to sort
> deadlines for high speed real-time earliest deadline
> first scheduling.  New deadlines can arrive at a peak
> rate of one every cycle and the earliest deadline
> needs to be extracted every 8 cycles.

You don't want a hardware sorter, you want a hardware priority queue, aka
heap manager.  Yes, work has been done on this.  For example, Quinn and
Deo have surveyed some early work on this in their Sept 1984 paper in
Computing Surveys.  Since then, other work has been done on priority queues
(by me, for example), but mostly focusing on high speed software
implementations.  I don't know if anyone has translated the best of these
results to useful hardware.
				Doug Jones
				jones@cs.uiowa.edu
Newsgroups: comp.arch
From: caperkin@ursa11.law.utah.edu (Charles Perkins)
Subject: Re: 600 transistor CPU (was: MINIMUM instruction set)
Summary: Program the FLASC?
Organization: University of Utah College of Law
Date: Fri, 13 Nov 92 16:04:42 GMT

In article <1992Nov13.104602.10923@odin.diku.dk> torbenm@diku.dk (Torben AEgidius Mogensen) writes:
>caperkin@ursa11.law.utah.edu (Charles Perkins) writes:
>
>>This caught my attention because of an idea I have been toying with, which
>>I have decided to call the Fractal Logic Asynchronous Scalable Circuit.
>>(Basically a 'memory' where every cell is a finite state autonoma 'conversing'
>>with the cells next to it.)  I figure eight thousand of the little guys on a 
>>chip, simple though they might be individually, could get some serious
>>computation done.
>
>Have you considered how to program such a beast? And on the hardware
>side, how do you load a program?
>
>	Torben Mogensen (torbenm@diku.dk)

It wouldn't be in C.

Actually, the whole idea is to break out of the VN bottleneck.
I imagine the architecture would be best suited to a wierd variant of prolog.
Each cell, when queried, could (hypothetically) either return it's value
(true or false) or (in conjunction with cells next to it) query other cells
to determine what it's value ought to be, then report that.

Thus there would be facts and rules.  The more complicated a query, the more
branching and parallel action occurs.  (The organization of the cells
would also follow a tree structure, rather than a linear or array structure,
for several reasons.  The main reason being the 'Scalable' in the acronym.)

Programming would be through set, rather than query location.

I would hate to port X to it, though.

-- 
 .8Chuck .2AlexanderGrahmBell
 perkins@ursa11.law.utah.edu
 "I am not a potted plant."
Newsgroups: comp.arch
From: tlilley@jarthur.claremont.edu (Thomas (Ted) Lilley)
Subject: Re: Hardware Support for Numeric Algorithm
Organization: Harvey Mudd College, Claremont, CA 91711
Date: Fri, 13 Nov 1992 19:59:26 GMT

In article <1992Nov13.141300.3528@clark.dgim.doc.ca> don@mars.dgrc.doc.ca writes:
>I believe correct results are far more important to Herman than the wrong answer
>3 times as quickly.  Therefore the folks arguing over which is more important,
>correctness or speed, are also wasting bandwidth.

Hi,
	There is one comment I'd like to make on this, which is that no one
who's mentioned correctness and speed has discussed it properly, which is to
say, in terms of the expected running time to find the correct answer.

If there exists an algorithm which runs 6 times as fast as Herman's current
algorithm, but gives a wrong answer 1/3 of the time, then he might expect to
have to run it 3 times for a correct answer, which is still twice as fast as
his current algorithm.  Since factorization is easy to check, a wrong answer
would not impose any serious time costs in that event.

So you see, you should not argue over which is better, correctness or speed,
without considering which type of algorithm you can expect to give you the
right answer in which amount of time.

I expect Herman already knows this, as most people who work with numeric
algorithms of that sort are familiar with probabilistic algorithms and
analyzing their running time.

Ted
Newsgroups: comp.arch
From: meissner@osf.org (Michael Meissner)
Subject: Re: Integers implementation
Organization: Open Software Foundation
Date: 6 Nov 92 16:19:26

In article <1992Nov6.144502.17520@osf.org> fabre@gr.osf.org (Christian
Fabre) writes:

| --
| Hello,
| 
| I have a question about integers representation.
| 
| Most of today architecture use 2's complement scheme to represent
| signed integers. About other possibilities, like 1's complement,
| I have the following questions:
| 
	...

|  - What are their drawbacks ?

2's complement has a negative number without a postive counterpart.
This means that abs function either will return 1 result that is
negative, or will signal some exception.

1's complement and signed magnitude have -0 which plays havoc with
things like bit masks.  Also, in 1's comp, addition is done via a
subtractor.

	...

|  - Are they likely to pop-up in future processor design ?

I suspect not, particularly if you want to run C.
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

You are in a twisty little passage of standards, all conflicting.
Newsgroups: comp.arch
From: dhesi@cirrus.com (Rahul Dhesi)
Newsgroups: comp.arch,comp.unix.bsd,comp.os.linux
Subject: Re: IDE faster than Mips SCSI disk
Date: 7 Nov 92 00:34:24 GMT
Organization: Cirrus Logic Inc.

In <1992Nov6.033942.21194@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg
(Othman Ahmad) writes:

>IDE is just a simple interface definition, just like SCSI-2, but IDE,
>is optimised for HARD DISKS, SCSI is not. SCSI is more general purpose.

IDE simply means "integrated drive electronics", i.e., the disk
controller is on the drive.  It is NOT a disk interface standard.  The
interface with which IDE drives are normally used is the standard AT
interface.

While there is some merit in the IDE versus SCSI argument, the real
argument is whether SCSI is or is not better a more dumb interface.
However, IDE versus SCSI is a false dichotomy, because two orthogonal
things are being compared:  (a) Where the disk controller is, and
(b) How smart the disk controller is.
-- 
Rahul Dhesi <dhesi@cirrus.com>
also: dhesi@rahul.net
From: khb@chiba.Eng.Sun.COM (Keith Bierman fpgoup)
Newsgroups: comp.arch
Subject: Re: RTX and SC32
Date: 5 Nov 92 19:43:20
Organization: Sun MegaSystems
NNTP-Posting-Host: chiba
In-reply-to: cliffc@rice.edu's message of 5 Nov 92 16:13:57 GMT


In article <CLIFFC.92Nov5101357@miranda.rice.edu> cliffc@rice.edu (Cliff Click) writes:

   And now a soapbox:

   Compiler technolgy is driven by computer archetectures.
   If a big-name company produced a blazing stack machine and handed a few
   out to CS departments doing compiler research, compiler researchers 
   (like myself, hint, hint) would find the moral equivalent of the
   "graph coloring register allocator" for stack machines.


The A series machines from UNISYS date back to the early sixties. They
are stack machines.

Do they have to throw more than 30 years of machines out to attract CS
researchers? 

It is possible that some optimizer writers have looked at stack
machines more than once ;>
--
----------------------------------------------------------------
Keith H. Bierman    keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM
SunPro 2550 Garcia MTV 12-40             | (415 336 2648) fax 964 0946
Mountain View, CA 94043  <speaking for myself, not Sun*> Copyright 1992
From: karhinen@klaava.Helsinki.FI (Anssi Karhinen)
Newsgroups: comp.arch
Subject: Re: What's wrong with stack machines?
Date: 5 Nov 92 06:51:16 GMT
Organization: University of Helsinki
X-Newsreader: TIN [version 1.1 PL6]

Nick Janow (Nick_Janow@mindlink.bc.ca) wrote:
> 
> Chuck Moore's P20 (20-bit Forth processor) is supposed to have a 200 MHz
> internal clock, using 1.2 um technology.  It has fewer than 10,000 (maybe
> 6000) transistors, which probably means that trace length isn't as much of a
> speed limiter as on something like the 486.  Scale the P20 down to .5 um, or
> whatever Alpha is supposed to use, and 400-700 MHz doesn't sound unlikely.
> 
> --
> 
> Nick_Janow@mindlink.bc.ca

Has the P20 chip been implemented yet? Is there any performance
data or estimates?
Any technical info on the P20?

Sure sounds like an interesting chip among all the new multimillion
transistor CPUs. Could P20 deliver cheap MIPS in a multiprocessor?


cheers Anssi
Newsgroups: comp.arch
From: styer@ms.uky.edu (Eugene F. Styer)
Subject: Re: 600 transistor CPU (was: MINIMUM instruction set)
    <1992Nov11.144304.10494@news.uiowa.edu> 
    <1992Nov12.164510.28248@dartvax.dartmouth.edu>
Date: Fri, 13 Nov 1992 15:52:38 GMT
Organization: University Of Kentucky, Dept. of Math Sciences

In article <1992Nov12.164510.28248@dartvax.dartmouth.edu> stevel@coos.dartmouth.edu (Steve Ligett) writes:
>Somewhere I have a copy of an article (or two) titled
>
>"A design for a 16 bit processor using only 600 transistors"
>
>from Microelectronics Journal, Vol 15, Nr 3,
>copyright 1984 Benn Electronics Publications Ltd, London
>
>The machine has 4 instructions: three subtracts, and one bit clear.
>
>I'll try to find and reread the articles if it would be of interest.
>-- 
>steve.ligett@dartmouth.edu
>Sign in our Machine Room:  Before Leaving Please Lock Door Behind You

I don't have that article any more (at least where I can find it), but I do
remember it.  I decided that if his goal was a small CPU to watch over things,
he would do better to have (say) 8 instructions and include load, store, etc.
My conclusion was that the additional size of the processor (I estimated 1000-
1200 transistors) would be more than balanced by the smaller programs required
(1/2 or smaller) for programs as small as a few hundred instructions.  If his
goal was the fewest number of instructions, then other posts have indicated he
has 3 too many instructions.  All in all, it was an attempt to be more practical
than most of the minimal-instruction systems.

Eugene Styer - 402 Wallace, EKU, Richmond, KY 40475  matstyer@eku.bitnet
"And to think I had a nice, safe career going for me putting mafiosi in jail"
-- 
Eugene Styer - 402 Wallace, EKU, Richmond, KY 40475  matstyer@eku.bitnet
"And to think I had a nice, safe career going for me putting mafiosi in jail"
Xref: sparky comp.arch:10485 comp.lang.forth:3453
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch,comp.lang.forth
Subject: Re: What's wrong with stack machines?
Keywords: register allocation, stack cache
Date: 6 Nov 92 22:46:20 GMT
Followup-To: comp.arch
Organization: Auspex Systems, Santa Clara

>There is a perspective on RISC/register based architectures and CISC  
>and/or stack based machines.

Err, does that mean you're throwing CISC machines into the same pile as
stack-based machines?  Most of the CISC architectures I've dealt with
are register based, even though they have memory-to-register or
memory-to-memory arithmetic; i.e....

>It is: when and how do you do register
>allocation.  On a RISC machine the compiler does it.

...on those CISC machines, the compiler does it as well.

>On a stack machine
>the hardware does it on-the-fly, i.e., a particular data value or variable
>gets allocated to a specific hardware register during execution.

Hmm.  I no longer have the paper, but I seem to remember seeing a paper
on compilers for stack-based machines that, as I remember it,
essentially had the notion of Sethi-Ullman numbers for stack machines; I
think the goal was to reduce the maximum stack depth required to
evaluate an expression.

I.e., I'm not convinced that all the work of "register allocation" is
always done, or should always be done, in hardware *even on stack
machines*.

(Trivial example: you can evaluate a+b+c+d as

	push a
	push b
	push c
	push d
	+
	+
	+

or you can evaluate it as

	push a
	push b
	+
	push c
	+
	push d
	+

If the machine has only two top-of-stack registers, the second example
may be better than the first.)
From: rf@cl.cam.ac.uk (Robin Fairbairns)
Newsgroups: comp.arch
Subject: Re: Mixing Greek/Latin in product naming (was: Re:<None>)
Date: 10 Nov 92 12:09:58 GMT
Organization: U of Cambridge Computer Lab, UK

In article <1992Nov9.184247.2626@lsl.co.uk>, snail@lsl.co.uk writes:
|> In article <1cok6sINN25m@iraul1.ira.uka.de>, S_JUFFA@iravcl.ira.uka.de (|S| Norbert Juffa) writes:
|> > or automobile (auto being Greek, mobil- being Latin, in pure Latin it would be
|> > a ipsemobile or some such)? I am sure there are more good exaxples, but I know 
|> > too little Greek/Latin to come up with them right away.
|> 
|> In England, I think we'd call it a motor car. Which two languages is that
|> descended from? :-)

Latin and Latin (respectively).
--
Robin (come back John Drummond) Fairbairns       rf@cl.cam.ac.uk
U of Cambridge Computer Lab, Pembroke St, Cambridge  CB2 3QG, UK
"They had twelve years to lay in wait for us" - Bush supporter on Nov 4
Newsgroups: comp.arch
From: k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
Subject: Re: IDE faster than Mips SCSI disk
Organization: Leibniz-Rechenzentrum, Muenchen (Germany)
Date: Mon, 9 Nov 1992 10:17:58 GMT

tgcpwd@rw9.urc.tue.nl (Wim van Dorst) writes:

>Klaus Steinberger writes:
>>	1520363 bytes/second for writing the file
>>	1736771 bytes/second for reading the file

>Others have written results for ordinary 386s with plain IDE disk
>in the range of 200-500 kB/s. I tried it at my home PC and I got
>similar results. 

>However, I always thought that those VAX/VMS machines at work were
>awfully slow. So I tried iozone there too. It compiled without a
>glitch, and gave results in various machines (workstations up to
>large VAX-6410s) with various disks (RA type, RF type, other) 
>results in the range 15-40 kB/s. 

>What does this mean: Are the disks really that slow? Is the VMS
>version of iozone different? Is the OS that significant?
I did the same test with same results, and I suspect its due to
a very bad implementation off the read/write call emulation in VAXCRTL .

I did have VMS Posix running on my VAX, and it gives indeed better
results. I'm seeing results in the 200 - 300 kBytes/sec range.
(A little MVIII, with SMD disks, platter rate around 2Mb/sec).
I did not know how well the Posix environment did emulate Unix
system calls, so I think native VMS programs with their ugly $QIO
interface will see better rates.

Sincerely,
Klaus
--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
Internet: Klaus.Steinberger@Physik.Uni-Muenchen.DE
Newsgroups: comp.arch,comp.lang.forth
From: NetCmmnd@boole.uucp (System Administrator)
Subject: Re: What's RIGHT with stack machines (Was Re: What's wrong...)
Keywords: stack computers, embedded control
Organization: Boole & Babbage, Inc.
Date: Thu, 12 Nov 1992 20:48:52 GMT

Where are the Hobbit people in this thread?

John Ahlstrom
Boole & Babbage
408-524-3307

I can neither confirm nor deny that
this question is interesting to anyone else.
Newsgroups: comp.arch
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: BCD Addition
Organization: Keith's Computer, Hope Mills, NC
Date: Sat, 07 Nov 92 17:50:00 GMT

In article <1992Nov4.151413.4203@odin.diku.dk> thorinn@diku.dk (Lars Henrik Mathiesen) writes:
>campbelr@hpcuhe.cup.hp.com (Bob Campbell) writes:
>>Well, since PA-RISC supports BCD directly ...
>
>To be more precise: PA-RISC maintains carry bits for each BCD digit,
>which allows BCD addition/subtraction using a decimal correct
>instruction after each normal ADD/SUB. (It has IDCOR to re-bias
>intermediate results, and DCOR to un-bias final results.)

[examples deleted]

Which probably explains why HP is doing well in the business markets.
I find it amusing that probably WAY more than half of the CPU cycles
expended on this globe are probably for some business purpose, but that
the CPU chips are often noticeably slanted to scientific use in their
design and handling of numbers.

Heck I use arctan and sin all the time at work ...  That SPECfp test is
REAL important to the zillions of business users out there.  Of course
it is the reasearch orginizations that are designing the stuff in the
first place, so they obviously are slanted to the scientific.
-- 
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
Newsgroups: comp.arch
From: pnevmati@milhouse.cs.wisc.edu (Dionisios N. Pnevmatikatos)
Newsgroups: comp.arch
Subject: Re: MIPS R4400
Date: 10 Nov 92 06:06:04 GMT
Article-I.D.: cs.pnevmati.721375564
Organization: U of Wisconsin Madison - Computer Sciences

bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar) writes:


>In article <lftam5INNgoi@exodus.Eng.Sun.COM>, walter@zarquon.Eng.Sun.COM (Walter Bays) writes...
>>>In article <JCALLEN.92Nov6135200@marley.think.com> jcallen@marley.think.com (Jerry Callen) writes:
>>>[I was surprised to see MIPS use SPEC 89 numbers...]
>> 
>>I also wonder why you would use the old 89 suite.  Was it that some of
>>the new 92 benchmarks are too complicated to simulate, in particular
>>026.compress and 072.sc?  (I believe there are ways around the
>>difficulties.)  But even if SPECint92 was intractable, can't you at
>>least simulate SPECfp92?
>> 
>Simulation is slow and often difficult when a benchmark does I/O. It is a lot
>easier to do 10 benchmarks that have been around for 3 years, than it is to do
>20 relatively new ones. With SPEC89 numbers in detail, one can make reasonable
>guesses at SPECint92 and SPECfp92.

>Dileep

Both SPECint89 and SPECint92 have IO calls. It's really not so hard to
simulate the IO calls provided that the host machine runs the same OS as
the simulated one. We have a R2000 simulator here at the UW-Madison that
can simulate the entire SPEC benchmark suite (Both 89 and 92 :-).

-Dionisis
-- 


   Dionisis

+--------------------------------+-------------------------------------------+
| Dionisios N. Pnevmatikatos     | Email: pnevmati@cs.wisc.edu               |
| Computer Sciences Department   | Phone: (1) 608/262 1721, (1) 608/255 0840 |
| University of Wisconsin-Madison| Fax:   (1) 608/262 9777                   |
Newsgroups: comp.arch
From: val@news.ccutah.edu (Val Kartchner)
Subject: MINIMUM instruction set
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Tue, 10 Nov 92 23:58:49 GMT

I've heard that it is possible to implement all programming languages with
seven instructions.  (Possible does not mean practicle.)  Does anyone know
what these instructions are?  Is it possible to do all operations in less
than seven instructions?

--
|===== The previous was my opinion -- val@csulx.weber.edu =====///============|
| "AMIGA: The computer for the creative mind." (tm) Commodore /// Weber State |
| "Macintosh: The computer for the rest of us."(tm) Apple \\\///  University  |
|============== "I think, therefore I AMiga." =============\///=== Ogden, UT =| 
Xref: sparky comp.arch:10717 comp.lang.misc:3648
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Summary: so simple only a programmer could understand it
Date: 13 Nov 92 01:08:26 GMT

: From: hrubin@pop.stat.purdue.edu (Herman Rubin)
: Message-ID: <BxLupy.M9K@mentor.cc.purdue.edu>
: There is a price for programming in what the languagists think is clean
: code.  Nobody except a computer programmer can read it at all!

I'm not sure I follow this.  If one is "programming", then one is
playing the role of a "computer programmer", whether one's vocation
is statistics, or engineering, or (shudder) business administration.

The similar complaint that "those statisticians and their screwey
sums-over and chi-squares and their standard deviations!  Nobody can
read their arcana except other statisticians!  Boy are they silly and
introverted!" is clearly false to me, despite my not being a
statistician.  Since this sort of statement, whether about mathematics,
or medical jargon, or blueprints, or (even) programming seems so
clearly false, I'm left wondering what Herman might mean by his
comments about "clean code" above.

If you want to play the game, you at least have to learn the rules.

: [.. I was ..] asked for another copy of the code where the control-path
: was "clear" and not defined by breaks or gotos.

Well...  I agree that if the algorithm is well-modeled by using 
gotos, it is pretty much a DISimprovement to render it into
if/then-while-sequence form.  I am not especially goto-phobic myself,
nor (seemingly) is Peter da Silva.  Did anybody really find Peter's
rewrite so arcane that "nobody except a computer programmer 
can read it at all"?  I, for one, found it much more readable.

: We still have the problem of what is comprehensible to whom.  

That's true, but if one wants to program a computer, it seems to me
it behooves one to become familar with the jargon of the trade.  Just
as (say) a biologist had better become fluent in statistics if that
biologist wants to do sound work in population genetics.

: And what
: is one supposed to do if the hardware operations wanted are not even
: expressible in the language?

Use another language (or implementation).



( Use of the term "jargon" above is in its "techspeak" meaning,
  not in the cannonical "hacker's" jargon meaning... )
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
From: cliffc@rice.edu (Cliff Click)
Newsgroups: comp.arch
Subject: Re: RTX and SC32
Date: 6 Nov 92 15:37:30 GMT
Article-I.D.: dawn.CLIFFC.92Nov6093730
	<CLIFFC.92Nov5101357@miranda.rice.edu> <Bx96zn.ME@rice.edu>
Organization: Center for Research on Parallel Computations

preston@miranda.cs.rice.edu (Preston Briggs) writes:
> cliffc@rice.edu (Cliff Click) writes:
> >I try to compare a popular RISC (Sparc) to a hypothetical Forth machine,

> >An 8 bit opcode can reference the top 16 stack elements, so 32 bits can
> >do a "push r1", "push r2", "op", "pop r3" - basically imitate a 3-address
> >instruction.  And I've seen the chip which can do all 4 in 1 50Mhz cycle
> >(really it was a 200Mhz internal clock).  No Viking technology here, it was
> >under 33,000 transistors.

> I keep seeing stack machine proponents bragging about small numbers of
> transistors.  Aren't most of the forth chips 16 bits (or 21 or
> whatever)?  With no FP.  And no support for virtual memory?

Yes, no FPU, no virtual memory, no cache (other than the stack cache),
and really old process technology.  The question is: given "equivalent"
technology will a stack-oriented machine do better than a register-oriented
one?  Here "equivalent technology" means that a major chip house plunks
down an FPU, big caches, virtual memory support, etc around a stack-oriented
core IU.

> Now about clock rates.  A 50 MHz external clock, accomplishing 50 M
> 3 address equivalents.  That's 1/4 of a 200 MHz Alpha, right?

Yup, and several years more ancient process technology as well. 
Had DEC done the Forth chip we might have been staring at 400+ Mhz 
internal clocks...

> About pipelining...  What are you going to do when you have to do FP?
> Spend several cycles per FP-ADD or pipeline?

Stack-oriented stuff can be pipelined; you will probably have to do the
moral equivalent of register renaming on stack slots.

Cliff
--
Through a gentle rain / the moon throws silver shadows /
and tears fall like pearls.                    Cliff Click (cliffc@cs.rice.edu)
Newsgroups: comp.arch,comp.lang.misc