HDTenEightyP/NetNews huggingface dataset:
From: tlilley@jarthur.claremont.edu (Thomas (Ted) Lilley)
Subject: Re: MINIMUM instruction set
Organization: Harvey Mudd College, Claremont, CA 91711
Date: Mon, 16 Nov 1992 10:03:40 GMT

In article <1992Nov15.134100.13188@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
>Scott Dorsey (kludge@grissom.larc.nasa.gov) wrote:
>: 
>: It's possible to build a machine with a single instruction (subtract and
>: skip if equal), but definitely not practical.  I believe a student at U.
>                      ^^^^^^^^^^
>YOu can't say that. Based on my current thinking this is the future of a new
>class of SUPER INTELLIGENT machines, that cannot crash. After all , there is
>only one instruction(conditional).
>	I've a strange feeling this is the way our mind works. 

Make a better idiot-proof box and we'll make a better idiot.  Seriously, do
you think computers always hang and crash because of an illegal instruction?
There's way too much involved in the scheduling, the OS, etc. that even if
you can't execute an illegal instruction, the machine will still choke on
bad code.  Besides which, what happens when somebody makes a coding mistake,
and branches to the wrong place?  The machine will start executing the wrong
instructions, perhaps not instructions at all, and it's behavior then is
undefined.  To sum up, bad instructions  come from the programmer (or compiler,
or whatever is between the programmer's mind and the machine code) not the
instruction set.  There will always be bugs.  Not to say that we can't
minimize them, but show me "crash-proof" and I'll show you an ill-tested
system.

As for the philosophy, who knows, you may be right.

Ted
Newsgroups: comp.arch,alt.folklore.computers
From: sl@wimsey.bc.ca (Stuart Lynne)
Subject: Re: What happened to the UCSD p-System?
Organization: BC News and Mail
Date: Sun, 22 Nov 1992 23:17:59 GMT

In article <51781@drilex.dri.mgh.com> dricejb@drilex.dri.mgh.com (Craig Jackson) writes:
>In article <8qmiuB1w164w@hub.parallan.com> richardw@hub.parallan.com (Richard Walter) writes:
}>(Info-world, I think) that Microsoft is writing some windows application
}>(I think it was a database) in p-code for some reason.  (I know that
}>this last bit sounds really, really hazy, but I do know that I saw
}>the headline with something like "Microsoft brings back P-Code" (there

}I have been told that many Microsoft applications over the years, back to
}the original PDP-11/45 Xenix, used something like P-code.  I believe this is
}one reason why that Excel and Word for the Macintosh and Windows until
}recently didn't exhibit the segment structure normally found in
}applications on those platforms.

}I think that something like Pcode is the only likely explanation why
}Multiplan ran on everything in sight at one point in the mid-'80s.

I remember hearing about this in the early 80's. Rumour had it that they
did cross development on larger systems (DEC 10's??).

Need to cross post this to alt.folklore.computers.

-- 
Stuart Lynne <sl@wimsey.bc.ca> ....................... UNIX Facsimile Software
Wimsey Information Technologies ................... moderator biz.sco.binaries
uucp login:nuucp passwd:nuucp .................. ftp.wimsey.bc.ca:~ftp/ls-lR.Z
PD Software for SCO UNIX .................. ftp.wimsey.bc.ca:~ftp/pub/wimseypd
Newsgroups: comp.arch,comp.lang.misc
From: bret@technix.mn.org (Bret Indrelee)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Private System - Saint Paul, MN
Date: Fri, 20 Nov 1992 05:46:03 GMT

In article <BxxGKp.81A@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>The statistician will need numerical analysis jargon.  That computer 
>jargon diverges from this is essentially a move on the part of the
>computer language designers to distance themselves from mathematics.
>They have been too succesful in this.

You could say the same thing in terms of Electrical Engineering or
Chemistry moving too far from Physics.


All of these fields use quantum mechanics.

Each has their own focus.

In physics, the objective is to create the most accurate model possible.

In chemistry, the strength of bonding and energy exchange is usually
the most important consideration.

In Electrical Engineering (IC design) the energy gap (how easy to push
an electron accross a gap) is more important.

The models used by each consider different details.  The EE would want
the simplest model, so that they can try different arrangements and
create the basic building blocks that make up NAND gates and memory
cells.  If electron spin isn't important in the interaction, then the
EE would not want it in the model.  They also don't tend to think in
terms of which 'shell' the electrons are at, but rather what the
energy gap between the shells are.


The focus of a computer programmers work is much different than
a mathematicians.  The mathematician can prove that an algorithem
works, and be done with it.  A computer programmer that doesn't
worry about how many steps the algorithem takes (how long to
complete a run) is going to get into lots of trouble.

Different focus.  Different jargon.  Each can ignore different details.

Since people get confused when they have to process too much information
simultaneously, this focussing on only parts of the whole problem is
not only good but necessary.


-Bret
-- 
------------------------------------------------------------------------------
Bret Indrelee               |         Insanity is all in the mind.
email: bret@technix.mn.org  |   
Xref: sparky comp.arch:11042 comp.arch.storage:796 comp.sys.super:1072 comp.databases:8049 comp.compilers:1941
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Purdue University Statistics Department
Date: Mon, 23 Nov 1992 21:58:00 GMT

In article <1992Nov22.192342.10288@qb.rhein-main.de> vhs@rhein-main.de writes:
>In article <1efg1gINNm6c@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
>> akao@.com (Adam Kao) writes:
>> : In article <Bxv2t2.4FH@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman  
>Rubin) writes:

			....................

