HDTenEightyP/NetNews huggingface dataset:
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: branch-and-link
Date: 30 Dec 92 23:32:07 GMT
Organization: Auspex Systems, Santa Clara

>On a related note (vis-a-vis debugging ease) to the branch-and-link
>issue, another peeve I've always had is that no commercially available
>processors (that I know of) make NULL pointer detection easy withou
>serious run-time overhead.  Various OS's try by unmapping the first N
>pages of memory, which works fine until you run into a chip like the
>68030, which supports huge displacements. 

The 68030 is no different from most other processors here; it's
*identical*, of course, to the 68020 in that respect, and even the
earlier 68K's had 16-bit displacements.

Besides, on processors that *don't* have long displacements, the code
that's generated by programmers or compilers generally synthesizes them
with additions, or something such as that, in any case, so the size of
the displacement is irrelevant.

However, if 99 44/100% of all the references through a pointer use
displacements less than about 8K or so - and all the code *I've* seen
backs that assumption up, as very little of it has large displacements -
you can get 99 44/100% coverage.

>Not to mention if the index register pushes the effective address out
>of your protected window, you're hosed.

That's the same issue as the displacement issue; it has nothing to do
with your addressing modes, it has to do with how large the object
pointed to by the pointer in question are.

>If you have a standard base_reg+index_reg+disp format, it would seem to
>me that having the processor check the base register for NULL and
>faulting if it is wouldn't be that hard (or inefficient).

You *don't* always have that format.  And, given my admittedly scanty
knowledge about modern processors, I'm loath to assume that having the
processor do such a check wouldn't be that inefficient; it won't seem
that way to *me* unless at least one processor architect says so....
Newsgroups: comp.arch
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: IBM AS/400 is the world's slowest computer
Organization: Keith's Computer, Hope Mills, NC
Date: Tue, 22 Dec 92 13:53:47 GMT

In article <1992Dec20.235519.16823@news.uiowa.edu> jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:
>2) The AS400 runs RPGII.  I don't care about RPG, you probably don't care
>    about RPG, but there are some big important applications that use it.

Amen.  *BUT* RPGII can be now gotten elsewhere, and the "push" at the
400 confrences are to "Go Native", as in Native Mode AS/400 ala RPGIII.

>3) The AS400 is a capability based tagged architecture.  It offers security
>    like nothing else on the market.  That's not to say that it's perfect,

Amen again.  Drove me crazy it was so tight. You could secure any object
on the system in about a thousand ways, individually or in groups. 
There are some lessons there that some *IX folks could learn
too!

>    but while all us RISCy folks have been off worrying about MIPS, IBM has
>    noticed that tools providing incredibly tight control over access to
>    information are crucial in many markets.  Try writing an AS400 virus!

That's the big problem.  It is a little overboard and very difficult
to administer.  I thought *NOTHING* could be as bad as Xenix9BD/Unix
until I came across this thing.  Also it alienated a lot of folks used
to the say of doing things on the S/36 and S/34 platforms.

Try writing an AS/400 PROCEDURE, forget the virus.
-- 
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
Newsgroups: comp.arch
From: prener@watson.ibm.com (Dan Prener)
Subject: Re: No Last Call Optimization on Sparc and DECstation
Date: Sat, 2 Jan 1993 01:26:39 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center, Hawthorne, New York

In article <1992Dec30.094352.4243@cucs5.cs.cuhk.hk> bmtong@cs.cuhk.hk (Tong Bo-Ming) writes:

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

IBM's compilers for the RS/6000 do this, when possible.  There are a few
things one must watch out for.  The linkage conventions of the RS/6000
dictate that a procedure that must save and restore registers does so
using a save area in the caller's stack frame.  That means that, in your
second example, one cannot always regard p() as a leaf procedure unless
x() is a leaf procedure.  The differences between the conventional linkage
semantics of C and FORTRAN (multiple procedures in a FORTRAN 77 file are
regarded as if they came from multiple files, i.e., some may be replaced
at link time) mean, in practice, that this optimization can be done in
C but not in FORTRAN.

