HDTenEightyP/NetNews huggingface dataset:
From: peter@ferranti.com (peter da silva)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: Xenix Support, FICC
Date: Tue, 17 Nov 1992 15:04:53 GMT

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?
-- 
Peter da Silva / 77487-5012 USA / +1 713 274 5180
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
From: pteich@cayman.amd.com (Paul Teich)
Newsgroups: comp.arch
Subject: Re: Registerless processor
Date: 22 Nov 92 04:08:40 GMT
Reply-To: pteich@cayman.amd.com (Paul Teich)
Organization: Advanced Micro Devices, Austin, TX

In article <1992Nov13.181654.11692@fcom.cc.utah.edu> (Darren R. Davis) writes:
| I have been pondering an idea for a machine architecture.  A processor
| that has no registers.  I am familiar with some architectures that have
| done this.  My twist on this theme is to have a very large cache on chip
| for memory locations (effectivelly becoming registers).

Quite recently AT&T has divulged details of its "Hobbit" microprocessor
(ATT92010) which indicate that it has neither general-purpose registers or
traditional instruction cache, but instead operates with only a stack cache
(and an instruction prefetch/decoded instruction pipeline/cache).

Can anyone shed any light on code development issues for the Hobbit, or on its
performance in executing compiled C code (as it is a direct decendent of the
CRISP archtecture)?
--
Paul R. Teich                          pteich@cayman.AMD.COM
Advanced Micro Devices, Inc.           Direct 1-512-462-4268
5900 E. Ben White Blvd., MS 561        WATS   1-800-538-8450 x54268
Austin, Texas  78741                   FAX    1-512-462-4756
===============================================================================
Religion loses its meaning as soon as it's explained.
Newsgroups: comp.arch
From: Nick_Janow@mindlink.bc.ca (Nick Janow)
Subject: THz Clock Lines
Organization: MIND LINK! - British Columbia, Canada
Date: Fri, 20 Nov 1992 06:35:29 GMT

arnold@clipper.ingr.com (Roger Arnold) writes:

>+ If that distance is small enough, it might be possible to do a "flash"
>+ conversion, with sensor elements in a linear optical path, each detecting
>+ whether there was a positive optical pulse within it at the time of a
>+ central clock pulse.
>
> About .2 mm, if it worked that way.  But it doesn't.  What you'd actually
> have would be 128 light frequency channels carried in one fiber, each
> channel modulated at 10 GHz.  Or 256 channels modulated at 5 GHz, or
> whatever works. Heavy duty frequency multiplexing, at any rate.  The
> receiving end has a corresponding number of tuned receivers, one per
> frequency channel.

That doesn't disqualify the "flash" conversion idea.  As the multi-frequency
optical signal enters a chip, it is split into channels via diffraction
grating or whatever.  Each channel converts one train of pulses into a
digital word. If you don't like long chips, yet need to stretch the pulses
out (by whatever means), you can wind the channels into spirals on the chip,
with little mirrors on the corners.  You can machine these optical channels
in two dimensions, or three (maybe stacked).

The point is, the optical pulses exist as physically serial information
measured from one single point in space...and as parallel information
measured from one single point in time.  The former requires a length of time
to acquire an entire word; the latter requires a length of space to acquire
an entire word.

Eventually, someone will develop the tools to make use of the parallel aspect
of optical signals in space to make fast optical>binary-word and
binary-word>optical interfaces.

--

Nick_Janow@mindlink.bc.ca
Newsgroups: comp.arch
From: firth@sei.cmu.edu (Robert Firth)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Software Engineering Institute
Date: Tue, 17 Nov 1992 20:36:33 GMT

In article <1992Nov17.191938.16161@newshost.lanl.gov> jlg@cochiti.lanl.gov (J. Giles) writes:

