HDTenEightyP/NetNews huggingface dataset:
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: 20 Nov 92 21:37:36 GMT
	<1992Nov19.105510.563@uklirb.informatik.uni-kl.de>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: kirchner@uklira.informatik.uni-kl.de's message of Thu, 19 Nov 1992 10:55:10 GMT

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

   From article <TMB.92Nov17223828@arolla.idiap.ch>, by tmb@arolla.idiap.ch (Thomas M. Breuel):
   > On the other hand, please do spare the rest of us
   > complex syntactic extensions ("!<>", "?)~", etc.) for all those
   > special purpose features.

   So Thomas wants us to write big numerical software in "assembler", or
   what else are these library calls ?

One of the main differences between assembler and high-level languages
is the ability to compose functions, or, in different words, not to
have to worry about where to store intermediate results. Whether a
language has infix operators or not is a trivial feature in
comparison.

In fact, there are assembly language with infix operators, while a lot
of numerical software has been written in languages (Lisp/Scheme)
without any infix operators. Writing numerical software in Lisp/Scheme
is certainly a whole lot more convenient than writing it in assembly
language or even FORTRAN or C (both of which do have infix syntax).

   The syntax extensions for rounding control are quite simple, a > or < behind
   the op, e.g. +>, -<, *< etc.

You are missing the point. In my experience, new operators make
program analysis and maintenance harder. A rarely used feature like
"x+>y" is much easier to read and recognized if written as
"add_rounding_down(x,y)" than as "+>" (in fact, what is "+>" actually
supposed to mean?). Another problem is that "+>" (whatever it may
mean) is not available on a lot of hardware, and
implementation-specific features should probably always go into
libraries.

I don't need per-instruction control over rounding mode frequently,
and I think that is true for most other users. Hence, I would oppose
the addition of special syntax for it to any language I'm using. You
are, of course, welcome to disagree.

   The problem is much more difficult with operations which give two results,
   like additions generating a carry. But these may really be hidden in
   some higher operations.

In my opinion, returning multiple values is a feature that is useful
enough to enough people to warrant better language support. Note that
in FORTRAN, this is altogether impossible, while in C, you can
"simulate" it using structures. SML and CommonLisp support it
directly.

				Thomas.
Xref: sparky comp.arch:10873 comp.lang.misc:3762
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.arch,comp.lang.misc
Subject: clean notation or speed: choose one
Date: 18 Nov 92 01:44:06 GMT

: From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
: Message-ID: <BxpnrA.Eqp@mentor.cc.purdue.edu>
: This is already clumsy, and difficult for a mathematician to read.  And it
: fails to use mathematical syntax; in use, simple syntax is more important
: than obscure semantics.  We prefer to write
:       x = y - z       rather than       sub3(x, y, z)

That's all very well, but when you start to want to say

              h = (o^2 + a^2)^.5

or even just

              x = y - c*z

then issues arise of register allocation, instruction scheduling, type
compabibility and/or conversions, peephole optimizations like
substituting a square root routine for the ^.5 operation, 
and so on and on.

NOW tell me... is "simple syntax" or "obscure semantics" more important
to  you?  The two are simply not compatible.  Ultimately, you MUST tell
the computer exactly what instructions to generate if you want to
squeeze the last gasp of performance.  And you simply *can't* hide
behind any simple notation when you do it, because that notation
*doesn't* *contain* *enough* *information* about what machine
operations you wish to generate.

On the other hand, I've seen assemblers that do use

              x = y - z

instead of

              sub3 x y z

And sure enough allowing infix operators and symbolic descriptions
of what each instruction does is a trivial thing to provide if you
want it.  But there's no escaping spelling out each instruction,
each register use, each "committed slot" allocation *by hand* if
you really want to squeeze the last drop of performance.

Herman's mixing of the goals of istream control and abstract notational
convenience means that he can never be satisfied with *any* solution to
his problem, because the problem has self-contradictory goals.
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
Newsgroups: comp.arch
From: dbg@slac.stanford.edu (David Gustavson)
Subject: Re: Hardware support for atomic operations ?
Followup-To: comp.arch
Organization: SLAC
Date: Sun, 22 Nov 1992 22:35:16 GMT