And, of course, this optimization eliminates tail recursion as an instance
of the more general phenomenon.
--
                                   Dan Prener (prener@watson.ibm.com)
Newsgroups: comp.arch
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Organization: Keith's Computer, Hope Mills, NC
Date: Tue, 22 Dec 92 15:35:19 GMT
Keywords: I/O, Point-to-Point, High Performance, Low Cost, Bus

In article <id.IO0W.TLE@ferranti.com> peter@ferranti.com (peter da silva) writes:
>I've seen two versions of this: one successful, one less so. The Convergent
>Technology bookshelf unit is a very nice design, with a positive mechanical
>lock and no arbitrary limits to the bus length. The Amiga expansion port is
>less successful, because it has no lock and the signal definition was never
>designed for multiple piggybacks. The original Amiga design would have been
>much better: basically stacked units with a bus running vertically up the
>back of the stack, using gravity for locking. It was abandoned because it
>would have added a several dollars to the cost of manufacturing a $1500 PC.

A modular block design is going to be slightly more expensive due to
case/connection cost.  I'd like to see the Convergent box sometime. 
I've never encountered one before.  Is the BUS architecture closed?

But imagine if it was standardized. You could buy a pre-fab block with
standardized mounting points for a circuit board and connectors, and
plug a project board into it.  Drive goes out, snap it off, and snap
another on.  This of course would require that:

>I'd like to see the bus specifics decoupled from the software, so you had
>some sort of interface that you told "go to unit so-and-so and send this
>control/read this data". Then you could use a low-cost hookup with ethernet
>type cables, or a high-speed bus type option, without impacting the software.
>You could even plug a low-speed adaptor into a high speed bus to hook up
>your laptop when you get home.
>
>If course this would logically be a LAN (um, CAN: Computer Area Network?).

Yes, exactly.  You could even make the thing somehow know how far off it
is, like contact the device 3 hops from the mother block, etc.  The
ethernet idea of unique Umpteen bit addresses somehow scares me. 
Perhaps use one decoupled bus pin, as a serial address marker that is
gobbled, incremented and passed down to the next device on the same pin,
sent every second or so until a block is connected and acks the address,
which would then pick up it's address, increment it ... 

>> <SIGH>  not in my lifetime I suppose.
>
>Go get a Burroughs/CT bookcase unit. UHaul uses them here in Houston, or
>call your local Unisys rep.
           ^^^^^
Hehehehe :) :)!


I'm sure It's not an expensive box :) :)!
-- 
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: No Last Call Optimization on Sparc and DECstation
Date: 4 Jan 93 04:14:02 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

raymondc@microsoft.com (Raymond Chen) writes:
>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.

	Actually, if you pass the first N arguments in registers, most such
calls can use last-call optimization.  I think most RISC compilers pass
some arguments in registers.  Even the SAS/C Amiga compiler will pass up to
2 pointers and 2 integers in registers.

-- 
GNU Emacs is a LISP operating system disguised as a word processor.
 - Doug Mohney, in comp.arch

Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
jesup@cbmvax.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
From: wilson@moonshine.llnl.gov (Mike Wilson )
Newsgroups: comp.arch
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-
Date: 22 Dec 92 21:07:17 GMT
Organization: Magnetic Fusion Energy - LLNL

timhu@ico.isc.com (Timothy Hu) writes:

>> Sun's CMW (shipping in volume as of 12/17/92) only needs a regular admin and a
>> security officer (who is required for any secure facility anyhow), and is being
>> evaluated for the DISA CMW (B2+ security).

>How can you tell if a machine has any security installed?
>-- 
if you have to ask, it's safe to assume that yours is not Orange Book certified.
If it did, it would be painfull enough that you'd know.  Follow ups to 
alt.security please?

