HDTenEightyP/NetNews huggingface dataset:
From: pettengill@cvg.enet.dec.com ()
Subject: Re: DEC Alpha architecture issues
Reply-To: pettengill@cvg.enet.dec.com ()
Organization: Digital Equipment Corporation
Date: Fri, 20 Nov 1992 06:45:29 GMT


In article <1992Nov19.204209.6619@nntpd.lkg.dec.com>, dipirro@star.dec.com (Steve DiPirro) writes:
|>In article <lgnfc3INNqnt@spim.mti.sgi.com>, woodacre@mips.com (Michael Woodacre) writes...
|>>In article <1992Nov18.210416.27212@nntpd.lkg.dec.com>,
|>. . .
|>>Can you explain how this is different from kernel code with interrupts
|>>disabled on any other risc processor? For instance, an R4000 can
|>>implement uniprocessor-atomic "instructions" which are sequences of
|>>MIPS instructions to implement complex functions by running code
|>>in kernel level with interrupts switched off.
|>
|>There are certainly similarities. 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. The environment allows
|>more flexibility and more possibilities than merely running in the "standard"
|>environment with interrupts disabled.

Another difference is that the instructions available to PALcode are not
architected.  The assumption is that PALcode will use standard Alpha
instructions plus up to five additional instructions specific to the
implementation.  Also, no cpu registers are defined.  The PALcode is what
implements standard things like interrupts triggered by implementation
specific mechanisms.  So, the CPU implementations are free to be as creative
as they can be in making the basic instruction set fast as well as making
PALcode fast.