In article <1992Nov21.173146.7509@ncsu.edu>, odkahn@eos.ncsu.edu (OPHER
DANIEL KAHN) wrote:
> 
> I am interested in primitives that support mutual exclusion in hardware, such
> as the Test-And-Set and Swap instructions which are atomic.  I am especially
> interested in any such new primitives that may have been developed in the
> last few years.  If you know of any good references I would appreciate
> some e-mail!
> -- 
>  Opher D. Kahn 

The Scalable Coherent Interface project spent a lot of effort on this
subject, because it needed to find mutual exclusion primitives that work
well in a large distributed multiprocessor with rather arbitrary
interconnect. SCI (now IEEE Std 1596-1992) settled on Swap, Compare & Swap,
and Fetch & Add as its base set, with the operation being exported to the
addressed memory controller or device for atomic execution there, and the
result returned to the processor via the same interconnect. 

There is some overview of this in an article on SCI in Feb 92 IEEE Micro,
pp 10-22. This work also was supported by IEEE Std 1212-1991 Control and
Status Register (I/O) Architecture and some related work on standard DMA
(multiple processors feeding DMA work queues and multiple DMA engines
reporting status to a processor via completion queues (interrupt service
queues). 

A nice reference about the power of various locks is Herlihy, M. Wait-Free
Synchronization, ACM Transactions on Programming Languages and Systems 13,
1 (Jan. 91) 124149. 

Other references I recommend include Mellor-Crummey, J.M. & Scott, M.L.
"Algorithms for Scalable Synchronization on Shared-Memory Multiprocessors,"
ACM Transactions on Computer Systems 9, 1 (Feb '92) 21-65; and
Mellor-Crummey, J.M. & Scott, M.L. "Synchronization without Contention,"
ASPLOS-IV April 91 procedings.

--------------------------------------------------------------
-- David B. Gustavson, Computation Research Group, SLAC, POB 4349 MS 88,
    Stanford, CA 94309   tel (415)961-3539  fax (415)961-3530
-- What the world needs next is a Scalable Coherent Interface!
-- Any opinions expressed are mine and not necessarily those
   of the Stanford Linear Accelerator Center, the University, or the DOE.
From: bret@technix.mn.org (Bret Indrelee)
Newsgroups: comp.arch
Subject: Re: DEC Alpha architecture issues
Date: 21 Nov 92 19:43:11 GMT
Organization: Private System - Saint Paul, MN

In article <1992Nov20.183610.12796@crl.dec.com> payne@crl.dec.com (Andrew Payne) writes:
>DEC Cambridge Research Lab
[ Text deleted ]
>When the processor is running in PAL mode (as a result of executing a 
>call PAL opcode or taking an exception) the processor is fetching and
>executing instructions as usual, but:

[ First two points deleted ]

>3. Interrupts are disabled (so you can do atomic operations)


Hold it!  Disabling interrupts is not usually enough to guarentee that
an operation is atomic!

Either I am missing something, or PALcode has to do more in order to make
sure that the operation is atomic.


The Alpha machines included models with multiprocessors.  Disabling the
interrupts on one processor does not, by itself, prevent one of the other
processors from changing the memory location.

Even on single-processor machines, disabling interrupts is not enough.
The high-end machines can have Futurebus+ cards on them, such as an
intelligent graphics engine.  These devices can be accessing memory,
and should be able to do atomic transactions.  The processor (and
system memory bus) have to do more than just disable interrupts in
order to guarentee a truely atomic transaction!

-Bret


-- 
------------------------------------------------------------------------------
Bret Indrelee               |         Insanity is all in the mind.
email: bret@technix.mn.org  |
From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
Subject: Re: gotos in hardware
Organization: Purdue University Statistics Department
Date: Mon, 16 Nov 1992 01:17:03 GMT

In article <141549@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes:
>| From: hrubin@mentor.cc.purdue.edu (Herman Rubin)

>| A goto, with no intervening possible exits, should be handled in such a
>| way that that the hardware starts getting the code at the new location
>| early, so that there are no unnecessary delays.  It could even issue
>| instructions from that "new" code in the same way it does from current
>| code.  The "structured" approach, where unconditional transfers are not
>| the rule, prevents this type of optimization.

>  Just because you don't see many explicit "goto"'s in ``structured
>programs'' doesn't mean they aren't there.  They're usually hidden as
>``structured goto's'': e.g. "break" and "continue" in C.

I am quite aware of that.  But there are machines whose architecture
does not have separate fast transfers, but instead have them as part
of a conditional transfer instruction with no condition bits used.

My message was posted to comp.arch only; I raised no software questions.
-- 
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: ddean@sapphire.risc.uni-linz.ac.at (Drew Dean)
Subject: Re: Hardware Support for Numeric Algorithms
Keywords: Try again
Reply-To: ddean@risc.uni-linz.ac.at
Organization: UNI-LINZ
Date: Sun, 22 Nov 1992 22:23:05 GMT

In article <By2MH8.JFB@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu  
(Herman Rubin) writes:
> Working in a university environment does produce some problems, which
> those with reasonable manpower support do not seem to realize.  I can
> get gcc on some machines, but we do not yet have it on the one I am
> supposed to use for production.  Also, it cannot be used for program
> design for more than one machine, which is something I am supposed to
> be involved in.  This is a major reason for asking for a good macro
> translator, to isolate the dependent problems from the independent
> ones and still be able to communicate.  I cannot reasonably communicate
> SPARCstation program to someone using an RS/6000 or a CRAY Y-MP, but I
> can communicate the algorithm to a mathematician using any one of those
> machines in such a way that a language hacker could come up with good
> code in consultation.
> 
...
> 
> As far as I can tell, TXL is a very new product.  I will not be able to
> access it until our systems people decide it is safe enough to use.
> 
> --
> Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette  
IN47907-1399

Uh, last I checked gcc didn't need any privileged operations to install  
it.  (Does we don't have it for our production machine mean (a) we haven't  
gotten around to installing it, or (b) there's no port yet ?)  I rather  
doubt TXL needs any privileged operations to install, although I've never  
seen it.  (A macro processor that had to be installed set{u,g}id would be  
really scary.)  Thus, "our systems people haven't installed these tools,  
so I can't use them" is not a good reason not to use the tools.

WRT gcc, why can't the code be #ifdef'd for different architecture, with a  
slow but portable (and readable, so the intelligent user can write a fast  
version) version be the default ?

Last time I checked, the systems people were supposed to install what the  
users needed (at least for users doing some sort of "real work").  It  
certainly works that way here (tell me about it; I get to do the  
installing :-)).
--
Drew Dean
ddean@risc.uni-linz.ac.at
Not speaking for RISC, of course.
Newsgroups: comp.arch,comp.lang.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Xenix Support, FICC
Date: Wed, 18 Nov 1992 20:03:12 GMT

In article <Bxv2t2.4FH@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
> In article <id.6S0V.FKH@ferranti.com> peter@ferranti.com (peter da silva) writes:
> >So you're making the claim that computer language syntax was deliberately
> >introduced to obfuscate or conflict with another field? Is that really
> >what you mean here, or am I putting words in your mouth?

> I have given examples.  Some have even introduced conflicts with previous
> notation in the computer field.  A brief repetition of some of them is in
> order.

> 	The use of | for or. [...]
> 	The use of ^ for exclusive or. [...]
> 	The obfuscation created by using * for indirection, [...]
> 	Similarly for ++ and --.  Also, using & for "address of", [...]

And these were *deliberately introduced to conflict with standard notation*?

> But for a language designer with large backing
> not to check on this is in the nature of criminal negligeance, at least.

These were not introduced by a "language designer with large backing".

C was practically a bootleg project.

Personally, I think that making indirection a prefix operator was a bigger
mistake than any of these.
-- 
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?
Newsgroups: comp.arch
From: zstern@adobe.com (Zalman Stern)
Subject: Re: DEC Alpha architecture issues
Organization: Adobe Systems Incorporated
Date: Sat, 21 Nov 1992 01:16:53 GMT

In article <By0xy0.FsA.2@cs.cmu.edu>  writes:
> 
> woodacre@mips.com (Michael Woodacre) writes:
> 	[ in reference to PALcode ]
> >Can you explain how this is different from kernel code with interrupts
> >disabled on any other risc processor?
> 
> Think of it as a supervisor state. This state doesn't just have
> interrupts disabled:  it also has direct access to a large variety of
> implementation-specific internal registers. For example, TLB reloads
> are done by PALcode, whereas the "normal" code in the OS need only
> know architectural things (things that remain constant across
> implementations). 

This is effectively provided by the coprocessor 0 enable bit on a MIPS  
architecture machine. (Which is probably ignored in kernel mode but not  
supervisor mode or vice-versa (I can never remember which is which).) In any  
event, it is a reliability/robustness issue not a functionality issue. I can  
write my kernel to not use any of the protected features except in a small  
set of routines through an architected interface. (And in fact RISC/OS on  
MIPS platforms did this for many things because the coprocessor 0  
functionality is quite different on the various R-series implementations.)

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

This is an implementation issue. (And certainly if you spec a  lot of  
lightweight primitive operations via sys-or-PAL calls, you better make them  
fast.) The only significant difference between MIPS syscall and Alpha  
PALcall in terms of speed is that PALcall has many exception vectors where  
you need some dispatch code on the MIPS. (Anybody have cycle counts?) Even  
this is not an architectural issue. I could implement an Alpha processor  
with a single exception vector and I could implement a MIPS processor with  
16 million of them (or so). (And there's the 'ol RISC argument that the  
single vector might be faster. Supposedly Cray's only have one exception  
vector though...)

The point I'm trying to make is that DEC's "Privelleged Architecture  
Library" is probably a good abstraction but it doesn't require big changes  
in hardware. (Nor is it all that original.) Also, it has a certain amount of  
intellectual and logistical complexity. There's a layer between the OS  
writer and the hardware. You must understand the layer, and somebody must  
provide the code for the layer. If that interface is not a good match to  
your needs there's going to be a problem.
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson
Newsgroups: comp.arch
Subject: Re: What happened to the UCSD p-System?
From: rmk@rmkhome.UUCP (Rick Kelly)
Organization: The Man With Ten Cats
Date: Sun, 22 Nov 1992 07:31:24 GMT
Reply-To: rmk@rmkhome.UUCP (Rick Kelly)

In article <1992Nov21.055139.18590@foretune.co.jp> trebor@foretune.co.jp (Robert J Woodhead) writes:
>uesu03@giac1.oscs.montana.edu (Lou Glassy) writes:
>>Is any work going on in this area?  Or does performance pay
>>more than portability?
>
>The UCSD p-System had many advantages for its time.  Recall, back in
>those dark ages, machines were slow, memory was tight (64k was huge)
>and hard discs were non-existant.  Even floppies rarely had more than
>150k on them.
>
>So packing a decent OS that could run reasonable programs into such
>environments was tough.  The p-System attacked this problem in several
>ways:
>
>1) p-Code instructions were highly optimized both for space and ease
>of interpretation, which meant that the interpreters were small, and
>the p-Code programs themselves were smaller than equivalent machine
>code programs; so much so that usually OS+Interpreter+p-Code program
>was smaller than the native machine code program alone!
>
>2) That smaller size really helped when you consider the size and
>speed of the storage devices.
>
>3) p-Code was easy to compile for, which meant that the Pascal compiler
>was small (ie: it could actually run on a 64k machine!)
>
>4) It was portable, which meant that it was easy to support all the
>gazillion different machines out there.
>
>For it's time, the UCSD p-System was a great achievement, but like
>all things, its time has passed.  I myself used the Apple Pascal
>version to write Wizardry (14,000+ lines, originally done on a
>64k, 2-floppy machine; full compiles took an hour!).
>
>Wierd side story: When Wizardry was translated into Japanese, the
>Japanese company that did the work (and from whose premises I am
>writing this note) simply wrote p-System interpreters for all the
>target machines, and we made minor modifications to the Wizardry
>program to handle Japanese characters and syntax (the final version
>let you choose at boot time if you wanted to play in English, Kana
>or Kanji).  After we were done, we back-converted their interpreter
>to run either standalone or under MS-DOS; I wrote Wizardry IV on a
>NEC9801 MS-DOS machine that, after a suitable command line incantation,
>promptly said "Welcome to Apple Pascal!"
>
>(And yeah, I bought an extra copy of Apple Pascal for the NEC, too!)