-mike
--
-------------------------------------------------------------------
wilson@moonshine.llnl.gov | Unix Sysadmin - MFE	 | 510-423-5937
The above is a personal opinion, I have no idea if it is the opinion
of: 1)DOE 2)UC 3)LLNL 4)The space aliens in the superblock (oops!)
Newsgroups: comp.arch
From: john@iastate.edu (John Hascall)
Subject: Re: reentrant
Organization: Iowa State University, Ames, IA
Date: Sat, 2 Jan 1993 19:06:39 GMT

firth@sei.cmu.edu (Robert Firth) writes:
}lindsay+@cs.cmu.edu (Donald Lindsay) writes:

}>The OS world is moving towards multithreading...

}It is with some trepidation that I amend one of Don Lindsay's comments,
}but in my experience it is only the C/Unix world that is moving towards
}multithreading.  The rest of the world has been there for a very long time.

Perhaps the research world has been...
But as far as (popular) commercially available OSes, it would seem not:

  MS-DOS:  not a chance
     VMS:  nope
     MVS:  sort of, but horrid
      VM:  I dunno, and I hope never to find out ;-)
    OS/2:  ditto
    UNIX:  not yet
   OSF/1:  yes, but not much of a commercial success at this point

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systmes Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
Newsgroups: comp.arch
From: jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen)
Subject: Re: question about DMA devices
In-reply-to: don@zl2tnm.gen.nz's message of 24 Dec 92 01:37:25 GMT
Organization: Inst. f. Neuroinformatik, Ruhr-Universitaet Bochum, FRG
	<17596358@zl2tnm.gen.nz>
Date: 26 Dec 92 12:58:08

In article <17596358@zl2tnm.gen.nz> don@zl2tnm.gen.nz (Don Stokes) writes:

   The MicroVAX I addressed memory on the Qbus, in the same way it addressed
   peripherals.  DMA is no different on these systems, except that there is no
   need for mapping registers because the memory is in the same address space
   as the peripheral and can be addressed directly.  

Na, Don, the mapping registers not only serve to map (eg) Unibus addresses 
into (physical) system addresses, they're also doing the pagewise scatter/
gather for you. If you don't have them, you i) don't do DMA, ii) do DMA only
a page at a time (seems hardly worth the effort), iii) or have to make sure
that virtually contiguous address space is also physically contiguous, eg use
a base&bound scheme like the first PDP10s did (and some Crays do?). I think
at some point VMS added a pool allocation routine called something like
EXE$ALOPHYCNTG to allocate virtually _and_ physically contiguous memory
from nonpaged pool, in order to support the type of VAx which didn't have
mapping registers.

	Jan
From: grover@brahmand.Eng.Sun.COM (Vinod Grover)
Newsgroups: comp.arch
Subject: Re: No Last Call Optimization on Sparc and DECstation
Date: 4 Jan 1993 03:11:43 GMT
Organization: Sun
NNTP-Posting-Host: brahmand

In article <1992Dec30.094352.4243@cucs5.cs.cuhk.hk> bmtong@cs.cuhk.hk (Tong Bo-Ming) writes:
>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


Tail call elimination and tail recursion elimination are performed by
SPARCcompilers (1.0, and 2.0.1). On SPARC this saves register windows.

Vinod Grover


Xref: sparky comp.arch:11896 comp.sys.intel:2820
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch,comp.sys.intel
Subject: Re: Superscalar vs. multiple CPUs ?
Date: 23 Dec 92 14:42:26 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Dec21.134531.3253@athena.mit.edu>, solman@athena.mit.edu (Jason W Solinsky) writes:

| In how many of these examples are we actually concerned with processor
| performance? In editors and word processors we certainly aren't.

  Sorry, you obviously edit only small documents. Search, or search and
replace, on a large document, can take a great deal of CPU. A global
reformat can eat the cpu. Things as simple as making the printed text
one column smaller can take many seconds in a WYSIWYG editor, since page
breaks all need to be checked or changed, page numbers in the index and
table of contents change, etc.

  It will take a massive increase in CPU to bring operations like this
