HDTenEightyP/NetNews huggingface dataset:
From: dricejb@drilex.dri.mgh.com (Craig Jackson)
Newsgroups: comp.arch
Subject: Re: What happened to the UCSD p-System?
Date: 22 Nov 92 16:12:09 GMT
Organization: DRI/McGraw-Hill, Lexington, MA
NNTP-Posting-Host: bbn.com

In article <8qmiuB1w164w@hub.parallan.com> richardw@hub.parallan.com (Richard Walter) writes:
>Also, I read recently (within the last 6 months) in some trade journal
>(Info-world, I think) that Microsoft is writing some windows application
>(I think it was a database) in p-code for some reason.  (I know that
>this last bit sounds really, really hazy, but I do know that I saw
>the headline with something like "Microsoft brings back P-Code" (there
>I go being vague again...:)).
>
>-Richard Walter
>richardw@parallan.com

I have been told that many Microsoft applications over the years, back to
the original PDP-11/45 Xenix, used something like P-code.  I believe this is
one reason why that Excel and Word for the Macintosh and Windows until
recently didn't exhibit the segment structure normally found in
applications on those platforms.

I think that something like Pcode is the only likely explanation why
Multiplan ran on everything in sight at one point in the mid-'80s.
-- 
Craig Jackson -- cjackson@mgh.com (Straight Internet)
dricejb@drilex.dri.mgh.com (uucp-forwarded)
{bbn,alliant,redsox}!drilex!{dricej,dricejb}
From: terashim@mtecv2.mty.itesm.mx (Ing. Hugo Terashima Marin)
Newsgroups: comp.arch
Subject: Info on KSR, Sequent, Dataflow and Ncube systems
Keywords: KSR, Sequent, Dataflow, Ncube, commercial parallel systems
Date: 18 Nov 92 22:52:53 GMT
Organization: I.T.E.S.M. Campus Monterrey

Hello,
   I would like to get any information and references of the commercial
parallel systes such as  KSR, Sequent, Dataflow, Ncube. Any reference
would be greatly appreciated. Thanks in advance.
    Hugo Terashima
    ITESM
    terashim@mtecv2.mty.itesm.mx

Newsgroups: comp.arch
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: Re: More Alpha AXP Performance Numbers
Organization: Nanyang Technological University - Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Tue, 17 Nov 1992 04:10:26 GMT

Donald Lindsay (lindsay+@cs.cmu.edu) wrote:
: - 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

What OS will it run on? With current 32-bit BSD unix, it can only access
2Gbyte addresses.

	Must be a 64-bit version of Unix or VMS. Will it cause problems in
porting software to apha?

--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet

Newsgroups: comp.arch,comp.parallel,sci.math,comp.org.ieee,comp.software-eng
From: srimani@CS.ColoState.EDU (Pradip Srimani)
Subject: CFP, Special Issue of VLSI Design on INterconnection Networks
Organization: Colorado State University
Date: Thu, 19 Nov 1992 15:47:25 GMT

                            CALL FOR PAPERS
    
                    Special Issue of VLSI Design

                                on
			    
                     Interconnection Networks
		 
Tentative Publication Date: Early 1994


Due to fundamental physical limitations on processing speeds of sequential
computers, the future-generation high performance computing environment
will eventually rely entirely on exploiting the inherent parallelism in
problems and implementing their solutions on parallel machines.
VLSI technology makes the design of such multiprocessors feasible. We can 
view these processors as individual chips, several chips on a circuit board 
or even individual computers interconnected suitably to form networks.
Thus, interconnection networks and their performance become an
integral part of high performance computing in general and
designing parallel architectures in particular. 