When I read "4)" I almost hit 'F' to say that Wizardry I on the Apple II
was a great example of the efficiency of UCSD Pascal. :-)

Luckily, I read further before I put my foot in my mouth.

Along with all my other computers, I still have an Apple IIe here, and I
boot up Wizardry every now and then and remember back to the days of
excitement.

Wizardry on the Apple is/was very responsive considering the speed of the
floppy media.  It should probably be considered as a significant stepping
stone in the evolution of computer games.

-- 

Rick Kelly	rmk@rmkhome.UUCP	unixland!rmkhome!rmk	rmk@frog.UUCP
Newsgroups: comp.arch
From: hyatt@cis.uab.edu (Robert Hyatt)
Subject: Re: What happened to the UCSD p-System?
Organization: University of Alabama at Birmingham
Date: Wed, 18 Nov 1992 21:40:43 GMT

In article <1992Nov17.162428.15881@coe.montana.edu> 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?
>
>Thanks in advance,
>
>Lou.
>


Pascal used to do this via its famed "pcode".  The idea was to output an
intermediate code, then have an interpreter engine run on each different
architecture.  flexible, but slow.  We have been interested in this for
process migration on distributed systems.  The real difficulty is that 
we would like to be able to "stop" a process, move it, and re-start it.

Figuring out how to map the "real" machine state to the "psuedo-machine"
state is interesting since different machines have different sets of
registers, flags, etc.  and optimizing the instruction streams for
performance really begins to depend on these machine characteristics.
Imagine running a code for 1/2 hour on a Cray and then moving it to a
Sparc.  I know where to start, but the process is unbelievably messy
and difficult.
-- 
!Robert Hyatt                    Computer and Information Sciences   !
!hyatt@cis.uab.edu               University of Alabama at Birmingham !
Newsgroups: comp.arch
From: linder@ERC.MsState.Edu (Dan Linder)
Subject: Re: References on Decoupled architectures
Organization: /home3/linder/.organization
Date: Tue, 17 Nov 1992 15:55:35 GMT