On the other hand, if you think that interrupts should dispatch via an
interrupt vector, then you can implement PALcode to do that.  Or if you
prefer that on an interrupt you jump to location zero where a special
instruction is executed to determine the source of the interrupt, the
`hardware' can be implemented that way as well.

The PALcode shipped with the current hardware supports two styles of
hardware interface for things like interrupts, page faults, etc.  There
are only a handful of PALcode calls that are common between the two
styles.  While it is possible that an operating system might include
its own PALcode (it can be switched), given the possibly significant
differences in the PALcode environments for different chips and systems,
this is probably not going to happen.  However, for imbedded applications,
you will need to develop PALcode specific to the application.  One might
expect that some applications that don't need interrupts or virtual
memory or other overhead might implement the entire application without
any sort of PALcode at all.

Basically, PALcode is one of the features that makes the Alpha architecture
unbiased toward VMS or unix, but instead biased totally toward performance.

mulp [jack of all trades, master of none]
DEC 
Newsgroups: comp.arch,comp.lang.misc
From: kpf@oasis.icl.co.uk (Karl Funk)
Newsgroups: comp.arch
Subject: Help finding Research Direction
Date: 22 Nov 92 16:26:26 GMT
X-Newsreader: Tin 1.1 PL3

Subject: Help finding Research Direction
Newsgroups: comp.arch
Distribution: 
Summary: 
Keywords: 

Hi,
I am sorry if you get a lot of postings of this nature but please
bear with me...
I have recently graduated from University with a (UK) First class BSc
Honours Degree in Computing Science. Although I have found gainfull 
employment in the computing industry I feel that I may be able to go
further academically. Therefore I have come to the decision
that I would like to attempt some form of part-time post-graduate study
(debts incurred while studying prevent me from continuing
full-time). The prefered form of this is MSc by research leading to
PhD. 
My main areas of interest are High Performance Computer systems,
Architecture, Performance Measurement. But if anyone can turn me on 
to something else than i am only too willing to listen.
My problems are:
(1). I need to find good sources of current research information
so that I can get up to speed on what is going on. These include
Books, Journals and electronic (i.e. ftp sites).
(2). I need to find a Univerity somewhere which is willing to
take a part-time and distance student (I am in Berkshire, UK).
(3). I need information on the current trends and discussion on
the suitability of any ideas which I may have for a research
area.
If anyone out there can help on any of these - (or if you have 
an idea that you have been kicking around and cannot find time for...) then I
will be extremly grateful.
Thanks in advance for and help/advice and I apologise if anyone
considers that I have wasted their time.
Cheers,
Kark Funk.
From: pgainer@vnet.ibm.com (Patrick Gainer)
Date: Wed, 18 Nov 92 11:13:42 EST
Newsgroups: comp.arch
Subject: Re: IBM Clock-tripled 486
Organization: IBM - Toronto Lab
Disclaimer: This posting represents the poster's views, not those of IBM
News-Software: UReply 3.0
            <Bxw6tK.KMM@pix.com>

In <Bxw6tK.KMM@pix.com> Josh Osborne writes:
>In article <1e937lINNq50@gap.caltech.edu> rrm@ssdp.caltech.edu writes:
>>So, I understand that IBM announced a clock-tripled (33MHz/99MHz) version
>>of the 486 (a DX3?) at Comdex.  Can anyone in the know at IBM (or Intel)
>>comment further on this?  IBM supposedly designed this chip under their
>>existing licensing agreement with Intel.
>
>The only 486 CPU that I know of that IBM announced is a 486SXL, which is
>a clock dubled 486 in a 386SX pinout (for the portable market).  Even
>with it's extra large cache it seems a tad bit silly to me (the clock).

I don't speak for IBM but I have seen the announcement letter. IBM did
announce a 486 running internally at 100 MHz, externally at 33 MHz.
The chip has a 16 Kbyte internal cache and cache controller. I don't have
more details. Demos were running at COMDEX.

>           stripes@pix.com              "Security for Unix is like
>      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"

Patrick Gainer
pgainer@vnet.ibm.com

Newsgroups: comp.arch
From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
Subject: Re: More Alpha AXP Performance Numbers
Reply-To: vhs@rhein-main.de
Date: Mon, 16 Nov 92 17:33:06 GMT

In article <Bxo927.ECF.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
> 
> In article <Bxo6rI.C89.2@cs.cmu.edu> I wrote:
> >Probably for the same reason one would buy an Amdahl - big IO, big
> >memory, big caches
> 
> Just to rub the point in: the DEC 10000 AXP has:
> 
> - 6 processors
> - 2 to 14 GB of ECC RAM
> - up to 4 Futurebus+ IO busses
> - up to 8 FDDI (100 Mb/s network) links
> - up to 56 GB of in-cabinet disk
> - up to 284 GB of directly attached disk
> - up to 10,000 GB of in-cluster disk
> - 800 MB/s "system interconnect"
> - 400 MB/s I/O bandwidth
> - support for HIPPI,CI,XMI,...
> - Integrated Uninterruptible Power System

yes, but...







...can it run MS-DOS?

;-)

--
Volker Herminghaus-Shirai (vhs@rhein-main.de)

Computer industry: Industry in which the number of units sold of any
given product is inversely proportional to its technical excellence.
See also: MS-DOS, Windows, IBM-PC, X, QWERTY,
          80x86, TrueType, Survival of the shittest.
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.arch
Subject: Re: PA-RISC ``semantic loading'' (according to DEC)
Date: 19 Nov 92 20:46:12 GMT
Organization: Department of Computer Science, U of Copenhagen

kaiser@mammal.vbo.dec.com (Peter Kaiser) writes:
>campbelr@hpcuhe.cup.hp.com (Bob Campbell) writes:
>>Someone at DEC writes:
>>>I write:
>>>> I suspect
>>>> that PA-RISC can get by with executing fewer instructions as well.
>>> This is, in a nutshell, the CISC viewpoint.
>>Some might call it engineering. 
>Touchy? :-)

While this charming little cascade could run for a while, I'll just
point out that I really think that the first gentleman from DEC was
stretching it --- I was clearly describing the HP-PA architecture as
being placed firmly within the RISC sphere, albeit in the less
aggressively hardware-optimizable end.

Rather than snide remarks, I had hoped to elicit informed comment as
to how much the statefulness of the HP-PA programmers' model impacts
(or can be assumed to impact) current and future implementations, in
development time *and* in achievable speed for a given technology.

Please?

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
Newsgroups: comp.arch
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 21 Nov 1992 04:07:32 GMT

dik@cwi.nl (Dik T. Winter) writes:

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

Just put the asm code in a (non-inline) function, instead of in a macro or
inline function.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.arch
Subject: Re: DEC Alpha architecture issues
Date: 23 Nov 92 12:27:27 GMT
Organization: Department of Computer Science, U of Copenhagen

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

>In article <1992Nov19.204729.24714@crl.dec.com> payne@crl.dec.com (Andrew Payne) writes:
>>>The last sentence is key here. If branches can be predicted with decent
>>>accuracy then it is hard to obtain benefits from conditional moves
>>>over using conditional branches. 
>>
>>Do you have any data to back up this claim?

>Sure do. If branches can be predicted with 100% accuracy then the
>version with conditional branches may run up to twice as fast. :-)
>Seriously, the silly example above should nonetheless show that if
>there are many instructions to guard, then potentially only half of the 
>functional units will accomplish useful work while running the code
>surrounded with conditional moves. 

If you can predict conditional branches, surely you can predict
conditional moves and other conditional instructions as well, even
using much the same techniques. In general any technique that can be
used to optimize conditional branches can also be used to optimize
other conditional instructions, so I can't see that using conditional
instructions in general can ever be worse than using conditional
branches only. One can then discuss how to reduce the penalty of
having conditions only on branches.

	Torben Mogensen (torbenm@diku.dk)
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: DEC Alpha AXP System INTEGER Performance
Keywords: Alpha, AXP, SPEC, DEC, INTEGER
Date: 22 Nov 92 20:11:30 GMT
Article-I.D.: cs.By4w36.EMo.2
Organization: School of Computer Science, Carnegie Mellon

samf@yosemite.dell.com (Sam Fuller) writes:
>After reviewing the Alpha performance claims, I had the feeling that
>the integer unit did not really run at 133Mhz.

No, it runs full speed.

I tried a worst-case benchmark: a program which
- uses no FP, hence, the superscalar doesn't apply much
- manipulates a byte array (an image)
- makes multiple passes over an array bigger than the secondary cache

A 150 MHz OSF/1 Alpha was ~4.4 times faster than a 25 MHz R3000
(DECstation 5000/200). By comparision, the clocks are 6:1, the DRAM
speed is probably about 1:1, and your guess would have predicted 3:1.

A quick look at the generated code shows room for improvement, and I
expect that future compiler releases will do better. For one thing,
the compiler's profiling and feedback features aren't available to me
yet.
-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science
Xref: sparky comp.arch:10971 comp.lang.misc:3818
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Date: 20 Nov 92 00:09:39 GMT

: From: mbk@lyapunov.ucsd.edu (Matt Kennel)
: Message-ID: <1efh6vINNm6c@network.ucsd.edu>
: The point, is, he [..Herman Rubin..]
: wants a high-level real language, with real optimizers,
: that nonetheless, does not consider hardware dependence to be anathema.

Except that when such capabilities are pointed out, he sneers at
them, and then asks for something else.  For example, gcc can generate
inline procedures with assembly instructions interspersed.  For pointing
this out, people get sneered at, and told that the notation isn't
simple enough.

When solutions to notation problems are presented, such as introducing
operators into gcc by the usual lex and yacc notations, or by
preprocessing with the TXL system mentioned by Matt a bit later, people
get sneered at, and told that specifying syntax in these ways is
too difficult.

So as near as I can see, solutions to the problems Herman Rubin
complains about are out there, and available for use now.  Herman Rubin
simply refuses to use them until they are customized for his needs to
an uneconomical extent.

The bottom line: Herman Rubin is attributing to malice and stupidity 
what is adequately explained by simple economics.

: So if C doesn't know how to do a fp divide with integer quotient and a
: remainder in one instruction, or how to do a "add in parallel, but
: only on those processors in this mask" (a CM),
: then no amount of higher-level rewriting will help.

Yes, this is the most central problem, which Jim Giles mentioned also.
Some method is needed which will specify the generated code, and yet
will fit in with the optimizations and register allocations and so on
which are already in place.  Jim says this "isn't too difficult", but 
I think it is the single most difficult part.  I've seen several
solutions, each with some advantages over the others.

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.
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.
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
Newsgroups: comp.arch
From: imohamme@ho08.eng.ua.edu (Imadulla S. Mohammed)
Subject: information about the Latest RISC chips 
Followup-To: imohamme@ho08.eng.ua.edu
Organization: The University of Alabama, Tuscaloosa
Date: Mon, 16 Nov 1992 04:59:40 GMT

Hi

	I would like to have information about the latest SUN,HP and IBM Risc chips. If anybody knows where i can find the above information. Please send me an
email at the above address.  Any help will be appreciated


yours
imad

Newsgroups: comp.arch
From: payne@crl.dec.com (Andrew Payne)
Subject: Re: DEC Alpha architecture issues
Organization: DEC Cambridge Research Lab
Date: Fri, 20 Nov 1992 18:36:10 GMT

In article <DOCONNOR.92Nov20095251@potato.sedona.intel.com> doconnor@sedona.intel.com (Dennis O'Connor) writes:
>
>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.

No, it's not really microcode at all.

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:

1. The I-stream is _physically mapped_ (otherwise, you can't do ITB 
   manipulations)

2. You can access the five implementation specific opcodes (that cause a
   reserved opcode exception if executed in non-PAL mode)

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

Otherwise, when running in PAL mode, it is business as usual:  you can use 
all of the Alpha instructions.  PALcode is just code written to run in 
PAL mode (i.e. it uses the five special opcodes to manipulate the machine 
state).

PALcode isn't necessarily stored in any special place:  it's fetched into
the processor for execution in the same manner that all other code is 
fetched (it gets cached in the I-cache, etc).  Most systems load PALcode 
into main memory from ROM, disk, or network, just like you would load 
boot code.
-- 
Andrew C. Payne
DEC Cambridge Research Lab
Newsgroups: comp.arch
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: DEC Alpha architecture issues
Organization: Digital Equipment Corporation
Date: 23 NOV 92 12:53:40    


In article <lgnfc3INNqnt@spim.mti.sgi.com>, woodacre@mips.com (Michael Woodacre) writes...
> 
>Can you explain how this is different from kernel code with interrupts
>disabled on any other risc processor? For instance, an R4000 can
>implement uniprocessor-atomic "instructions" which are sequences of
>MIPS instructions to implement complex functions by running code
>in kernel level with interrupts switched off.
> 
It is very similar. The difference is that the high level function is defined
and software developers can count on this function being available in a 
consistent way across many implementations. Our model was that a processor 
designers would write the PALcode for their machine. The other advantage is
that you avoid the overhead of a system service call. If the function
requires memory access, you can implement it easily by executing PALcode
with memory management on for data accesses, so you don't have to check page
table entries explicitly in software.

Dileep
Co-inventor of what used to be EPICODE on PRISM
Xref: sparky comp.arch:10995 comp.benchmarks:1758
From: dseal@armltd.co.uk (David Seal)
Newsgroups: comp.arch
Subject: Re: Registerless processor
Date: 18 Nov 92 18:13:11 GMT
Distribution: comp
Organization: A.R.M. Ltd, Swaffham Bulbeck, Cambs, UK

In article <1992Nov13.181654.11692@fcom.cc.utah.edu> drdavis@u.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).  This goes
>against the RISC idea of having very large register sets with load store
>instructions.  This machine would just reference memory, and the most
>common addresses becoming cached internally to the processor giving very
>fast access.  Does anyone know of such a machine, and what are your
>thoughts on this kind of architecture.  I envision the cache being
>something like 8K or greater giving a large effective register set.

One common difference between the registers and the cache is that the
register bank is multi-ported, while the cache is single-ported. This
results in the registers supplying a much higher effective bandwidth to the
ALU and other parts of the processor than the cache can. To get equivalent
performance out of a registerless machine, you're going to have to
multi-port the cache - which will make it take up similar amounts of space,
power, etc., as a large register bank.

Another big difference is that the register bank usually is usually
addressed statically (i.e. the compiler decides what register is used) and
has comparatively few entries, while the cache is addressed dynamically
(i.e. the processor decides on the fly what cache entry to use) and has
comparatively many entries. A couple of side effects of this are:

(a) Register access is generally faster than cache access.

(b) Register addresses (i.e. register numbers) are generally shorter than a
    cache address could possibly be, which in turn are shorter than the
    addresses that are actually used for the cache (i.e. memory addresses).
    This improves code density considerably, with various effects on speed
    (denser code requires less memory bandwidth, uses the available cache
    more efficiently, etc.).

Overall, for these and other reasons, I believe the experience of the
computing community is that this is one of the situations where having two
levels in the memory hierarchy (i.e. registers *and* cache) is more
cost-effective than just having one. Some of the reasons are in fact very
similar to those for having both cache and main memory rather than just main
memory; some are specific to registers, which tend to be addressed
differently to other layers of the hierarchy because of instruction set
considerations.

David Seal
dseal@armltd.co.uk

All opinions are mine only...
Xref: sparky comp.arch:10763 comp.lang.misc:3703
From: mbk@lyapunov.ucsd.edu (Matt Kennel)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Date: 16 Nov 1992 04:13:47 GMT
Organization: Institute For Nonlinear Science, UCSD
NNTP-Posting-Host: lyapunov.ucsd.edu
X-Newsreader: Tin 1.1 PL3

hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:
: Nobody on this net, or others I have discussed this with, know of the 
: existence of a versatile syntax converter (macro processor).  Bob Silverman
: and Peter Montgomery have considerable contacts here, and they know of no
: such thing.  There are many macro processors out which at least handle some
: problems with macro name first, but apart from compilers, I know of none
: which would allow someone to write (Bob Silverman's notation) 
: 
: 	c = a ** b
: 
: and have it translated into 
: 
: 	c = doubmult(a,b).
: 
: C++ could hopefully do something intelligent with the second, so why
: do you guys who say that you are giving us everything to make life
: easy provide at least the translation facilities?


Translation: 

  Prof. Rubin wants to use a syntax which cannot be parsed with the
"standard" tools of compiler contruction kits.  Think of 
the old standbys "lex 'n' yacc"---he essentially wants something in
which the "tables" themselves could somehow be altered using langauge
statements.  Maybe the world doesn't revolve around statically generated
context-free unambiguous grammars.

Too many computer scientists think that "syntax is trivial" or "syntax
is uninteresting", which it may be to the inside of a compiler, but isn't
to ordinary users.

Now we come to the hard part:  what type of computer notations could
be made to work?

What would be truly too difficult to do, and what would be "simply a
matter of programming?"

: -- 
: 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)

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".
Newsgroups: comp.arch