HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.arch,comp.lang.misc
From: akao@.com (Adam Kao)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Oracle Corporation, Redwood Shores, CA
Date: Wed, 18 Nov 1992 00:58:57 GMT
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

In article <Bxv2t2.4FH@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

	[computer usage conflicting with mathematics]

>SOME of this may have been inadvertent, and due to the ignorance of those
>introducing the notation.  But for a language designer with large backing
>not to check on this is in the nature of criminal negligeance, at least.

Computer science is not mathematics.  Computer science is not the servant
of mathematics.  Computer science is related to mathematics only by
historical accident.

Feel free to design a computer language for mathematics.  Don't pretend
that other computer languages (least of all C) exist to serve you.

Adam

"Those French people have a different word for _everything_!!!"
Newsgroups: comp.arch
From: alan@sal.wisc.edu (Alan Watson)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: Space Astronomy Lab, Madison WI
Date: Sun, 15 Nov 1992 19:33:56 GMT

In article <7899@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
>But wait.  SPARC version 7 does not have an integer multiply instruction,
>it uses multiply step.  When you code the multiply in assembly you will
>find that you get a 64 bit result, but in C it is not possible to
>retrieve that result.  Doing it with inline assembly is not what you
>want in general (>32 instructions inline assembly), so you do it
>out-of-line.  Hence it is not sufficient to have good inliners, on
>some platforms you need out of line assembly routines to do what you
>want, and no, the compilers do not help.  (The same holds for HP-PA 1,
>IBM PC-RT, AMD 29k and a few more.)  So the operation is available but
>you do not get it.
>
>So let's see.  You promote the GCC interface with asm.  How do you
>code the 32x32->64 multiply on the SPARC in GCC?

Include the following in every source file:

	static inline long long mul32to64 (long i, long j)
	{
		whatever asm magic one requires
	}

This terribly inelegant; if you want elegance BUY a compiler for the
machine which has 64 bit longs and use:

	long i64;
	int i32, j32;
	i64 = (long) i32 * (long) j32;

If the compiler insists on promoting i32 and j32 to 64 bits before the
multiplication, ask for your money back.

Solutions exists for many of the specific problems which have been
discussed in this thread: most of the free ones are inelegant and most
of the elegant ones are expensive.
Xref: sparky comp.arch:10872 comp.lang.misc:3761
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.arch,comp.lang.misc
Subject: adding new operators on the fly
Date: 18 Nov 92 01:44:01 GMT

: From: bs@gauss.mitre.org (Robert D. Silverman)
: Message-ID: <1992Nov13.155126.3660@linus.mitre.org> 
: I would like to see a language that has a feature that will allow
: me to (say) define new operators that use specific machine instructions.
: for example: (pseudocode)
:
:       define binary operator arg1 ** arg2  as  'emul arg1 arg2'

This doesn't even begin to address all the necessary aspects of
defining a new operator.  What prescedence does "**" have?  What are
restrictions the compiler must know about which registers arg1 and arg2
must be loaded into?  What should the compiler do if there's a type
mismatch in the arguments (eg: you try to do this to floating point
numbers).  And so on and on and on.

These (among other reasons) are why gcc encourages access to assembly
instructions with functional notation.  You can at least specify input
and output types, and you don't have to worry about operator
prescedence issues, or lexical or syntactic ambiguity after the
introduction of the new operator.

There *are* languages that allow introduction of operators, but they
sidestep a lot of the issues by not defining the operators in terms of
machine instructions, but of other language constructs, and sidestep
others by including notation for type compatibility and operator
prescedence, and so on and on.

Code generation just isn't as simple as associating a concrete instruction
with an abstract operation, and syntactic recognition isn't as simple as
spelling all the operators.  The above notation doesn't even *begin*
to be adequate to the task it is allegedly intended for.


( Now granted: the example was "pseudocode".  But nevertheless, the
  example gives no clue how this pseudocode can even potentially be
  elaborated into a practical notation. )
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
Newsgroups: comp.arch
From: payne@crl.dec.com (Andrew Payne)
Subject: Re: DEC Alpha architecture issues
Organization: DEC Cambridge Research Lab
Date: Thu, 19 Nov 1992 20:47:29 GMT

In article <lgnojjINN627@exodus.Eng.Sun.COM> tremblay@flayout.Eng.Sun.COM (Marc Tremblay) writes:

[ ... deleted ...]

>>   Any conditional branch over
>>   a short sequence of instructions was optimised into a short
>>   sequence of conditionally-executed instructions, which reduced
>>   the code size and saved flushing the pipeline (there was no smart
>>   branch prediction or delayed branches).
>
>The last sentence is key here. If branches can be predicted with decent
>accuracy then it is hard to obtain benefits from conditional moves
>over using conditional branches. 