down to reasonable (ie sub second) response time, so I don't think
there's any lack of market in the word processing field.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
Newsgroups: comp.arch
From: solman@athena.mit.edu (Jason W Solinsky)
Subject: Re: uniprocessor design ceiling
Organization: Massachusetts Institute of Technology
Date: Sun, 3 Jan 1993 21:54:58 GMT

In article <1ho4g1INNgac@nigel.msen.com>, paulh@msen.com (Paul Haas) writes:
|> Bob Supnik (supnik@human.enet.dec.com) wrote:
|> 
|> : The ingenuity of processor designers (and semiconductor technologists) being
|> : far from exhausted, I believe this performance growth can continue for the
|> : rest of this decade.  There are some limiting factors:
|> 
|> : - Process technology evolution appears to be slowing somewhat, due to
|> :   lengthening development time (and cost) for new generations of semiconductor
|> :   processing equipment.
|> 
|> Is this a long term trend?

[begin sepculation]

I doubt it. In the past the slowing down of process technology evolution has
lead to process technology revolution. As the rate of improvement in
lithography slows down, people will just start looking towards new
technologies and begin building into the third dimension. There are certainly
many technologies out there which are just waiting for somebody to do the
research to make them more affordable.

Additionally, now that voltage is scalling with device size, total CMOS
performance (speed/area) is inversely proportional to the third power of
lithography line size, not the fourth power as used to be the case. That
means that the threshold at which it becomes more profitable to spend money
on 3D devices than on smaller lithography has become considerably smaller.
If cheap sub-micron fabrication is as difficult as people have been saying,
process people will just head upwards.

[end speculation :-) ]

I have a question along those lines. If (as I have been led to believe) there
exists a linewidth which is large enough for yield to be effectively 100%,
why hasn't anybody attempted to build a very tall, large line width chip?

Is the problem a difficulty in creating monocrystaline Si above the substrate?

Are problems with planarization cumulative such that working with too many
levels becomes impossible?

Or is there another reason?

Thanks.

Jason W. Solinsky
Newsgroups: comp.arch
From: wbeebe@bilver.uucp (Bill Beebe)
Subject: Re: IBM AS/400 is the world's slowest computer
Organization: W. J. Vermillion - Winter Park, FL
Date: Sat, 26 Dec 1992 00:30:22 GMT

In article <id.HD1W.X03@ferranti.com> peter@ferranti.com (peter da silva) writes:

>I'd hope it'd run pretty damn well, since we've had up to 10 users on a 286
>doing software development... which is about 30 times slower than the 486,
>with more demanding users.
>
>Now I won't say I was happy with the performance on the 286, but the current
>systems with moderately old 386es are adequate, and our 486 box screams.

Maybe I *really* am dumber than a box of dirt, but why, in this day of
networking, would anyone do team development on a single box when it would
appear that team development on networked single-user boxes would be a lot
more efficient? Why do we still need multi-user boxes except to support
obsolete business practices?

-- 
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
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: peter@ferranti.com (peter da silva)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: Xenix Support, FICC
Date: Mon, 21 Dec 1992 23:57:17 GMT

In article <BzGn32.37C@dscomsa.desy.de> Hallam@zeus02.desy.de writes:
> 1) Online manual still designed with aim of minimizing disk space rather than
> providing information.

Well, it's better than most systems which provide no online manual at all, or
provide one that requires some fancy hardware/software combination to use, and
can only be used from one seat at a time.

> 2) No help facility.

It's a fair cop, but in general I find I rarely use the help facility on VMS
unless I *can't* get to the offline manual and need to find an option. A help
facility is no replacement for a tutorial, and a tutorial and manual is more
useful than any of the three.

> 3) No standardized user firendly shell.

A fair cop, but there have been pretty nice front ends. I think that this will
show up in a matter of time as windows finally filter down to the commodity
market.

> 4) Command qualifiers hard coded into applications making multilanguage
> customization impossible.

I wouldn't want multilanguage customization of command qualifiers. Help
messages and error messages, yes, I'll go with that.

> 5) Requires expensive expert to have a chance of any security.