The purpose of this special issue is to focus on the design and analysis 
of all aspects of interconnection networks and VLSI design issues. Specific
topics of interest include, but are not limited to:

 o  Network Topologies and Algebraic Properties. 
 o  Routing Algorithms. 
 o  Fault Tolerance Issues: Node and Link Failures.
 o  VLSI Chip Design Issues. 
 o  Mapping of Parallel Algorithms.
 o  Embedding Problems: Static and Dynamic.
 o  Reconfiguration Techniques for Fault Tolerant Networks.
 o  Load Balancing Issues. 
 o  Self-Stabilizing Distributed Algorithms on Networks.

Please submit five copies of your manuscript to  the guest editor 
by May 1, 1993:


                     Professor Pradip K. Srimani
                     Department of Computer Science
                     Colorado State University
                     Ft. Collins, CO 80523
                     Tel: (303) 491-7097
                     Fax: (303) 491-6639
                     Email: srimani@CS.ColoState.Edu


Instructions for submitting papers: Papers should be not exceed 30 double 
spaced pages including figures, tables etc.  Papers should not have
been previously published, nor currently submitted elsewhere
for publication. Papers should include a title page containing
title, authors' names and affiliations, postal and email
addresses, telephone numbers and Fax numbers. Papers should
include a 300-word abstract. [Note: If you are willing to review papers 
for this special issue, please send a note with research interest
to Professor Srimani.]


Publishers: Gordon \& Breach Science Publishers, 820 Town Center
            Drive, Langhorne, PA 19047
-- 
Pradip K Srimani                Tel: (303) 491-7097
Department of Computer Science  Email: srimani@CS.Colostate.EDU
Colorado State University       Fax: (303) 491-6639
Ft. Collins, CO 80523       

Newsgroups: comp.arch
From: moss@cs.cmu.edu (Eliot Moss)
Subject: Re: DEC Alpha architecture issues
Reply-To: moss@cs.cmu.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
	<1992Nov18.191730.1044@meiko.com> <lgnojjINN627@exodus.Eng.Sun.COM>
Date: Fri, 20 Nov 1992 15:17:27 GMT

Regarding conditional moves, I think that branch prediction is not the only
issue. Another issue is code density. A comparison followed by a conditional
move is one instruction shorter than a comparison followed by a branch
followed by an unconditional move. The number of instructions moved through
the pipe must be at least two (unless you are lucky to have a situation where
a compare and branch can fold into one instruction) and the conditional move
approach gives you that, but with no pipeline "bubble". In fact, conditional
instructions are easy to handle in a regular pipeline -- you just suppress the
store in the last step, and you certainly know the outcome of the comparison
by then. In a superscalar, where things get reordered, it is admittedly not
quite so simple.
--

J. Eliot B. Moss, Associate Professor	Visiting Associate Professor
Department of Computer Science		School of Computer Science
Lederle Graduate Research Center	Carnegie Mellon University
University of Massachusetts		5000 Forbes Avenue
Amherst, MA  01003			Pittsburgh, PA  15213-3891
(413) 545-4206, 545-1249 (fax)		(412) 268-6767, 681-5739 (fax)
Moss@cs.umass.edu			Moss@cs.cmu.edu
Newsgroups: comp.arch
From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
Subject: Re: DEC ALPHA Performance Claims
Reply-To: vhs@rhein-main.de
Date: Mon, 16 Nov 92 12:32:21 GMT

In article <1992Nov15.010845.25121@fasttech.com> zeke@fasttech.com (Bohdan  
Tashchuk) writes:
> In <1992Nov13.165319.11391@crc.ac.uk> ifenton@crc.ac.uk (I. Fenton) writes:
> 
> >i didn't write the numbers down, but i think that the low-end ALPHA
> >box is a 133MHz job which gives a specint92 of about 70-ish (?).  from what
> >i remember the 486-50MHz has a specint92 of around 30.  so, MHz for MHz,
> >alpha seems no better than a 486... or i am a twit ?!
> 
> MHz for MHz the 486 has very good integer performance. The R3000 is a little
> better, but many other RISCs aren't. The 486 has much poorer floating point
> performance than RISCs, but this isn't relevant to most DOS applications.
> 
> Intel has been doing a good job keeping their "market niche" happy. (Can you
> call their overwhelming market share a "niche"?)
> 
> I'd like to hear from RISC architects and implementers on this topic. Given
> all the touted advantages of RISC, why aren't they blowing Intel away?