>I'm disappointed with Dr. Rubin.  He left out such obvious ones as:
>making a leading zero digit mean octal!  Or, the fact that `/*' is
>actually *ambiguous* in C because it's either a comment or a divide
>followed by a dereference...

Well, Mr Rubin only has 24 hours in his day, so don't expect him to
list all the problems!  What I'd like to add, though, is the comment
that, in most of the situations where C got it wrong, its predecessor,
BCPL, got it right...

>He didn't mention that the distinction between bit-wise and logical
>operators would not have been necessary if C had a LOGICAL data type.

... Including this one.  Yes, even a typeless language can make the
distinction, in a way that avoids surprise 99% of the time.
Newsgroups: comp.arch
From: awolfe@moo.Princeton.EDU (Andrew Wolfe)
Subject:  Question about SPARC FP traps
Originator: news@nimaster
Keywords: SPARC FP
Organization: Princeton University
Date: Wed, 18 Nov 1992 18:10:14 GMT


My students and I are confused about the way that traps are handled in SPARC implementations with multi-cycle, unpipelined FP operations.


Page 288 of Hennessy and Patterson reads:

----------------
A third technique in use is to allow the interrupts to become somewhat imprecise, but keep enough information so that trap-handling routines can create a precise sequence for the interrupt.  This means knowing what operations were in the pipeline and their PCs.  Then, after handling a trap, the software finishes any instructions that precede the latest instruction completed, and the sequence can restart.  Consider the following worst-case code sequence:


  Instruction-1 --- A long running instruction that eventually interrupts
                    execution

  Instruction-2,...,Instruction-(n-1) --- a series of instructions that are
                                          not completed

  Instruction-n --- an instructionthat is finished.

Given the PCs of all of the instructions in the pipeline and the interrupt return PC, the software can find the state of instruction-1 and instruction-n.  Since instruction-n has completed, we will want to restart execution at instruction-(n+1).  After handling the interrupt, the software must simulate the execution of instruction-1 ... instruction-(n-1).  Then we can return from the interrupt and restart at instruction n+1.
-------------------


I can't find anything in the SPARC arch. ref. that says anything different.  Here is our problem.  If you only save the instructions and PCs of uncompleted operations, then how do you get the input operands to re-execute them.  For example if instruction-2 requires r7, but instruction-n (that has completed) overwrites r7 then how can I restart instruction 2?

It would seem that a history buffer of some type containing register values is still required.

Is there anyone who has a more intimate understanding of this problem that can correct our interpretation of the facts or confirm that saving the PC's and instructions is not enough?



-- 
--------------------------------------
Andrew Wolfe
Assistant Professor
Department of Electrical Engineering
Princeton University
Xref: sparky comp.arch:11026 comp.lang.misc:3843
From: pcl@oxford.ac.uk (Paul Leyland)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Date: 23 Nov 92 14:07:11 GMT
	<mwm.2n6z@contessa.palo-alto.ca.us> <Bxr8vG.IpI@mentor.cc.purdue.edu>
	<martin.721995695@bert> <TMB.92Nov17181419@arolla.idiap.ch>
Organization: Oxford University Computing Service, 13 Banbury Rd, Oxford, OX2
	6NN
In-reply-to: tmb@arolla.idiap.ch's message of 17 Nov 92 18:14:19 GMT

In article <TMB.92Nov17181419@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M. Breuel) writes:



Lot's of stuff about double-length multiplies deleted, then:

   If anything, if you are going for efficiency, the C approach is more
   portable, saying that "int" is whatever is fastest and "long" gives
   you extra bits. "int" essentially used to mean "CPU register size" and
   "long" was largely intended to mean "probably twice CPU registers
   size, which coincidentally is what multiply may give you, unless
   that's too inconvenient". The only problem with this approach was
   that the early C compilers for 32bit machines messed up and didn't
   make "long" 64bits.


If only it was that simple.  Ten years ago, I was working part-time
for a company building a bit-slice mini.  It had a 32-bit alu and was
quite capable of performing 32x32=>64 and 64/32=>32,32.  I wrote the
great majority of the microcode, and played a significant part in
defining the architecture.  I also did a lot of multi-precision
integer work, and argued that longs should be 64-bits; partly for
elegance, partly for performance reasons.  I wrote the microcode to
support those instructions.

We then came to port an operating system (BSD 4.0 I think, though
itmay have been 4.1).

It was a real eye-opener to find out how many pieces of code *knew* a
long was 32 bits long.


Faced with the unsurmountable opportunities of changing hundreds of
kilolines of kernel and utilities, we chickened out.  It was bad
enough, fixing everything that knew address zero was readable and
contained zero; and others that knew stacks grew towards lower
addresses; and others that knew it was safe to calculate addresses
outside of arrays, so long as you didn't use them before calculating
another offset to bring them back in bounds, and ...

Still, I was able to have an instruction which returned the smallest
prime factor of a 64-bit unsigned integer operand on the stack, even
if I did have to load my own ucode and use an asm statement 8-)


Paul
--
Paul Leyland <pcl@oxford.ac.uk>          | Hanging on in quiet desperation is
Oxford University Computing Service      |     the English way.
13 Banbury Road, Oxford, OX2 6NN, UK     | The time is come, the song is over.
Tel: +44-865-273200  Fax: +44-865-273275 | Thought I'd something more to say.
Newsgroups: comp.arch
From: deraadt@newt.cuc.ab.ca (Theo de Raadt)
Subject: Alpha
Organization: little lizard city
Date: Sun, 22 Nov 1992 11:36:12 GMT

Has anyone compiled any statistics on the origin of postings in comp.arch
of late?

I'd be very interested to see how many postings have been coming from DEC.
 <tdr.
--

This space not left unintentionally unblank.		deraadt@newt.cuc.ab.ca
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Tue, 17 Nov 1992 09:03:05 GMT
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.arch,comp.lang.misc
Followup-to: comp.lang.misc

I've (tried to) direct followups away from comp.arch.

In article ... tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

   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.

It says ``This extension, however, would imply a significant extension of
complexity of syntax analysis and an uncertain gain in readability.'' It then
remarks that precedence and associativity must either be fixed for all
user-defined operators, or a mechanism must be present to define them; it is
this latter that is the tricky point. (The ``complexity of syntax analysis''
argument seems to be terribly weak, given that (a) Stroustrup is not stupid,
and (b) the rest of C++.)

There are many other things compilers cannot warn about reliably, or indeed, at
all; writing ``-'' when one meant ``+'', forgetting to increment a counter,
calling the wrong function (or not calling the right one), writing ``0'' when
style demands FALSE or NULL_String, and so on. Has anyone done some *research*
on the issue, rather than making *-informed speculation?

[My own speculation is that it's all perfectly sensible provided you're
prepared to forgo the ability to define your own precedence and associativity,
and that operator tokens are recognisable by spelling just as identifiers are.
What would be handy, I think, is a way of making *any* dyadic function into an
infix with a simple syntactic mark, eg, ``E1 @F E2''.]
--

Regards | "Always code as if the guy who ends up maintaining your code will be
Kers.   | a violent psychopath who knows where you live." - John F. Woods
Xref: sparky comp.arch:10919 comp.lang.misc:3791
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 11:44:49 GMT
Organization: University of Brighton, UK

bs@gauss.mitre.org (Robert D. Silverman) writes:
> 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 Run Time 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"
-------------------------------------------------------------------------------
Xref: sparky comp.arch:10839 comp.lang.misc:3742
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: 17 Nov 92 22:38:28
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
	<1992Nov17.112551.10920@uklirb.informatik.uni-kl.de>
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: kirchner@uklira.informatik.uni-kl.de's message of Tue, 17 Nov 1992 11:25:51 GMT

In article <1992Nov17.112551.10920@uklirb.informatik.uni-kl.de> kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner) writes:

   There are often VERY USEFULL things in the hardware, but now
   programming language supports them. This is mostly the case in the
   field of numerics, like
   - long integer product, as shown by Bob,
   - the carry, the major incredient to build a 'long' arithmetic
   - rounding control, needed to generate verified results ( not a mode bit! )

True, they are occasionally useful.

   What bothers me even more is the fact that modern processors are
   designed to support only things that can be used by HLL, mainly C,
   because statistics show no use of other features ( what else ), and
   so we find ourselves severley limited by a chicken and egg problem.

I suspect most people (including myself) are actually perfectly happy
with 32bit integers and 32bit/64bit floating point numbers with any
reasonable kind of rounding mode. The main limits that users are
coming up against are probably 32bit address limits (of course, if you
go to 64bit addresses, you need 64bit integers for indexing).

It is not very hard to provide access to such features from high-level
languages, through things that look and behave like library calls but
are actually recognized and inlined by the compiler ("sincos(a,s,c)",
"add_with_carry(result,arg1,arg2)", ...). If you are really interested
in this, I recommend that you work within NCEG (or other language
standards committees) to make proposals for what library primitives
might be useful. On the other hand, please do spare the rest of us
complex syntactic extensions ("!<>", "?)~", etc.) for all those
special purpose features.

					Thomas.

Newsgroups: comp.arch,comp.lang.misc
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Los Alamos National Laboratory
Date: Mon, 23 Nov 1992 18:32:04 GMT

In article <722228704@sheol.UUCP>, throopw@sheol.UUCP (Wayne Throop) writes:
|> [...]
|> But ultimately, when you are going after that last 1% or .1% of speed,
|> you will simply have to spell out the istream, operation by operation.

Unfortunately, the speedup from going to assembly is usually in the 
5% to 10% area.  And yes, there are people to whom such an increase
is worth a man-year or two of effor to achieve.  They'd rather spend
less effort if the CS community would provide better integrated tools
for optimizing, and there are people who cannot afford the effort
these kinds of optimizations require - but would benefit also if the
tools were improved.

|> [...]
|> No amounts of hints to the optimizer will ever be enough, because
|> ultimately the optimizer can only deal with hints it is prepared to
|> accept, and if a programmer comes up with something unforseen by the
|> optimizer, there's no simple way to give a hint about it.

True.  However it's possible to have the amount of explicit 
assembly kept to a minimum if the proper interfacing protocols 
are present.  For example, neither C nor Fortran (nor most other 
high-level languages) have a way for the user to get the leading 
zero count of the vector mask on a Cray.  I have algorithms which
need that computation and which are time-critical.  The nearest 
that the high-level languages can do is some clumsy loop.  All 
I really need are some intrinsics corresponding to the instructions 
which set the vector mask based on some array conditionals and an 
intrinsic which does a leading zero count instruction.  In fact, 
if  all the machine instructions were avalable as intrinsic functions
calls, then the compiler need only be able to do  adequate register 
allocation between these intrinsics (and also into the code generated 
from the higher level) and I could optimize any part of the code 
without paying procedure-call overhead.

-- 
J. Giles
From: doconnor@sedona.intel.com (Dennis O'Connor)
Newsgroups: comp.arch
Subject: Re: DEC Alpha architecture issues
Date: 20 Nov 92 09:52:51
Organization: Intel i960(tm) Architecture
NNTP-Posting-Host: potato.intel.com
In-reply-to: dipirro@star.dec.com's message of Thu, 19 Nov 1992 20:30:12 GMT


dipirro@star.dec.com (Steve DiPirro) writes:
] ... PALcode "instructions" actually appear as single instructions
]  in the Istream which is handy for debuggers, etc.  PALcode runs 
] with interrupts disabled, Istream memory management traps disabled,
]  and complete control over machine state. 

Sounds like a microcoded instruction to me. Except, of course, that
there's no guarantee of what PALcodes are available on a particular
system, and that the microcode may be external to the chip.

Humoursly : Sounds like an architectural wimp-out to me :-)

--
Dennis O'Connor			doconnor@sedona.intel.com
Newsgroups: comp.arch
From: kneuper@chpc.utexas.edu (Stephen Kneuper)
Subject: 64 bit Alpha AXP -vs- 32 bit computers
Organization: The University of Texas System CHPC
Date: Tue, 17 Nov 92 16:20:14 GMT

A debate is occuring at my site (and within my mind) regarding 64 bit
versus 32 bit computing.

I'm trying to figure out why I want to go to a 64 bit machine Alpha
AXP system instead of continuing to run 32 bit machines (RS6K, Sun).

Outside of the numerical analysis issues, the only other issues I see
are:

1.  64 bit ints allow the easy support of files larger than 2 Gbytes.

2.  64 bit ints allow the construction of filesystems larger than 2
Gbytes.

I do know some vendors (convex) have addressed these issues within a
32 bit architecture; Sun allows >2GB filesystems, if memory serves.
Have I missed any other obvious (or not!) programming or system
administration issues?

-- 
Steve Kneuper                                kneuper@chpc.utexas.edu - Internet
Sr. Operating Systems Specialist
University of Texas System (mailcode 78700)  kneuper@uthermes - BITNET
Center for High Performance Computing        (512)471-2472
Newsgroups: comp.arch,alt.folklore.computers
From: sgccseh@citec.oz.au (Steve Hocking)
Subject: Re: What happened to the UCSD p-System?
Organization: CITEC
Date: Tue, 24 Nov 1992 01:20:21 GMT


	Does anyone have the specs for the P-system and some code floating
about? Sounds like it would be fun to implement....


	Cheer,s

	Stephen
From: gml@hri.com (Gary Lasker)
Newsgroups: comp.arch
Subject: Need address/phone for Teradata and Fail-Safe Tech.
Date: 18 Nov 92 15:54:38 GMT
Reply-To: gml@hri.com
Distribution: usa
Organization: Horizon Research, Inc.


Could some kind soul please send me an address and/or phone number
for either or both of the following companies:

        Teradata
        Fail-Safe Tech.

Thanks!


--
  Gary M. Lasker                  gml@hri.com
  Horizon Research, Inc. 
  Waltham, MA  USA
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: DEC Alpha architecture issues
Date: 22 Nov 92 17:47:06 GMT
Article-I.D.: cs.By4pEI.8r5.2
Organization: School of Computer Science, Carnegie Mellon

andrew@megadata.mega.oz.au (Andrew McRae) writes:
>If it looks like microcode, smells like microcode ... Why call it PALcode?

Because it doesn't even vaguely resemble microcode.

- PALcode is fetched from the I-cache, not from ROM.
- PALcode is decoded by the normal decoder, as opposed to to microcode,
  which is often a raw mask over a processor's internal control lines.
- Microcode is usually in charge of detailed sequencing/timing of e.g. 
  register writebacks. PALcode has no concept of this, except for
  some implementation-specific rules like "if you set this TLB control
  register, then the TLB mode will change one clock later".
-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science
Newsgroups: comp.arch