>In the very moment you get hardware dependent you also lose portability. If
>you accept loss in portability, do it in assembler. If you need a portable
>assembler with elementary type-conversion and safe subroutine calls, symbolic
>names for variables and little overhead, use C. That's about as close to
>assembler (as hardware dependent) as you can get without resorting to assembler.
>I also can hardly imagine what a language would look like that had some special
>operators for e.g. "FP division by integer value with remainder saved" on one
>architecture but would compile and run on another one.
>Other than #define-ing some assembler macros for each machine and inlining the
>expansions.

We do not have full portability now, nor is it likely we ever will.  If 
word lengths change, or rounding changes, or whatever, portability is 
lost.  It is not necessary to lose all portability to get great improvement.

C is an atrocity as a portable assembler.  Too many of the instructions are
missing.  Such simple things as packing and unpacking, n x n -> 2n products
and the corresponding quotients, handling of overflows, bit operations,
and many others vary from non-existent to dead slow if you can do them.

This carries over to architecture.  Finding the next one in a bit stream
costs an arm and a leg in C, or even in machine language on most machines. 
Think of how much information must be considered; the number of bits left
in the current word being looked at, and of course what they are, the address
of the next word in the stream, and also that of the end of the stream.  Even
if all of these are in registers, it is not cheap, and we have 4 registers,
plus the output register, involved in this very simple operation, and we
have conditional code all down the line.

-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
From: storm@cs.mcgill.ca (Marc WANDSCHNEIDER)
Newsgroups: comp.arch
Subject: Re: 64 bit Alpha AXP -vs- 32 bit computers
Date: 20 Nov 92 19:23:40 GMT
Organization: SOCS - McGill University, Montreal, Canada