Too many computer-illiterates getting caught by M$'s and intel's
marketing hype.

> The bottom line is that Intel has kept up with RISC much better than most
> RISC companies thought they would.

They are lagging in both absolute performance and in price/performance behind
many RISC chips (comparing *existing* chips at any point of time).

[rest deleted]

NewsGrazer: error opening /dev/flame-suit: permission denied

HELP!!!

--
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.
Newsgroups: comp.arch
From: schow@bcarh2d8.bnr.ca (Stanley T.H. Chow)
Subject: Re: DEC Alpha architecture issues
Organization: Bell Northern Research Ltd, Ottawa
Date: Mon, 23 Nov 92 16:11:11 GMT

In article <By4pEI.8r5.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>andrew@megadata.mega.oz.au (Andrew McRae) writes:
>>If it looks like microcode, smells like microcode ... Why call it PALcode?
>
>Because it doesn't even vaguely resemble microcode.
>
>- PALcode is fetched from the I-cache, not from ROM.
>- PALcode is decoded by the normal decoder, as opposed to to microcode,
>  which is often a raw mask over a processor's internal control lines.
>- Microcode is usually in charge of detailed sequencing/timing of e.g. 
>  register writebacks. PALcode has no concept of this, except for
>  some implementation-specific rules like "if you set this TLB control
>  register, then the TLB mode will change one clock later".

I know of at least one other Intel processor using micro-code with
these properties. But then, Intel is a CISC dinosaur doing reactionary
evil things so it is micro-code; on the other hand, DEC (at least the
NEW DEC) is a forward looking RISC convert so it's the sexy PAL-code.

Actually, I believe there is a distinction:

  The PAL-code is not part of the architecuture.

This means one can have a VMS-Aplha and a Unix-Alpha, etc. and most
of the system is still portable. Think of PAL-code as a "O/S dependent
Hardware Abstraction Layer"

--
Stanley Chow            InterNet: schow@BNR.CA
Bell Northern Research  UUCP:     ..!uunet!bnrgate!bqneh3!schow
(613) 763-2831
Me? Represent other people? Don't make them laugh so hard.
Newsgroups: comp.arch
From: trebor@foretune.co.jp (Robert J Woodhead)
Subject: Re: What happened to the UCSD p-System?
Organization: Foretune Co., Ltd.
Date: Sat, 21 Nov 1992 05:51:39 GMT

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

-- 
+---------------------------------------------------------------------------+ 
| Robert J. Woodhead, Biar Games / AnimEigo, Incs.    trebor@foretune.co.jp |
| AnimEigo US Office Email (for general questions): 72447.37@compuserve.com |
Xref: sparky comp.arch:11022 comp.lang.misc:3840
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: 23 Nov 92 10:12:40
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
	<7958@charon.cwi.nl> <By4Dwr.78r@mentor.cc.purdue.edu>
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: hrubin@pop.stat.purdue.edu's message of Sun, 22 Nov 1992 13:38:51 GMT

In article <By4Dwr.78r@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

   Full efficiency of code can be attained by hand-optimization, with whatever
   aid one can get from computers, for a given machine.

That's a statement of belief, not of fact. In fact, optimizations
can get complex enough that they go beyond what any person could
realistically do manually.

You are also assuming that people care about "full efficiency of
code". Most people don't.

					Thomas.
Newsgroups: comp.arch
From: willmore@iastate.edu (David Willmore)
Subject: Re: DEC Alpha architecture issues
Keywords: alpha architecture
Organization: Iowa State University, Ames IA
Date: Wed, 18 Nov 1992 22:29:51 GMT

