HDTenEightyP/NetNews huggingface dataset:
From: vulture@imperial.ac.uk (Thomas Sippel - Dau)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Reply-To: cmaae47@imperial.ac.uk
Organization: Imperial College of Science, Technology and Medicine
Date: Tue, 22 Dec 92 13:58:02 GMT

In article <BzIxqo.C90@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill Hallam-Baker) writes:
 
- But it is the paucity of software that prevents anything more novel than
- floating point accelerators for standard Von Neumann machines gaining wide
- acceptance.
- 
- If you want to discuss hardware, you cannot ignore the software aspect.
....

And unfortunately that goes very deep and does certainly not stop at the
operating system. Once you deart from a von-Neuman architecture, many
respected truths are no longer applicable. Take the well-known suggestion
that a binary chop is the fastest way to serch an ordered list. If you have
two processors (and a few more performance parameters ...) you will find
the fastest search splits the population at the 62/38 % rather than at 50/50.

Once you design hardware that requires people to redefine and rethink 
their problems before they can use of it you have some selling to do.

                                       Thomas

-- 
*** This is the operative statement, all previous statements are inoperative.
*   email: cmaae47 @ ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic on Janet)
*   voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
*   snail: Imperial College of Science, Technology and Medicine
*   The Center for Computing Services, Kensington SW7 2BX, Great Britain
Newsgroups: comp.arch
From: bmtong@cs.cuhk.hk (Tong Bo-Ming)
Subject: No Last Call Optimization on Sparc and DECstation
Organization: Faculty of Engineering, The Chinese U. of Hong Kong
Date: Wed, 30 Dec 1992 09:43:52 GMT

In the field of Logic Programming, we have a kind of optimization
technique called the Last Call Optimization.  The idea is simple.

	p(a,b,c)
	{	x(a);
		y(b);
		z(c);
	}

In the above procedure, we may discard the current stack frame (or reg
window in Sparc) before calling z.  We then replace the call z
instruction by a jump instruction.

	p(a)
	{	x(a);
	}

In the above kind of procedure where there is only one call, no stack
frame is necessary.  It can be optimized as if it were a leaf procedure.

It is a sad thing to notice that such a nice optimization is not
implemented in languages other than Prolog and on RISC architectures.

				Tong Bo-Ming
				Department of Computer Science
				The Chinese University of Hong Kong
From: akao@.com (Adam Kao)
Newsgroups: comp.arch
Subject: Re: big + little endian (was: Comparison of Alpha, MIPS ..)
Date: 30 Dec 92 19:37:52 GMT
Organization: Oracle Corporation, Redwood Shores, CA
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 <1hquujINNmov@fido.asd.sgi.com> pj@sgi.com writes:
>In article <28164@dog.ee.lbl.gov>, torek@horse.ee.lbl.gov (Chris Torek) writes:
>|> 01101001 may mean `105' (big-endian) or `150' (little-endian)
>
>Big and little endian refer to the order of bytes within words,
>not to the order of bits within bytes.

You're teaching grandmother how to suck eggs ...


Adam
Organization: Ministry of Education, Computer Center NETNEWS system V2.3
Date: Tuesday, 29 Dec 1992 16:05:04 EST
From: <TKUS135@TWNMOE10.BITNET>
Newsgroups: comp.arch
Subject: Asking for paper/textbook concerning instruction-set parallelism

Greetings:

I'm looking for any papers, documents or textbooks which are concerning
about the insturction-set layer parallelism. As far as I know, there
are many parallelisms can be pursued in the computing systems:

        . algorithm layer
        . environment layer
        . language and compiler layer
        . OS and library layer
        . instruction-set layer
        . hardware layer