In article <BxM3G4.6zz@dcs.ed.ac.uk> gxj@dcs.ed.ac.uk (Graham Jones) writes:

>   Can anybody recommend any articles/books/papers on decoupled architectures ?

A couple of references that I have seen are:

Smith, J. E., "Decoupled Access/Execute Computer Architectures," ACM Trans.
  on Comp. Systems, vol. 2, no. 4, Nov 1984, pp. 289-308.

Weiss, S., "Multiple-Port Memory Access in Decoupled Architecture
  Processors," 1991 Int. Conf. on Parallel Processing, pp. I-373-376.


Dan Linder
linder@erc.msstate.edu
Newsgroups: comp.arch
From: zstern@adobe.com (Zalman Stern)
Subject: Re: integer distance or sqrt
Organization: Adobe Systems Incorporated
Date: Sat, 21 Nov 1992 01:25:52 GMT

In article <6839@sungy.Germany.Sun.COM> ulrich@weissnics.Germany.Sun.COM  
(Ulrich Graef SUN Frankfurt TSE) writes:
[Describes methods of finding integer square root using 256 kilobyte  
tables.]
On state of the art hardware, the limiting factor in using table lookup for  
such algorithms is not memory usage, but cache miss penalties.
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson
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 19:59:15 GMT


[...regarding conditional moves on DEC's Alpha...]

For a reference on compilers, inlining conditional code, and GCC see:

"Eliminating Branches using a Superoptimizer and the GNU C Compiler" by
Granlund and Kenner in ACM SIGPLAN '92 pp. 341-352

The paper describes methods for inlining short conditional statements.  While
they give examples for the RS/6000, the techniques map nicely onto machines 
with conditional move instructions.

-- 
Andrew C. Payne
DEC Cambridge Research Lab
Newsgroups: comp.arch,comp.lang.misc