Do you have any data to back up this claim?

Don't forget that conditional move sequences can be shorter than the 
corresponding branch sequence.  In other words, the two instruction
sequence branch/op can sometimes be replaced with a single conditional move 
instruction.

Second, I believe the second order effect of providing larger basic blocks
is the conditional move's greatest benefit.  Larger basic blocks offer
more scheduling opportunities.  I don't have any data (yet), but I've 
certainly seen it happen.

-- 
Andrew C. Payne
DEC Cambridge Research Lab
From: tremblay@flayout.Eng.Sun.COM (Marc Tremblay)
Newsgroups: comp.arch
Subject: Re: DEC Alpha architecture issues
Date: 23 Nov 1992 17:52:26 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: flayout

In article <1992Nov23.122727.12708@odin.diku.dk> torbenm@diku.dk (Torben AEgidius Mogensen) writes:
>If you can predict conditional branches, surely you can predict
>conditional moves and other conditional instructions as well, even
>using much the same techniques. In general any technique that can be
>used to optimize conditional branches can also be used to optimize
>other conditional instructions, so I can't see that using conditional
>instructions in general can ever be worse than using conditional
>branches only. One can then discuss how to reduce the penalty of
>having conditions only on branches.

Let me try to explain one more time what needs to be considered when
conditional moves and conditional branches are evaluated.

Conditional moves allow the program counter to progress sequentially.
Since the flow of instructions is unconditional (only the register file
update and the bypasses attached to the conditional move are conditional),
no repair is needed to correct the flow of instructions.
Usually conditional moves are used to eliminate conditional branches
that jump over a small piece of code. That is usually done by executing
*both* pieces of code (the part associated with the taken branch and the
one associated with the non-taken branch) simultaneously. By simultaneously
I mean in the same basic block (could be simultaneously in time on a 
superscalar processor).

That works well if the number of instructions that are "guarded" is small,
since you may need to set up only one register, do a compare, and do a
single conditional move. If the number of instructions to guard is large,
then several instructions are needed to do the set up, several compares
may be needed (unless all instructions can be based on the original compare)
and several conditional moves are required. One can generalize and say
that in the "conditional move mode", twice as many instructions are needed,
reducing the throughput by one half. Clever tricks can be used, for example
using logical operations to merge both streams into one stream, but that
usually works only for small pieces of code. The throughput is not
reduced by one half for these, but it would certainly be degraded
significantly.

If conditional branches can be predicted accurately, then the break in the
flow of instructions can be hidden through a smart pre-fetcher (no magic here).
After the branch is executed, 100% of the hardware can be dedicated to
execute the correct path (versus ~50% for conditional moves). With a
smart processor front-end it would seem that it is always better to
use conditional branches, except that the prediction is not always correct
and a penalty of a few cycles is associated with the misprediction.
That is why the accuracy of the prediction and the efficiency of the
prefetcher is important when evaluating conditional moves vs.
conditional branches.

- Marc Tremblay.
Sun Microsystems.
Newsgroups: comp.arch
From: renglish@cello.hpl.hp.com (Bob English)
Subject: Re: PA-RISC ``semantic loading'' (according to DEC)
Date: Mon, 23 Nov 1992 17:53:21 GMT
Organization: Hewlett Packard Labs

thorinn@diku.dk (Lars Henrik Mathiesen) writes:
:   0) The programmer model contains a processor status register, with
:      rapidly changing contents; it is only visible on interrupts, and
:      with a special instruction, but it still has to be synchronized.

The PSW is not visible except as a value that can be restored after an
interrupt.  An interrupt causes the pipeline to drain, so there are a
few cycles available during which the value can synchronize.

:   1) ``Skip-on-condition'' sets a nullification bit in this PSR;
:      nullification depends on the ALU results of one instruction, and
:      prevents all programmer-visible effects of the next --- including
:      data cache move-in, as far as I can see.

At the worst, this would mean that instructions that can nullify the
following instruction would have to run more slowly, and that
nullification would be less useful, but I don't think the situation is
that bad.  The data cache move-in problem you describe, for example,
isn't really any worse than a sequence of two instructions where the
first generates an address and the second uses it to load a word of
data.

:   2) The instructions that support multiprecision and BCD arithmetic
:      have carry bits in the status register as implicit arguments.

This is a problem, but only because the status register acts as an data
bottleneck, limiting the number of multiprecision operations that can be
performed in parallel.  This is the real problem with the nullification
operations, by the way.

:   3) Changes to the virtual memory mapping of the instruction stream
:      are guaranteed to take effect within 8 instructions.