In article <Bxvwp3.87G@metaflow.com> rschnapp@metaflow.com (Russ Schnapp) writes:
>As I've heard the explanation, a primary motivation for 64 bits is to
>allow for _REALLY_ big virtual address spaces for processes that need
>to access oceans of data.  Really gonzo database applications might
>want to memory-map humongous database files.  A 64-bit address
>space ought to be able to satisfy that kind of requirement for the
>forseeable future (given the fogginess of MY crystal ball, the forseeable
>future can't be too far way, though  8-).

	There is probably a certain amount of added use to the mathematics
field.

	64bits allows integer values greater than 4 billion, a limit which
is easily reached when using exponential and factorial functions.

	The extra 32bits might allow an application to stave off the point
at which arbitrary precision arithmatic has to be added.


	ToodlepiP!
	Marc 'em.
-- 
  storm@cs.mcgill.ca           McGill University         "-- Attack ships on
  Marc Wandschneider           Montreal, CANADA             fire "
	Any opinions expressed are not mine, but those of the Demon Lord
      Yeegeheeegenogohugu who possessed me whilst I munched on Raisin Bran.
Newsgroups: comp.arch,comp.lang.misc
From: dseal@armltd.co.uk (David Seal)
Newsgroups: comp.arch
Subject: Re: What's RIGHT with stack machines
Date: 18 Nov 92 17:43:11 GMT
Distribution: comp
Organization: A.R.M. Ltd, Swaffham Bulbeck, Cambs, UK

In article <dak.721621337@messua> dak@messua.informatik.rwth-aachen.de
(David Kastrup) writes:

>See the MIPS processors (micro without interlocking pipeline stages) for
>a clever design idea: they have simply left out all instruction scheduling.
>If you start a command using a register which a previous command still has
>to fill up, there is no delay, but the OLD value is used.
>So the compiler/assembler will have to include nops by hand in order to
>prevent register clashes. On the other hand, command interlocking can be
>done by compilers. And you can use the die space thus gained for other
>purposes (bigger cashes, etc.). And because of the Harvard bus architecture,
>there is no difference between waiting for interlock or fetching a nop.
>Only problem: code tends to get longer.

Second problem: if a second implementation has different "natural" delays
for instructions to produce their results, then something is going to break.
Within limits, you can choose what it is - e.g. any of the following will
do:

  * The second implementation has to reintroduce the instruction scheduling
    hardware. It probably doesn't have to reintroduce *all* of it - e.g. if
    your original implementation had one load delay slot and your new one
    has two, you only have to protect one of them. But simply having
    instruction scheduling hardware at all is a large fraction of the
    complexity involved, so this may not save as much as you might have
    thought.

  * All code has to be recompiled for the new hardware. Unfortunately, not
    all vendors give you the sources...

  * You impose a rule on yourself that you simply won't use implementations
    that change the natural delays. Of course, this may well give
    less-than-optimal results in a few years' time.

Personally, I see this technique and others that expose implementation
details to the programmer as being rather short-sighted. They buy you a nice
short-term gain, at the cost of long-term problems. (Of course, if you're a
small company trying to get your architecture off the ground, you may *need*
the short term gains: if you don't get them, there won't *be* any long term
to worry about...)

David Seal
dseal@armltd.co.uk

All opinions are mine only...
Xref: sparky comp.arch:10812 comp.benchmarks:1709
From: jayl@bit.UUCP (Jay Lessert)
Newsgroups: comp.arch,comp.benchmarks
Subject: Re: Lisp performance (on Sparc SS2, SS10-30, HP720)
Date: 16 Nov 92 18:57:04 GMT
Article-I.D.: bit.489
Reply-To: jayl@bit.UUCP (Jay Lessert)
Organization: BIT Inc.,  Portland, OR USA

In article <Bxt992.BJB@pix.com> stripes@pix.com (Josh Osborne) writes:
>In article <1e824rINNlpu@iraul1.ira.uka.de> wolpers@i11s10.ira.uka.de (Andreas Wolpers) writes:
>>I can buy enough memory so that disk speed is no criterion.
>>Should I wait for machines with 8MB of cache? Should I shoot myself?
>
>How long can you wait?  Wait long enough and lisp machines will come
>back into style (half :-) ).

Hey, the Solbourne Series6 (Viking) CPU boards have 16MB of static third
level cache, no waiting necessary!  :-)

-- 
Jay Lessert  {decwrl,cse.ogi.edu,sun,verdix}!bit!jayl
Bipolar Integrated Technology, Inc.
503-629-5490  (fax)503-690-1498
Newsgroups: comp.arch,comp.lang.misc
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: Purdue University Statistics Department
Date: Wed, 18 Nov 1992 13:54:55 GMT

In article <id.HJ1V.BTG@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <BxtA6v.CE8@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>> But it is.  The operations often use register arguments and the results
>> are wanted in registers.

>What's a register? Most modern compilers ignore "register", or use it as a
>hint "this is a frequently used value".

Maybe that is one reason for such poor object code.  Most modern architectures
REQUIRE that arguments are in registers.  This should be well known; no matter
how well loads or stores can be integrated into the code, they certainly add
an instruction issue.

So, assuming that addition takes one cycle, a = b + c takes one cycle if
only registers are used, but four cycles otherwise.

Take one of the examples, unpack.  Since the registers typically do not 
behave in enough respects like memory, it is certainly difficult to put
a struct in the register file.  And even if it is, they might be in the
wrong registers.  So that unpack, as a macro, can often be done in 3 steps,
while any use of a struct for the result is likely to add at least 2 more,
and if memory is invoked, 4 more.

>And how is an inline library part of the language more than a subroutine
>or an include file?