It's my impression that most of current parallel system implementations
are mainly focused on hardware layer. I wonder whether instruction-set
layer parallelism is worth to explore. Current CISC/RISC processors
seem don't consider implementing any instructions which support the
concurrent execution (except floating-point operations). Although
some processors (such as Inmos's Transputer series) also include
the inter-processor communication instructions, I doubt this is the
only way to obtain the instrcution level parallelism.

The vector processors are good enough for array operations but are
criticized for most of the general-purpose programs are hard (if not
impossible) to transform into vector forms. So you can find that
additional vector processors are attached in TMC's CM-5 nodes.

MIT's dataflow machines seems be the only one computation model that can
support instruction level parallelism. Other High-Level-Language (HLL)
machines might be the another candidate, I'm not sure.

Superpipeline and superscalar, however, are not my interesting.

Please forward your direction to me.

Thanks,

Yin-Chih Lin    lycmit@x1sun6.ccl.itri.org.tw

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Yin-Chih Lin                   Industrial Technology Research Institute (ITRI)
Design Eng.                    Computer & Communication Research Labs.  (CCL)
lycmit@x1sun6.ccl.itri.org.tw  Microcomputer System Department X100
Tel: 886-35-917331             14 Bldg, 195 Chung Hsing Rd., Section 4
Fax: 886-35-917503             Chutung, Hsinchu 31015
                               Taiwan, R.O.C.
Newsgroups: comp.arch
From: hyatt@cis.uab.edu (Robert Hyatt)
Subject: Re: UNIX fseek time (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
Organization: University of Alabama at Birmingham
Date: Thu, 24 Dec 1992 15:15:00 GMT

In article <1992Dec24.112422.12434@titan.inmos.co.uk> conor@lion.inmos.co.uk (Conor O'Neill) writes:
>>
>>That's an interesting point.  I am not an expert in Unix file access
>>but I'd guess that Unix has standardized on both sequential
>>and flat direct-access files, and that sequential access is just a
>>special case of direct access: read so many bytes sequentially from
>>a randomly-accessible point in a file.  Or, it has standardized on
>>sequential file access, and that direct access is a special case, using
>>the fseek() library call.
>
>But, given that 'fseek' is incredibly slow on most Unix systems,
>one could almost assume that Unix doesn't support random-access files.
>

If you look at how unix maintains a file's data blocks, you will see that
it is based on random I/O.  There are direct pointers to the first ten
blocks of a file, a pointer to a block of pointers for the next "n" blocks
of the file (N depends on the blocksize/wordsize of the machine), a pointer
to a block of pointers which points to blocks of pointers for the next
n*n blocks of the file, etc.  In essence, everything is offset from the
first byte of the file and there are no "links" or whatever within a
block for sequential access.  To access a file sequentially, you simply
increment through the pointers sequentially.

As to it being slow, I haven't noticed it being any slower than most any
system call.... there IS a lot of work to cross the kernel boundary and
then get back.  fseek() doens't do much work, just computes where the
next block is.  If it is not pretty close to the last block (excepting
the first 10 blocks of the file) it might have to do I/O to read in the
"indirect" pointer blocks.  However, just like any system, random access
has it's penalty.

-- 
!Robert Hyatt                    Computer and Information Sciences   !
!hyatt@cis.uab.edu               University of Alabama at Birmingham !
Newsgroups: comp.arch
From: kdlin@advtech.uswest.com (David Lin)
Subject: Internet Multimedia Archive Info Wanted
Organization: U S WEST Advanced Technologies
Date: Tue, 29 Dec 1992 17:34:00 GMT

Happy holidays.

I'm doing a preliminary survey on the archive sites of Internet/USENET. 
I'll really appreciate it if anyone can point me to where those sites
are located. Basically, I'm looking for multimedia resources archives
such as images, quicktime movies, sounds, text, MPEG, JPEG, DVI movies,
etc. Any multimedia related items will work too.

Please send e-mail to me at: kdlin@advtech.uswest.com.

Thanks in advance.

David

-- 
 K. David Lin, Ph.D.              | IEEE Member, NRA Member, HAM Operator
 Communication Services Research  | U S WEST Life Safety Team
 U S WEST Advanced Technologies   | Defend your life in STEREO - Beretta & SIG 
 E-mail: kdlin@advtech.uswest.com | Disclaimer: Only personal opinions
Newsgroups: comp.arch
From: raymondc@microsoft.com (Raymond Chen)
Subject: Re: No Last Call Optimization on Sparc and DECstation
Date: 02 Jan 93 22:21:31 GMT
Organization: None.  That way I don't have to write a disclaimer.

In article <1992Dec30.094352.4243@cucs5.cs.cuhk.hk> bmtong@cs.cuhk.hk (Tong Bo-Ming) writes:
>	p(a,b,c) { x(a); y(b); z(c); }
>
>In the above procedure, we may discard the current stack frame (or reg
>window in Sparc) before calling z.  We then replace the call z
>instruction by a jump instruction.
>
>It is a sad thing to notice that such a nice optimization is not
>implemented in languages other than Prolog and on RISC architectures.

As has been noted, LISP-like languages are major consumers of tail
recursion technology.

In article <1993Jan2.144518.20826@walter.bellcore.com> mo@gizmo.bellcore.com (Michael O'Dell) writes:
: There are a number of challenges to exploiting the technique 
: in C compilers (having to do with exception handling, setjmp/longjmp,
: etc).

I figure stack management is the toughest part.  the "caller cleans the
stack" calling convention used by many compilers (to make variadic
functions easier) makes it impossible to optimize the last call in a
function like

	f(a) { return g(a, 2); }

because f's caller will clean only one word from the stack, whereas
g will leave two words of garbage on the stack when it exits.

And pointers really make things confusing.  If you gave anybody a pointer
to a local variable, you cannot optimize the last call.  Consider,
for example,

	f(a) { int b; g(&b); return h(a); }

You can't clean f's stack frame before calling h(), because g() and h()
might've been written like this:

	int *scary;
	g(p) int *p; { scary = p; *scary = 2; }
	h(a) { return *scary + a; }

We learn once again that the tremendous flexibility of C's pointers
proves an obstacle to optimization.  (As if we didn't know this already.)
--
Raymond (not a compiler writer) Chen
Newsgroups: comp.arch
From: skwong@cuse1.se.cuhk.hk (Wong Sai Kee (Graduate Assistant))
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Organization: Faculty of Engineering, The Chinese U. of Hong Kong
Date: Tue, 22 Dec 1992 06:52:37 GMT

dfox@quack.sac.ca.us (David Fox) writes:

>>|>> So far, the most "open" system I can think of is a 386 running DOS:
>>|>> - systems available from all sorts of people
>>|>> - CPU's available from (at least) AMD, Intel, IBM, and Cyrix

>I don't agree.  For a system to be open requires it not to be
>proprietary.  Of course, 386s running DOS are a lot more 'open' than 
>Macintoshes, for example.  But Unix (or at least _some_ unixes) foster

Have you program Mac before?  I think it is more open than MS-DOS.

Newsgroups: comp.arch
From: kolding@cs.washington.edu (Eric Koldinger)
Subject: Re: IBM AS/400 is the world's slowest computer
Organization: Computer Science & Engineering, U. of Washington, Seattle
Date: Thu, 24 Dec 92 20:34:52 GMT

In article <Bzs3zn.43H.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>cecchi@rchland.vnet.ibm.com (Del Cecchi) writes:
>>In article <1992Dec22.092355.29859@adobe.com>, zstern@adobe.com (Zalman Stern) writes:
>>|> In particular, is it based on PowerPC or is IBM going to  
>>|> have two 64 bit RISC architectures floating around.
>
>>"IBM doesn't comment on un-announced machines"
>
>The workstation group has tried to persuade the rest of IBM to use
>its silicon. As long as the division making the AS/400 is profitable,
>it will have the option of resisting this pressure.

The AS/400 uses a tagged memory-system and tagged registers to protect
capabilities (or pointers, as they call them).  There are also a number of
operations that only take place on capabilities.  This makes it rather unlikely
that they'd use a stock micro-processor from the workstation group.  You could, 
of course, either emulate these features in software, or modify the basic
PowerPC architecture.  The first, however would be very inefficient (you'd have
to check every memory reference to see if you're working with a capability or a
data item), and the second *could* involve extensive modifications to the basic
PowerPC architecture and implementations.

I'd bet IBM will have two 64-bit architectures floating around.  Besides, I've
heard rumors that the pointers on this improved AS/400 are going to be extended
to 96-bits, anyway. That would probably rule out PowerPC right away.

-- 
    				|   Eric Koldinger
    Your tax dollars at play.	|   University of Washington
	 			|   Department of Computer Science
				|   kolding@cs.washington.edu
Newsgroups: comp.arch
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 25 Dec 92 03:10:35 GMT
Distribution: world
Organization: The Wolery

peter@ferranti.com (peter da silva) writes:
> > OK, try this. VMS has something called an AST (Asynchronous System Trap) which
> > is similar to a user-mode interrupt.
> 
> Yes, I'm familiar with it from RMX.  There, at least, unless you're working
> in assembler it's something to be used with extreme care lest you trash the
> language runtime.

This is largely false in the VMS environment.  Language runtimes are mostly
reentrant; the big exception is the C runtime, which is a piece of crap
anyway.  (And in any case, the C runtime doesn't mind if you don't use any
of the non-reentrant code.  Only calling a non-reentrant routine from an
AST while the same or a related routine is also executing has problems.)

> > This may occur at any time: for instance,
> > an asynchronous I/O can call an AST routine when the I/O completes. When the
> > AST routine completes, control returns to the code that was executing at the
> > time the AST occurred. (The analogy in NT is the APC, or Asynchronous
> > Procedure Call.)
> 
> And in UNIX the analog is a "signal". Now, a signal is a little "safer" than
> an AST (at least as under RMX), in that it's guaranteed to run in your task
> context.

Unix signals are basically a small subset of AST functionality.  Signals
can be implemented in VMS using ASTs, but not vice-versa.

> > Now, much of the run-time stuff in UNIX is non-reentrant.
> 
> Much of the *C* run-time in *any* language is non-reentrant, and I would
> be surprised if the VMS library was any better. If I get an AST while I'm
> in the runtime (say, in the Fortran library in the middle of a formatted
> I/O statement) I would expect dire consequences from calling the language
> runtime. I have never written an asyncronous signal handler under any
> operating system (out of UNIX, RMX, AmigaOS, and RSX-11) where I didn't
> have to watch for that sort of thing. In RSX all you can do from an AST,
> pretty much, is access memory.

I think you'd find the FORTRAN library is fine for AST reentrancy.  I've
certainly never seen any problems related to non-reentrancy of library
routines.  (That doesn't say there are no gotchas lurking.) 

I mean, reentrancy is (or should be) a non-problem.  It's *not* hard to
write re-entrant code, particularly when you're dealling with interrupt
reentrancy (ie the routine interrupts, runs to completion and leaves
the mainline to continue) rather than multitasking or multiprocessing. 

The C library on Unix is non-reentrant because there wasn't much call 
for it (async code is mainly for exception processing, and usually results
in a longjmp() anyway; any seriously asynchronous stuff gets kicked into
a subprocess).  On VMS it's simply because the code is crap.

--
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
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: branch-and-link
Organization: Intel Corp., Hillsboro, Oregon
Date: Fri, 1 Jan 1993 00:29:20 GMT

    Here's a question for the hardware types: is there any reason either of
    design complexity or performance to not have *all* branches (conditional
    and unconditional) save their origin somewhere (probably in a fast
    dedicated register)?  I know various cpu's (the rs6000?) have done this
    in the past, but only as an option.  If there is no negative impact to
    doing this, it would be a real win for debugging crashes where a program
    (application or kernel) branch off to nowhere and die - and the poor S/W
    type is left guessing...

Make it an option, specific to a model.

Some microarchitectures can do it easily.

Other, quite reasonable, microarchitectures can't do it at all without
slowing down (or requiring a PC to be attached to every instruction as
it flows through the pipe).

When you can do it, great! But don't slow down other implementations
for a debug feature that is not in use most of the time.

--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
Xref: sparky comp.arch:11846 comp.arch.storage:881
From: tom@rsp.UUCP (Thomas Ruf)
Newsgroups: comp.arch,comp.arch.storage
Subject: Re: ?Concurrent DMA possible on smarter PC buses (EISA/MCA/Localbus)
Keywords: EISA,MCA,Localbus,VESA,PC,IBM,smartIO
Date: 21 Dec 92 21:16:34 GMT
Organization: RSP Datensysteme, W-Germany

mike@cbl.umd.edu (Michael Santangelo) writes:
>So this theoretical EISA SCSI controller and this theoretical EISA FDDI
>controller could both be doing DMA writes to main memory (interleaving their
>accesses I assume)?  Since PC's do not have multiport memory, I assume
>the EISA subsystem would itself (on behalf of BOTH of these controllers) have
>full control over the memory during the dual transfers, starving out the CPU?

On EISA, the CPU(s) is (are) considered to be one of the potential bus masters,
therefore the CPU(s) will get a fair share of the available bandwith.
On MicroChannel, the CPU is usually the lowest priority bus master,
therefore the peripherals "win" over the CPU.

And, BTW: the above mentioned controllers are not theoretical only.
-- 
Thomas Ruf	tom@rsp.de	Schneider & Koch GmbH
Newsgroups: comp.arch
From: herlihy@crl.dec.com (Maurice Herlihy)
Subject: Transactional Memory Tech Report by e-mail
Organization: DEC Cambridge Research Lab
Date: Sat, 26 Dec 1992 22:46:52 GMT

The Transactional Memory tech report is now available by e-mail from the CRL tech
report server.  Note that this is the same tech report previously made available
via anonymous FTP from U Mass.

A new CRL technical report is available:

                 	CRL Technical Report 92/7
                TRANSACTIONAL MEMORY: ARCHITECTURAL SUPPORT 
                       FOR LOCK-FREE DATA STRUCTURES
                          Maurice Herlihy
                          J. Eliot B. Moss
                          December 1, 1992
                                       
A shared data structure is lock-free if its operations do not require
mutual exclusion.  If one process is interrupted in the middle of an
operation, other processes will not be prevented from operating on that
object.  In highly concurrent systems, lock-free data structures avoid common
problems associated with conventional locking techniques, including priority
inversion, convoying, and difficulty of avoiding deadlock.  This paper
introduces transactional memory, a new multiprocessor architecture that
supports lock-free implementations of complex data structures in a simple and
efficient way.  Transactional memory allows programmers to define customized
read-modify-write operations that apply to multiple, independently-chosen
words of memory.  It is implemented by straightforward extensions to any
ownership-based multiprocessor cache-coherence protocol.  Simulation results
show that transactional memory outperforms the best known locking techniques
for simple benchmarks, even in the absence of priority inversion, convoying,
and deadlock.

To retrieve the abstract for any report or note, send a message saying
(for example) "send abstract 92/9" or "send abstract 92/9 92/10", using
the number of the desired technical report to
        techreports@crl.dec.com (Internet)
        crl::techreports (DECnet)
Capitalization does not matter. 

To retrieve the PostScript for any report or note, send a message saying
(for example) "send postscript 90/3" or "send postscript 90/3 90/2", using
the number of the desired technical report to
        techreports@crl.dec.com (Internet)
        crl::techreports (DECnet)
Capitalization does not matter. 

Abstracts and PostScript versions of the CRL technical reports are
also available via anonymous FTP to crl.dec.com, in the directory
/pub/DEC/CRL/{abstracts,tech-reports}.

To be added to the mailing list for announcements of CRL technical reports,
send mail to
        techreports-interest-request@crl.dec.com (Internet)
        crl::techreports-interest-request (DECnet)


Michelle Gillespie                                        Cambridge Research Lab
michelle@crl.dec.com                                      Digital Equipment Corp.
Xref: sparky comp.arch:11971 comp.sys.dec:6628 comp.sys.sgi:18347 comp.sys.hp:14382
From: rlyle@nl.oracle.com (Rob Lyle  Wizard of Ozje)
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Date: 28 Dec 92 13:25:29 GMT
Followup-To: comp.arch
Organization: Oracle Europe

In article <1992Dec26.001827.25290@bilver.uucp>, wbeebe@bilver.uucp (Bill Beebe) writes:

[ ... Random gunk deleted ... ]

|> to run adequately, both require lots of system resources to run
|> adequately, and both have equal numbers of vociferous bigots.

I too, second this opinion.  I too, have developed on both platforms.
I therefore refuse to state a bias in either direction except that UNIX is
obviously superior [ 8 out of 10 customers say so ;-) ]

--Rob.


|> William H. Beebe, Jr. - wbeebe@bilver.UUCP
|>                  UUCP - {ucf-cs,peora,uunet}!tarpit!bilver!wbeebe
|>                       - bilver Public Access Unix, Orlando FL
|>                       - (407)644-8327  2400/9600  24 hours  8N1

-- 
Robert P K Lyle		#include <std_disclaimer.h>	**********************
UNIX System Manager					 If I could play the
ORACLE Nederland					Blue Peter theme tune
Rijnzathe 6,	 					   here, I would.
3454 PV  						**********************
De Meern
E-mail:  rlyle@nl.oracle.com				FAX:     +31 3406 65603
Voice:   +31 3406 94211					Private: +31 10 4809140
Newsgroups: comp.arch
From: rmk@rmkhome.UUCP (Rick Kelly)
Organization: The Man With Ten Cats
Date: Thu, 24 Dec 1992 04:01:57 GMT
Reply-To: rmk@rmkhome.UUCP (Rick Kelly)

In article <DERAADT.92Dec21165342@newt.newt.cuc.ab.ca> deraadt@newt.cuc.ab.ca (Theo de Raadt) writes:
>In article <9212200017.12@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes:
>   I don't see where this has anything to do with Intel.  Cyrix decided that
>   they could make some money by cloning a best selling CPU chip.  Obviously,
>   they have missed something.  A curious individual with a 486DLC system, a
>   486DX system, two logic analyzers, and two NeXTStep bootdisks should be
>   able to track down the problem.
>
>And probably binary-patch it to work.

Exactly.  I would almost bet that it is some weird timing problem.

-- 

Rick Kelly	rmk@rmkhome.UUCP	merk!rmkhome!rmk	rmk@frog.UUCP