This is only relevant to operations which affect the virtual memory
mappings, so that the OS can predict when translations will be valid.
Without some such guarantee, the OS would not know when to return to
virtual mode.  Since the effects are limited primarily to the TLB miss
path--code which gets optimized to particular processors, anyway--this
aspect of the architecture would be easy to modify should it pose a
problem.

--bob--
Not an HP spokesperson, but still an HP employee.
From: endecotp@cs.man.ac.uk (PB Endecott (PhD SFurber))
Newsgroups: comp.arch
Subject: Re: why no register + register addressing mode in R3000 (repost)
Date: 13 Nov 92 17:26:59 GMT

tremblay@flayout.Eng.Sun.COM (Marc Tremblay) writes:


>Here is the percentage of loads and stores for SPECint92 benchmarks
>running on SPARC which use the two register addressing mode [RX + RY]:

>benchmark	loads	stores
>---------	-----	------
>espresso	37%	9.8%
>li		2.5%	2.8%
>eqntott	76.4%	5.4%
>compress	27%	7.3%
>sc		13.5%	7.9%
>gcc		18.9%	37.5%

Interesting numbers, thank you.

I calculate from this that an average of 11.8% of stores and 29.2% of loads
use a two-register addressing mode.

Using numbers from Hennessey & Patterson fig 4.34 (sorry I don't have them
for the SPEC benchmarks), 8% of instructions in dynamic execution are
stores, and 18% are loads.  So, (8% x 11.8%) = 0.9% of instructions are
stores that use two registers, and (18% x 29.2%) = 5.3% of instructions are
loads that use two registers; a total of 6.2% of instructions use
two-register addressing modes.

On an architecture without this mode, assuming that each of these
operations would need a separate ADD to calculate the address, the number
of instructions needed to do the same work would increase by 6.2%.  Does a
6.2% performance increase justify an extra register read port ?

The answer depends on the actual cost of adding the read port, and other
factors such as the impact on code density of the extra code.

Question : does the Sparc do both sorts of addressing in the same number of
cycles, or does it use an extra cycle for reading the extra register ?

The 6.2% is a maximum; clever compiler techniques should reduce this.
 
Consider a processor which implements register+register for loads (where
the extra port is available) but not for stores, where the port is needed
for the data.  I believe that the HP-PA does this.  From the above numbers,
0.9% of instructions need an extra ADD for address calculations compared to
a machine with register+register for loads and stores.  Is this a good
compromise ?

In a superscalar implementation, you have lots of register ports.  For
example, you may have four read ports so that you can do two ALU operations
simultaneously.  You could then do a store with two registers for the
address at the same time as a monadic ALU operation!

--Phil.
Xref: sparky comp.arch:10959 comp.lang.misc:3813
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Date: 16 Nov 92 20:36:10
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
	<TMB.92Nov16140138@arolla.idiap.ch> <BxtFoF.BGn@mentor.cc.purdue.edu>
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: hrubin@pop.stat.purdue.edu's message of Mon, 16 Nov 1992 15:43:26 GMT