An include file should be considered as part of the program.  The programmer
decides explicitly which ones to include.  By a subroutine, I normally mean
one compiled separately, and with object code linked at run time, or when
an object file is being produced, by the loader.  Inlining requires that
the compiler introduce instructions directly into the compilation as it
does when it is handling the user's code.  The current inlining is a special
case of what I would like to accomplish with the macro processor I have
called for; I would allow macros applied to macros, etc.  Inlining corresponds
to a subset of what a more powerful #define would handle.  But since it is not
under the control of the programmer, it becomes part of the language.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
Newsgroups: comp.arch
From: kaiser@mammal.vbo.dec.com (Peter Kaiser)
Subject: Re: PA-RISC ``semantic loading'' (according to DEC)
Reply-To: kaiser@uniriv.vbo.dec.com
Organization: DEC Technology Integration Group
Date: Thu, 19 Nov 1992 14:03:34 GMT


--
In article <32580142@hpcuhe.cup.hp.com>, campbelr@hpcuhe.cup.hp.com
(Bob Campbell) writes:

>>> I suspect
>>> that PA-RISC can get by with executing fewer instructions as well.
>> This is, in a nutshell, the CISC viewpoint.
>Some might call it engineering. 

Touchy? :-)

___Pete

kaiser@uniriv.vbo.dec.com
+33 92.95.62.97, FAX +33 92.95.52.00
Newsgroups: comp.arch
Subject: Re: More Alpha AXP Performance Numbers
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 17 Nov 92 14:28:46 GMT
Distribution: world
Organization: The Wolery

lindsay+@cs.cmu.edu (Donald Lindsay) writes:
> different *systems* by a single metric, such as $/SPECmark.  Heck,
> some of the potential customers may ask DEC to price it without the
> floating point units...

A lot of the potential customers for this box would do about one FLOP a
year just to check that it still works.... 8-)

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
Newsgroups: comp.arch,comp.lang.misc
From: bret@technix.mn.org (Bret Indrelee)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: Private System - Saint Paul, MN
Date: Thu, 19 Nov 1992 03:43:25 GMT

In article <id.HJ1V.BTG@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <BxtA6v.CE8@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>> But it is.  The operations often use register arguments and the results
>> are wanted in registers.
>
>What's a register? Most modern compilers ignore "register", or use it as a
>hint "this is a frequently used value".
>
>And how is an inline library part of the language more than a subroutine
>or an include file?

Which brings up a question I've wondered about.  Do any compilers use
'register' to indicate that a pointer reference DOESN'T access the
value?

If so, it once again becomes usefull to use the register keyword,
as a no-alias.  Compiler could optimize knowing that the value isn't
changed by that weird intervening pointer reference.

-Bret
-- 
------------------------------------------------------------------------------
Bret Indrelee               |         Insanity is all in the mind.
email: bret@technix.mn.org  |   
Newsgroups: comp.arch
From: renebi@idt.unit.no (Olaf Rene Birkeland)
Subject: Re: integer distance or sqrt
Reply-To: renebi@idt.unit.no
Organization: The Norwegian Institute of Technology
Date: Mon, 16 Nov 92 10:56:23 GMT

In article <CLIFFC.92Nov15184340@miranda.rice.edu>, cliffc@rice.edu (Cliff Click) writes:
|> bbs.dennis@tsoft.sf-bay.org (Dennis Yelle) writes:
|> > because of the interest in Herman Rubin's optimization problems
|> > some people here might be interested in this.
|> > It is a real problem.  That is, I have a program that spends quite a 
|> > lot of time here, and I would like to change this if I could.  
|> 
|> > I first considered asking for a integer sqrt, but maybe if the context is 
|> > known a better answer can be given.  This program is normally run on a 
|> > machine with no floating point hardware so I would like to get rid of 
|> > floats entirely.
|> 
|> I sent him an integer square root code using Newton's Method.  I've done 
|> this problem before and I'm sure there are better methods out there.  Does 
|> somebody want to post/email something better than Newton's?

I don't know the details of your algorithm, but wouldn't it be
possible to avoid sqrt's, i.e. do the substitutions

  sqrt(x^2 + y^2) < sqrt (z^2+t^2)    => (x^2+y^2) < (z^2+y^2)
  sqrt(x^2 + y^2) < d                 => (x^2+y^2) < d^2

and so on? This demands larger integers, but that might be needed
anyway for temporary calculations?