keiths@cae.wisc.edu (Keith Scidmore) writes:

>1. The DEC Alpha includes a conditional move instruction that they claim
>   can be used to avoid using branches and the associated branch penalties.
>   I'm trying to evaluate the usefulness of this feature.  Can someone tell
>   me where I might find articles that discuss this or raw data that can be
>   used to calculate the advantages of such an instruction.  I'm not into
>   compilers, and I need to know what kinds of situations an optimizing
>   compiler could make use of this instruction.  Is it even practical?  Are
>   there any compiler writers out there with opinions on this?

You might try asking the HP people.  They were discussing the benefit of
their conditional execution 'branches'.  Other people to ask, if you're
brave enough, are the ARM people.  In their assembler, almost every inst.
is conditional.

>3. Cray has annouced intention to build a 300 Teraflop machine based on the
>   alpha.  What is the word for 1000 teraflops?

I believe it's Etaflop from the progression: 
				Units	Prefix Suffix
				10-18	atto	a
				10-15	femto	f
				10-12	pico	p
				10-9	nano	n
				10-6	micro	u (greek mu, sorry)
				10-3	milli	m
				10 3	kilo	k
				10 6	mega	M
				10 9	giga	G
				10 12	tera	T
				10 15	eta	E

I can't find a chart with higher entries.  Sorry, but the computer
industry isn't *allowed* to get any faster than 999 eta(something).
It's a physical law. :)

Maybe it's time for a trip to the library.  Anyway, I hope this helps.

---------------------------------------------------------------------------
willmore@iastate.edu | "Death before dishonor" | "Better dead than greek" | 
David Willmore  | "Ever noticed how much they look like orchids? Lovely!" | 
---------------------------------------------------------------------------
From: forsyth@minster.york.ac.uk
Newsgroups: comp.arch
Subject: source-to-source translation
Date: 22 Nov 92 16:42:07 GMT
Organization: Department of Computer Science, University of York, England

Herman Rubin asks for a macro processor that can convert
	c = a**b
into
	c = doubmult(a,b)

i think ML/1 could handle a macro with this syntax:
	%T The ML 1 Macro Processor
	%A P. J. Brown
	%J Communications of the ACM
	%V 10
	%N 10
	%D October 1967
	%P 618-
i'm not sure where you can find an implementation of it now.
there was a version on pdp11 unix.
Newsgroups: comp.arch,comp.lang.misc
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Los Alamos National Laboratory
Date: Mon, 23 Nov 1992 18:06:09 GMT

In article <1efg1gINNm6c@network.ucsd.edu>, mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
|> akao@.com (Adam Kao) writes:
|> : [...]
|> : Computer science is not mathematics.  Computer science is not the servant
|> : of mathematics.  Computer science is related to mathematics only by
|> : historical accident.
|> 
|> Yup, those mere "accidents of history", like Turing and Von Neumann.

This argument can go on and on.  The fact is that computing "science"
is a misnomer.  CS is to mathematics as engineering is to the hard
sciences.  Mathematics is the study of the properties of formal
systems.  CS is the application (and further study) of particular
varieties of formal systems.  To say that this relationship doesn't
exist or is an historical accident is to miss the fundamental nature
of CS.

-- 
J. Giles
From: grout@sp90.csrd.uiuc.edu (John R. Grout)
Newsgroups: comp.arch
Subject: Re: DEC Alpha AXP System INTEGER Performance
Date: 18 Nov 92 23:56:34 GMT
Reply-To: j-grout@uiuc.edu
Organization: UIUC Center for Supercomputing Research and Development

yankus@IMD.Sterling.COM (Mike Yankus) writes:

>You are forgetting about a large volume of programs which mainly do
>nothing but character manipulation.  These include editors, compilers,
>mail handling, and the very programs which do the posting and reading
>of News.  I would consider a machine which does not have efficient
>character handling capability a step backwards of about 30 years.
>Is this really the case with the Alpha?