In article <BxtFoF.BGn@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

   > * Programming languages themselves nowadays only let you specify very
   >   limited syntactic extensions, because such extensions are difficult
   >   to scope properly (mind you, the computer and the parser have no
   >   problem with this, it is the humans that can't deal with it).  This
   >   isn't the result of some kind of "language fascism", but of market
   >   forces: languages that have allowed more general syntactic
   >   extensions simply never caught on, presumably because such
   >   extensions were causing more hassle than they were worth.

   I am not at all convinced that this is the case.  I doubt that they were
   left out of C++ because humans could have problems with them; if that is
   the case, a warning should be sufficient.

The problem is that user-defined operators cause problems about which
the compiler cannot warn reliably. For the rationale and some examples
of what can go wrong, see the ARM, p331.

					Thomas.
Newsgroups: comp.arch,comp.lang.misc
From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Purdue University Statistics Department
Date: Sat, 21 Nov 1992 14:08:31 GMT

In article <1992Nov20.054603.28338@technix.mn.org> bret@technix.mn.org (Bret Indrelee) writes:
>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.

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

>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.

The two aspects I have been arguing are the notation to communicate,
and the speed of the object code.  This is also what those using the
computers in number theory are arguing.  The physicist does not attempt
to use notation known to confuse the chemist or electrical engineer.
The numerical analyst does not tell the engineer to state it in a new
"clean" format or go without the services.  When I consult on statistical
problems, the problem is not statistical notation, but that the client
does not know that more SUBJECT MATTER assumptions are needed to solve
the problem, and that the numerical answers depend on those assumptions
in a non-trivial manner.  Also, often there is a partial analysis, with
further work needed on steps, even on the decision of what data to collect.

It is precisely this approach which the programming people seem unwilling
to take.  I do not attempt to force the solution method into a small
algorithmic framework, and often invent algorithms for the particular
problem.
-- 
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: stripes@pix.com (Josh Osborne)
Subject: Re: IBM Clock-tripled 486
Organization: Pix Technologies -- The company with no adult supervision
Date: Wed, 18 Nov 1992 03:24:56 GMT

In article <1e937lINNq50@gap.caltech.edu> rrm@ssdp.caltech.edu writes:
>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.

The only 486 CPU that I know of that IBM announced is a 486SXL, which is
a clock dubled 486 in a 386SX pinout (for the portable market).  Even
with it's extra large cache it seems a tad bit silly to me (the clock).

>                                          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?

I don't know, but if it is it would give IBM a price advantage even after
the first 6months...  (on their PCs)

>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?

I would assume they have at least as much cache as their 486SXL, but I
don't know.  Even if it has NO extra cache the tripled clock would help
a great deal on floating point ops.  How much more on-chip cache would
it need to signifagntly effect the integer speed (assuming most of the
int instructions are the one cycle kind...)?  And if IBM can make
a 486 run at 99Mhz what could they have done with a SPARC/MIPS/generic
RISC CPU?
-- 
           stripes@pix.com              "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.       - Larry Wall
Xref: sparky comp.arch:10949 comp.lang.misc:3804
From: mwm@contessa.palo-alto.ca.us (Mike Meyer)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Newsgroups: comp.arch,comp.lang.misc
Distribution: world
X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52
Keywords: 
Summary: 
Date: 15 Nov 92 16:06:09 PST
Organization: Missionaria Phonibalonica

In <1992Nov15.193847.8390@udel.edu>, carroll@balin.cis.udel.edu (Mark C. Carroll) wrote:
> Herman, you're a liar.
> 
> On at least three occasions, I have answered this ridiculous thread of
> yours with a recommendation that you take a look at TXL. TXL will do
> exactly what you want from a macro processor.

Nuts, Herman once named such a processor in private mail to me. It was
incomprehensible and had no documentation, but he seemed to like it.

From what he's said, you don't need anything particularly powerfull.
Any good template macro processor ought to be able to do what he
wants. MORTRAN spring to mind, and it's 15 or 20 years old.

	<mike
From: richardw@hub.parallan.com (Richard Walter)
Newsgroups: comp.arch
Subject: Re: What happened to the UCSD p-System?
Date: Thu, 19 Nov 92 18:14:42 PST
Organization: Parallan Computer, Mountain View CA

uesu03@giac1.oscs.montana.edu (Lou Glassy) writes:

> Is the idea of running code on virtual machines dead?
> Found a couple of old books yesterday on the p-System and 
> MINT.  
> 
> The possibility of taking my binary from machine to machine,
> (with possibly different physical architectures), and having
> it run without dinking, is an intriguing one.
> 
> Is any work going on in this area?  Or does performance pay
> more than portability?
> 
Firstly, there is a commercial package called "Soft-PC" which runs on
Macintoshes and emulates a PC.  Also, isn't this one of the basic
ideas of Windows NT?  Since NT is supposed to be platform independent,
if you are running on an Alpha and then start-up an application compiled
for the Intel x86 family, won't NT really startup an x86 emulator and
run the application inside of that?

I guess that these aren't really p-code systems.  But then again, if
you run the same p-code on all platforms, then all systems will suffer
a performance hit, while if you compile it for one system and run under
emulators on all others, then at least the one system running native
code will have good performance while the others take the hit.

Also, I read recently (within the last 6 months) in some trade journal
(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 go being vague again...:)).

-Richard Walter
richardw@parallan.com
Xref: sparky comp.arch:10921 comp.lang.misc:3794
From: je@unix.brighton.ac.uk (John English)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Date: 19 Nov 92 12:27:54 GMT
Organization: University of Brighton, UK

In <1992Nov13.155126.3660@linus.mitre.org>, by bs@gauss.mitre.org (Robert D. Silverman):
> Herman is bemoaning the fact that quite often a computer HAS hardware
> to execute some particular instruction that he likes, but that HLL's
> do not allow him access to it.

One of my favourite quotes (from the VAX/VMS Runtime Library manual):
	"The VAX instruction set was designed for efficient use by
	 high level languages and therefore contains many functions
	 which are directly useful in your programs.  However, many
	 of these functions cannot be used directly by high level
	 languages..."
Says it all, really.
-- 
-------------------------------------------------------------------------------
John English			| "Yes, understanding today's complex world of
Dept. of Computing		|  the future IS a little like having bees live
University of Brighton		|  in your head... but, there they are..."
Janet: je @ unix.brighton.ac.uk	| "People who live in windowed environments
Fax:   0273 642405		|  shouldn't cast pointers"
-------------------------------------------------------------------------------
Newsgroups: comp.arch