A fair cop, and I blame the vendors. It's not HARD to ship a system with
good default security. SCO claims to.

> 6) File system limited to sequential file, forcing applications to create
> their own file system on top of the UNIX one, thus preventing any
> standardization or application independent optimization.

On the other hand, there are some very strong traditions about file formats
and semantics that have proven extremely useful, and are one of the reasons
UNIX is so popular.

> The kernel is a major factor in determining how useful the system is. Only
> AT&T had the capability to introduce a shell to replace the standard ones
> that could have achieved a degree of acceptance. 

Um, the kernel and shell are separate components. Which are you talking about?

> If UNIX was ever allowed to become the sole O/S it would halt O/S deelopment
> completely.

Actaully, UNIX has allowed a lot of OS research that would otherwise be
impossible. By providing a useful lowest comon denoinator interface people
have been able to spend more time on the operating system and less time
reinventing the wheel. The amount of variety "under the hood" of UNIX and
UNIX-like systems is incredible.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
From: ajc@pa.dec.com (AJ Casamento)
Newsgroups: comp.arch
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Date: 1 Jan 93 18:29:33
Organization: Digital Equipment Corporation
	<1992Dec18.100700.62150@cc.usu.edu>
	<AJC.92Dec19132456@thendara.pa.dec.com> <BzoL0q.3zr.2@cs.cmu.edu>
NNTP-Posting-Host: thendara.pa.dec.com
In-reply-to: lindsay+@cs.cmu.edu's message of 22 Dec 92 21:58:00 GMT



In article <BzoL0q.3zr.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) 
writes:

>>ajc@pa.dec.com (AJ Casamento) writes:
>>>  I guess I not as upset by the concept of using an ASIC. Of course, I'm not
>>>talking about respinning a full custom ASIC for each new design either.

>>I would expect that the ASICs could become cheap, and would have a lot
>>in common internally.

>>However, ASICs have a lead time. If Compaq is serious about spreading
>>this as a standard, then they should make available a
>>common-denominator design based on common parts, or on FPGAs.
>>Something that lets people get their feet wet, at the very least.

Don,

  We do exactly this in the TURBOchannel Developer's Kit. It provides:

	* A functional TURBOchannel Option (capable of both DMA and PIO)
	* Schematics for the Option design
	* State machine diagrams for the design
	* PAL equations for the TURBOchannel interface logic
	* A BOM (Bill Of Materials) using all external part numbers
	* Source code for the Option ROM (the ROM is socketed)
	* A ROM developer's guide/example
	* Source code for the device drivers (currently Ultrix & OSF/1 with
	  VMS, OpenVMS and Alpha AXP OSF/1 drivers coming)

  This is intended to provide a designer with all of the building blocks that 
it took to build this option. You can install the option and play with the 
functionality and then try developing your own Option ROM and device driver to
test against the Option as well (all of the standard TURBOchannel documentation
is included in the kit).

  However, my point was that COMPAQ could also provide a common interface ASIC,
equivalent to the TcIA, that would provide a very cheap cut and paste logic for
Option card vendors that would provide a lowest risk path for migrating their
current designs to this new interconnect. By arranging an agreement with some
ASIC vendor to provide the same ASIC design as a mega-cell they would also be
enabling those vendors with a need for tightly integrated performance designs
to easily migrate. Their version of a common interface ASIC ought to be very
cheap given the datapath size. I highly recommend this alternative.

Still just my own view, of course.

				Thanx,
				  AJ


      **********************************************************************
      * AJ Casamento			"The question is not whether or    *
      * Digital's TRI/ADD Program	 not the opinions are mine; but    *
      * 529 Bryant Ave. PAG-2		 rather, which of my personalities *
      * Palo Alto, CA 94301-1616	 do they belong to?"		   *
      * 415.617.3460							   *
      * ajc@pa.dec.com  						   *
      **********************************************************************

Newsgroups: comp.arch,comp.sys.dec,comp.sys.hp,comp.sys.sgi