- Olaf Ren 
 
--------------------------------------------------------------
Olaf Ren Birkeland                 e-mail: renebi@idt.unit.no
The Norwegian Institute of Technology, University of Trondheim
--------------------------------------------------------------
From: rrm@ssdp.caltech.edu (Ron Marquardt)
Newsgroups: comp.arch
Subject: IBM Clock-tripled 486
Date: 16 Nov 92 21:18:45 GMT
Reply-To: rrm@ssdp.caltech.edu
Organization: California Institute of Technology
NNTP-Posting-Host: pluto.ssdp.caltech.edu

So, I understand that IBM announced a clock-tripled (33MHz/99MHz) version
of the 486 (a DX3?) at Comdex.  Can anyone in the know at IBM (or Intel)
comment further on this?  IBM supposedly designed this chip under their
existing licensing agreement with Intel.  If I understand that agreement
properly, IBM has 6 months to exclusively do their thing with it before
Intel can provide their own version to the masses.  Is that correct?
Also, what kind of incremental/marginal gain is there to clock tripling?
Does this chip have extra cache to compensate for the additional I/O burden?

Thanks.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Ron Marquardt                       E-mail: rrm@ssdp.caltech.edu
Solid State Device Physics Group            rrm@cco.caltech.edu
California Institute of Technology
Newsgroups: comp.arch
From: keiths@cae.wisc.edu (Keith Scidmore)
Subject: DEC Alpha architecture issues
Organization: College of Engineering, Univ. of Wisconsin--Madison
Date: 18 Nov 92 11:24:06 CST
Summary: conditional moves, PALcode, 1000 Teraflops=?
Keywords: alpha architecture

1. The DEC Alpha includes a conditional move instruction that they claim
   can be used to avoid using branches and the associated branch penalties.
   I'm trying to evaluate the usefulness of this feature.  Can someone tell
   me where I might find articles that discuss this or raw data that can be
   used to calculate the advantages of such an instruction.  I'm not into
   compilers, and I need to know what kinds of situations an optimizing
   compiler could make use of this instruction.  Is it even practical?  Are
   there any compiler writers out there with opinions on this?

2. The Alpha architecture also includes a feature they call PALcode that
   allows the chip to have a sort of rom-bios.  Why is it useful to have
   this feature?  Supposedly Operating systems can make use of this for
   the implementation of certain system calls.

3. Cray has annouced intention to build a 300 Teraflop machine based on the
   alpha.  What is the word for 1000 teraflops?
From: jfc@athena.mit.edu (John F Carr)
Newsgroups: comp.arch
Subject: Re: DEC Alpha architecture issues
Date: 22 Nov 92 16:57:52 GMT
Organization: Massachusetts Institute of Technology

In article <By0xy0.FsA.2@cs.cmu.edu>
	lindsay+@cs.cmu.edu (Donald Lindsay) writes:

>Also, PALcode can be entered from user state - you don't need to do a
>system call, with its heavy-duty state-change overheads.

A system call does not need to be slow.  On an RS/6000, a system call can be
as fast as 2 cycles.  If there is a slow instruction like a multiply or
divide executing the system call may overlap it and appear to take 0 cycles.

The current Alpha implementation takes more cycles than the RS/6000 to
switch modes, but that isn't an architectural issue: the 21064 pipeline is
longer.

--
    John Carr (jfc@athena.mit.edu)
Xref: sparky comp.arch:10765 comp.lang.misc:3705
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Date: 15 Nov 92 23:06:32 GMT
Followup-To: comp.arch
Organization: CWI, Amsterdam

In article <mwm.2n6z@contessa.palo-alto.ca.us> mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:
 > In <Bxq7y0.IJ@mentor.cc.purdue.edu>, hrubin@mentor.cc.purdue.edu (Herman Rubin) wrote:
 > > With instruction scheduling, one place for an optimizer would be in the
 > > ASSEMBLER, and even interaction between the programmer and the compiler/
 > > assembler.  I do not know of any such.
 > 
 > Herman, I've *never* seen you suggest something that hasn't been tried
 > already, in some form or another. This is no exception. It's been
 > tried. It didn't work very well.
 > 
Wrong.  The MIPS assembler performs some optimizations (like delay slot
filling and instruction scheduling).  It works quite well.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
Xref: sparky comp.arch:10860 comp.lang.misc:3755