No... one combines load and store (which are faster because they are
restricted to aligned 64-bit quantities) and various register-to-register
instructions to efficiently handle characters in registers... a typical RISC
tradeoff.
--
John R. Grout						j-grout@uiuc.edu
University of Illinois, Urbana-Champaign
Center for Supercomputing Research and Development
Xref: sparky comp.arch:10749 comp.lang.misc:3690
From: carroll@balin.cis.udel.edu (Mark C. Carroll)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Date: 15 Nov 92 19:38:47 GMT
Organization: University of Delaware, Newark

In article <Bxr8vG.IpI@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:
>In article <mwm.2n6z@contessa.palo-alto.ca.us> mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:
]]In <Bxq7y0.IJ@mentor.cc.purdue.edu>, hrubin@mentor.cc.purdue.edu (Herman Rubin) wrote:
]]] With instruction scheduling, one place for an optimizer would be in the
]]] ASSEMBLER, and even interaction between the programmer and the compiler/
]]] assembler.  I do not know of any such.
]
]]Herman, I've *never* seen you suggest something that hasn't been tried
]]already, in some form or another. This is no exception. It's been
]]tried. It didn't work very well.
]
]Trying something on a stupidly restricted basis cannot work well.  It seems
]like you are saying that the analogs of the "enrichment" programs that the
]educationists have come up with for the bright children, rather than allowing
]them to advance, do not accomplish much.
]
]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).
]

Herman, you're a liar.

On at least three occasions, I have answered this ridiculous thread of
yours with a recommendation that you take a look at TXL. TXL will do
exactly what you want from a macro processor.

TXL is a tool which takes a language, transforms it into an abstract
syntax tree, and then allows you to perform arbitrary transformations
on the tree, and output the results of the transformation.

Every single syntax that you have ever posted to the net could be
parsed by TXL and transformed into the conventional syntax of your
language. 

Archie lists dozens of sites that have TXL available.

In addition, someone recently announced a macro transformer named m5. From
the description I've read, m5 will also do the transformations that you've
wanted.

	<MC>


-- 
|| Mark Craig Carroll: <MC>     ||"I prize the cloudy, tearing sky,
|| Univ of Delaware, Dept of CIS|| for the thoughts that flap and fly.
|| Grad Student/Labstaff Hacker || For staying in and reading by.
|| carroll@udel.edu             || For sitting under" -Karen Peris
From: tremblay@flayout.Eng.Sun.COM (Marc Tremblay)
Newsgroups: comp.arch
Subject: Re: DEC Alpha architecture issues
Date: 19 Nov 1992 18:52:35 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: flayout

In article <1992Nov18.191730.1044@meiko.com> richard@meiko.com (Richard Cownie) writes:
>1. Conditional move instruction is certainly useful.  I was involved
>   in writing a compiler for the Acorn RISC Machine (ARM), which has
>   the unusual feature that all instructions are conditionally
>   executed, with a 4-bit field to specify the condition (the most
>   common condition being "always").  Any conditional branch over
>   a short sequence of instructions was optimised into a short
>   sequence of conditionally-executed instructions, which reduced
>   the code size and saved flushing the pipeline (there was no smart
>   branch prediction or delayed branches).

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. In cases where branches can be predicted,
a good processor front-end can provide the correct instructions
"most of the time" and basically eliminate branches ahead of time.
If the branch is correctly predicted than the full scalarity of
the processor is available for computation. With conditional moves,
the general case is that half of the functional units are available
since you have to duplicate each instruction (half for the setup
and half for the conditional execution).
For hard to predict branches (50% ~ 60%), with a small number of
instructions to guard, then conditional moves may be useful only if the
pipeline is designed to handle the forwarding of the data efficiently
(not free, requires junk in the pipeline).

- Marc Tremblay.
Sun Microsystems.
Newsgroups: comp.arch