HDTenEightyP/NetNews huggingface dataset:
From: wyle@synopsys.com (Mitch Wyle)
Subject: SYNOPSYS OFFERS TWO NEW SYNTHESIS PRODUCTS
Organization: Synopsys Inc.
Date: Wed, 16 Dec 1992 03:10:48 GMT

Synopsys press release posted in biz.comp.software

Newsgroups: comp.lsi,comp.lsi.cad,comp.lsi.testing,biz.comp.hardware
From: wyle@synopsys.com (Mitch Wyle)
Subject: SYNOPSYS OFFERS TWO NEW SYNTHESIS PRODUCTS
Organization: Synopsys Inc.
Date: Fri, 18 Dec 1992 23:07:30 GMT

Another Synopsys press release posted in biz.comp.software
Newsgroups: comp.lsi,comp.arch
From: pngai@adobe.com (Phil Ngai)
Subject: Re: Intel's 100-Million Transistor Device
Organization: Adobe Systems Incorporated
Date: Sat, 12 Dec 1992 21:11:51 GMT

In article <VFmJVB1w164w@hub.parallan.com> richardw@hub.parallan.com (Richard Walter) writes:
>Where to buy Intel FLASH devices?  Why not call INTEL ???????????
>They have been in full production and available for at least a year, if

Ha ha, that's the funniest thing I've read all week. Thanks.

By the way, have you ever heard of EE Times or Microprocessor Report?

-- 
My opinions are my own.
From: phwl@ee.su.oz.au ()
Subject: Jiggle chip tester
Reply-To: phwl@ee.su.oz.au ()
Organization: Electrical Engineering, The University of Sydney, Australia
Date: Mon, 21 Dec 1992 02:47:08 GMT

I recently posted this article to comp.arch.bus.vmebus in response to
someone's questions about a analogue/digital IO VME card. It occurred to
me that some readers of comp.lsi may also be interested.

The following blurb is a short description of the board. Please contact
me if anyone has any questions about it. 

---------------------------------------------------------------

Jiggle is a general purpose chip tester which was designed specifically
for the training and testing of integrated circuits. It has been used
extensively to train VLSI implementations of low power artificial
neural network chips, although it could be used to test both digital and
analogue designs.

The Jiggle chip tester has the following features
- 64 digital IO channels
- 64 analogue IO channels
- 2 x 12 bit analogue to digital converters 
  multiplexed to the 64 analogue input channels
- 64 x 12 bit digital to analogue converters
- All digital and analogue pins can be sampled simultaneously
  and read back at a later time
- Analogue inputs have high input impedance ($50 M\Omega$)
- Software configuration of analogue and digital IO direction
- Easily customisable via a chip interface board
- VME bus interface
- UNIX library for Jiggle IO


Regards,
Philip Leong.
--
Department of Electrical Engineering	Tel. (+61 2) 692 3297
University of Sydney 2006		Fax. (+61 2) 660 1228
Australia				Internet: phwl@sedal.su.oz.au
From: chuck@ksr.com (Chuck Shavit)
Newsgroups: comp.lsi.testing
Subject: maximum-length LFSRs
Date: 18 Dec 92 17:08:26 EST
Distribution: comp.lsi.testing
Organization: Kendall Square Research Corp.


Dear Netters,

I am looking for an algorithm to compute a primitive polynomial of a Linear
Feedback Shift Register.  A primitive polynomial is a polynomial that cause
an n-bit LFSR to generate a sequence 2**n-1 different numbers (usually
there are many such polynomials for a given n; I am interested in just
one...).

Thanks,

Chuck Shavit
Kendall Square Research

chuck@ksr.com
Newsgroups: comp.lsi.testing
From: gakusei@bmerh136.bnr.ca (Andre Roy)
Subject: This is a test
Organization: Bell-Northern Research Ltd.
Distribution: ont
Date: Thu, 17 Dec 1992 17:24:54 GMT


This is a test, this is only a test
From: veit@du9ds3.fb9dv.uni-duisburg.de (Holger Veit)
Newsgroups: comp.lsi.testing
Subject: Re: Groups for ESD, SPC ?
Date: 16 Dec 92 08:45:43 GMT
Organization: Uni-Duisburg FB9 Datenverarbeitung
Reply-To: veit@du9ds3.fb9dv.uni-duisburg.de
NNTP-Posting-Host: du9ds3.fb9dv.uni-duisburg.de

In <88910001@teecs.UUCP> smithr@teecs.UUCP (Robert Smith) writes:

>Sorry if I'm in the wrong group but does anyone know if there is a group
>on the net discussing electro static discharge, SPC related to
>electronic production or reliability in general? I'd appreciate any
>suggestions on the right groups. Thanks.

>Bob.

You are not in the wrong group here. This group is on testing of electronic
circuits, and if you do testing, you also have to consider the production
process, fault tolerance and reliability. Feel free to contribute to this
group, and issue a query or start a discussion about ESD here.

Holger
-- 
|  |   / Dr. Holger Veit         | INTERNET: veit@du9ds3.fb9dv.uni-duisburg.de
|__|  /  University of Duisburg  |
|  | /   Dept. of Electr. Eng.   |          "Understand me correctly:
|  |/    Inst. f. Dataprocessing |     I'm NOT the WIZARD OF OS" (Holger)
From: smithr@teecs.UUCP (Robert Smith)
Date: Wed, 9 Dec 1992 18:35:49 GMT
Subject: Groups for ESD, SPC ?
Organization: Litton Systems, Toronto ONT
Newsgroups: comp.lsi.testing

Sorry if I'm in the wrong group but does anyone know if there is a group
on the net discussing electro static discharge, SPC related to
electronic production or reliability in general? I'd appreciate any
suggestions on the right groups. Thanks.

Bob.
Newsgroups: comp.lsi.testing,comp.lang.verilog
From: warren@stationd.storage.tandem.com (WARREN SAVAGE)
Subject: Verilog source for JTAG functions
Keywords: JTAG,Verilog,1149
Organization: Tandem Computers Inc, Cupertino CA
Date: Thu, 17 Dec 1992 21:25:49 GMT

Does anyone know if there is source code available for JTAG functions ?

Either public-domain or for-sale solutions would be OK.

Thanks,

Warren Savage
warren@storage.tandem.com
Newsgroups: comp.lsi,misc.books.technical
From: toma@baritone (Thomas Arneberg)
Subject: Seek comments on book: _Digital BiCMOS IC Design_
Organization: Cray Research Inc.
Date: 14 Dec 92 13:32:30 CST

Has anyone seen the following book?

	Title:   _Digital BiCMOS Integreted Circuit Design_
	Authors: Embabi/Bellaouar/Elmasry
	ISBN:    0-7923-9276-0
	Date:    1992  (417 pages)
	Price:   $105.00 (!)

Info from a flier I recieved:
   _Digital BiCMOS Integrated Circuit Design_ is the first book devoted
   entirely to the analysis and design of digital BiCMOS integrated
   circuits. The text also overviews CMOS and CML integrated circuit
   design. The application of BiCMOS in the design of digital subsystems,
   e.g. adders, multipliers, RAMs and PLAs is addressed. The book also
   introduces the reader to IC process technology, CMOS, bipolar, and
   BiCMOS. The modeling of both the bipolar and MOS devices are covered.
   Many process/device/circuit design issues are discusses.
(The flier was from Kluwer Academic Publishers, Kluwer@world.std.com.)

Sounds like a decent book, but at $105, I thought it would be nice to get
any unbiased opinions out there in net.land before I spend that much.

Thanks for any advice,
  - Tom A.
---------------------------------------------+------------------------------
;-) I'd rather be ____  Thomas R. Arneberg   | Internet: toma@cray.com
:-) singing in a |____| Senior IC Design Eng.| UUCP: ...!uunet!cray!toma
:-) Barbershop  _|   _| Cray Research, Inc.  | CLAIM TO FAME: Loni Anderson 
:-) Quartet!   (_)  (_) Chippewa Falls, Wisc.|   went to my high school 
---------------------------------------------+------------------------------
Newsgroups: comp.compilers
From: paco@cs.rice.edu (Paul Havlak)
Subject: Re: question on control dependence
Reply-To: paco@cs.rice.edu (Paul Havlak)
Organization: Center for Research on Parallel Computation
Date: Wed, 16 Dec 1992 17:08:33 GMT
Keywords: optimize, analysis

preston@dawn.cs.rice.edu (Preston Briggs) writes:
>McConnel's algorithm will require at least O(N^2) time (consider the bit
>vectors to be initialized).  On the other hand, I believe it only requires
>O(N^2) time worst-case.  Therefore, worst case, the algorithms are the
>same.  Best case (and probably expected case , Cytron et al. are faster,
>though perhaps only for very large N.

    It depends on how you define "worst case".  In terms of the time
and space required per control dependence, the newer Cytron et al.
algorithm (and I think the older one as well) can beat McConnel's
method by a linear factor.

	* When the number of control dependences is O(N), McConnel's
		algorithm is quadratic in its output -- O(|CD|^2).  It
		is linear in its output only when |CD| is O(N^2).

	* The newer Cytron et al. algorithm is always linear in its
		output -- O(|CD|).  This is particularly important
		because |CD| is much more often O(N) than O(N^2).

    I believe the newer Cytron et al. algorithm to be as fast as
theoretically possible.  Once you've built the predominator tree, it
requires very few (less than a dozen?) instructions to find each control
dependence relation.

Note: The newer Cytron et al. algorithm, which amounts to reading control
dependences off the postdominator tree, appeared in Cytron, Ferrante and
Sarkar's SIGPLAN '90 paper.  However, the method was also described
briefly in Ferrante, Ottenstein and Warren's July 1987 TOPLAS paper
(although without handling of labels).
--
Paul Havlak			Dept. of Computer Science
Graduate Student		Rice University, Houston TX 77251-1892
PFC/ParaScope projects		(713) 527-8101 x2738 	paco@cs.rice.edu
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: dkchen@sp91.csrd.uiuc.edu (Ding-Kai Chen)
Subject: Re: question on control dependence
Reply-To: dkchen@sp91.csrd.uiuc.edu (Ding-Kai Chen)
Organization: UIUC Center for Supercomputing Research and Development
Date: Wed, 16 Dec 1992 20:04:36 GMT
Keywords: design

preston@dawn.cs.rice.edu (Preston Briggs) writes:
>The general case of more than 2 succesoors is handled like this...

>	CD(X) = union(P(S)) - intersection(P(S)), for S in successors(X)

>(This is a much simpler version of another answer I posted earlier)

This can be simplified (also with less computation) further:

	CD(X) = union(P(S)) - P(X)

I think it is not difficut to prove that

	{intersection(P(S)), for S in successors(X)}=P(X)

Similarly,

	CD(X,L) = P(X_L) - P(X)

where CD(X,L) is the set of nodes control depend on X with label L and X_L
is the successor of X with label L.
Ding-Kai Chen

--
Ding-Kai Chen		University of Illinois
(217)244-0046		Center for Supercomputing R&D,
dkchen@csrd.uiuc.edu	465 CSRL 1308 W. Main St. Urbana, IL 61801


-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: marks@iris.mincom.oz.au (Mark Stavar)
Newsgroups: comp.compilers
Subject: Extension Languages
Keywords: question, design, comment
Date: 14 Dec 92 03:30:30 GMT
Article-I.D.: comp.92-12-056
Reply-To: marks@iris.mincom.oz.au (Mark Stavar)
Organization: Mincom, Brisbane, Australia

[ Article crossposted from comp.editors ]


I have a question relating to extension languages for editors:

IS there any specific reason why one would choose to utilise an prefix
notation language for extensions to an editor as opposed to infix or
post-fix?

Emacs utilised its own implementation of lisp, while in the PC world,
Brief ( which has a distinctly Emacs feel about it ) uses a native macro
language which is also implemented al la prefix notation.

Does prefix notation provide some facilities for better performance for
interpretive languages.  I am particularly interested since, as both Emacs
lisp and the Brief macro language were specifically written for their
respective products, I would have thought that the options would have been
available to utilise a more *natural* language interface.  ( My definition
of *natural* here being similar to other procedural languages that most of
us write all day. e.g. C, Pascal, Fortran. I think you can get my drift. )

This post is not implying that anything should change in the cases sited
above.  Rather, I am seeking more information as to why the particular
choices were made, what the advantages are that they provide, etc.

Thank you for any light you can shed

marks
--
Mark Stavar
Mincom
Juliette St
Brisbane Q Aust

Email:	marks@jove.mincom.oz.au
[People implement what they like, and what's a natural programming style
is 100% a matter of opinion depending on one's personal experience.  GNU
Emacs uses Lisp because Stallman likes Lisp.  Epsilon uses C.  Micro-emacs
uses Trac.  It's all compiled into internal bytecodes; there's not a lot
of performance difference due to the language style. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: jfisher@hplabsz.hpl.hp.com (Josh Fisher)
Subject: Re: static estimation of conditional branches?
Reply-To: jfisher@hplabsz.hpl.hp.com (Josh Fisher)
Organization: Hewlett-Packard Laboratories Palo Alto,CA
Date: Fri, 11 Dec 1992 18:06:21 GMT
Keywords: optimize

>[As I recall, Fortran II dropped FREQUENCY because it was infrequently
>used and made little difference.  I've heard that it may even have been
>implemented backwards and nobody noticed. -John]

I was told the story about 10 years ago by, I think, Lois Nash, at
Yorktown Heights.  She (or whoever told me the story if I've remembered
wrong) did the backend for the compiler that was to use these directives.
Sometime after releasing it, she took a vacation and someone reversed the
sense of what was passed to her in an earlier phase.  About a year after
this happened, she was debugging some object code and noticed the
reversal.  This was when people grovelled over the object code--in the
1950s, I guess--because of their general suspicion of compilers (*we*
never do that), yet no one ever pointed it out to her.  She figures nobody
noticed.

(By the way, the Multiflow compiler allows programmers to insert
directives to this effect to guide the compiler in chosing long regions
within which to do code motions.)

					-- Josh Fisher // HP Labs
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: davis@pacific.mps.ohio-state.edu  (John E. Davis)
Subject: Re: Extension Languages
Reply-To: davis@pacific.mps.ohio-state.edu  (John E. Davis)
Organization: Dept. of Physics, The Ohio State University
Date: Mon, 14 Dec 1992 17:11:06 GMT
Keywords: design

marks@iris.mincom.oz.au (Mark Stavar) writes: 
   IS there any specific reason why one would choose to utilise an prefix
   notation language for extensions to an editor as opposed to infix or
   post-fix? 


For my JED editor, I invented a language which I call S-Lang or
``Ssslang''.  It is stack based and resembles postscript in many ways.
However unlike other stack based languages, it supports local variables
which tremendously simply taking care of the stack.  However, this is not
just an editor language--- rather it is a language embedded into the
editor.  I am currently writing a program which utilizes a frame grabber
and I have embedded the languge in it as well.  So for example, suppose I
have a C function called `draw' which takes 4 integers and draws a line
between two points and returns nothing.  Then to embed this function in
the language, simply put:

add_intrinsic("line", draw, VOID_TYPE, 4);

in your C program.  Then you can call the function from within Slang:

1 1 10 10 line  ;; draws a line between points (1,1) and (10,10)

Then you can create a function called `box':

( [x1 y1 x2 y2]        ;; local variables
  =y2 =x2 =y1 =x1

  x1 y1 x1 y2 line
  x1 y2 x2 y2 line
  x2 y2 x2 y1 line
  x2 y1 x1 y1 line
) box

Then `1 2 10 12 box' will draw a box with two corners at (1,2) and
(10,12).  I think that you can see how such a program adds a new dimension
to a program with a C function called draw.  In addition, think about how
you would have to write the box function with NO local variables using
stack operators `dup', `exch', `roll', etc....

The reason I chose a stack based language is easy: The parsing stage is
simple.  I did not want most of the executable devoted to the language.

I will release Slang as a standalone product soon.  Of course it is not
really standalone because it needs to be embedded into you application.
Look at my JED sources (in ledit.c) to see how Slang is embedded.
--
John E. Davis
internet: davis@amy.tch.harvard.edu
bitnet: davis@ohstpy   office: 617-735-6746
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: xjam@cork.CS.Berkeley.EDU (The Crossjammer)
Subject: Re: Extension Languages
Reply-To: xjam@cork.CS.Berkeley.EDU (The Crossjammer)
Organization: University of California, Berserkeley
Date: Mon, 14 Dec 1992 08:01:40 GMT
Keywords: design

marks@iris.mincom.oz.au (Mark Stavar) adds:
> I have a question relating to extension languages for editors:

> IS there any specific reason why one would choose to utilise an prefix
> notation language for extensions to an editor as opposed to infix or
> post-fix?

Most people wouldn't list this as an a priori reason but prefix notation
is *trivial* to parse. Makes life easier on the language implementor, and
depending on the community, the users. 

Also typical extension languages don't have those fun filled, action
packed, programming constructs that beg for LR parsing. I would wager that
even those extension languages that have a Pascal/C heritage could be
relatively easily turned into a prefix notation and vice versa.

--
xjam@cork.Berkeley.EDU
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: bwilson@shasta.stanford.edu (Bob Wilson)
Subject: Re: question on control dependence
Reply-To: bwilson@shasta.stanford.edu (Bob Wilson)
Organization: Compilers Central
Date: Tue, 15 Dec 1992 19:48:43 GMT
Keywords: optimize, design, bibliography

Carl McConnell writes:
> I've come up with a simple algorithm for computing control dependences, ...

This sounds like the algorithm that was used in the PTRAN compiler.
I think it's described in a research report by Vivek Sarkar:

"PTRAN - the IBM Parallel Translation System"
IBM Research Division Report RC 16194
1990

Bob Wilson
bwilson@shasta.stanford.edu
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: idacrd!desj@uunet.UU.NET (David desJardins)
Subject: Re: static estimation of conditional branches?
Reply-To: idacrd!desj@uunet.UU.NET (David desJardins)
Organization: IDA Center for Communications Research, Princeton
Date: Sat, 12 Dec 1992 04:37:35 GMT
Keywords: optimize

The moderator wrote:
> [As I recall, Fortran II dropped FREQUENCY because it was infrequently
> used and made little difference.  I've heard that it may even have been
> implemented backwards and nobody noticed. -John]

Henry Spencer <henry@zoo.toronto.edu> writes:
> The other problem that occurs with such facilities is that programmer
> intuition is notoriously unreliable about such things.

I don't understand this statement in this context in this context.  I know
it's fashionable in this group to claim that compilers are supergeniuses
and humans are idiots.  This might even sometimes be the case for examples
like, "Should the variable FOO be held in a register?"  After all, a
typical programmer would not know enough about the compiler internals and
machine architecture to know all of the tradeoffs involved in this
decision.

But any programmer who is making a serious effort to write high-
performance code must know approximately how often each of the conditional
branches in critical sections is taken.  That's not a matter of
"intuition."  It's a question of understanding what the code is doing: an
understanding which is fundamental to optimization.

And we are just talking about communicating those facts from the
programmer to the compiler, with no judgments about their implications
attached.  It's up to the compiler to draw the appropriate conclusions, if
any.  I don't see how this can be "unreliable."

Of course, I too endorse the feedback of profiler information as a more
convenient (to the user) way to achieve similar results.

                                        David desJardins
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: Kurt Bischoff <bischoff@cs.iastate.edu>
Subject: Beta testers wanted Attribute Grammar Compiling System
Reply-To: Kurt Bischoff <bischoff@cs.iastate.edu>
Organization: Compilers Central
Date: Wed, 16 Dec 1992 12:47:51 GMT
Keywords: tools, attribute, lex, yacc

                     Beta testers wanted for

             An Attribute Grammar Compiling System
                           based on
                        Yacc, Lex, and C

Ox generalizes the function of Yacc in the way that attribute grammars
generalize context-free grammars.  Ordinary Yacc and Lex specifications
may be augmented with definitions of synthesized and inherited attributes
written in C syntax.  From these specifications, Ox generates a program
that builds and decorates attributed parse trees.  Ox accepts a most
general class of attribute grammars.  The user may specify postdecoration
traversals for easy ordering of side effects such as code generation.  Ox
handles the tedious and error-prone details of writing code for parse-tree
management, so its use eases problems of security and maintainability
associated with that aspect of translator development.

The translators generated by Ox use internal memory management that is
often much faster than the common technique of calling malloc once for
each parse-tree node.

Ox is a Yacc/Lex/C preprocessor, and is designed to bring attribute
grammars closer to the mainstream of Unix-based language development.  Ox
inherits all of the familiar syntax and semantics of Yacc, Lex, and C.  It
is relatively easy to convert programs between Ox code and "pure
Yacc/Lex/C" code.

Ox has been used to build a compiler for a small (eighty grammar rules)
block-structured imperative programming language, and has been tested and
found to be portable among the following systems running Unix:

     Hewlett-Packard PA, 680x0
     Sun 3, SparcStation
     DECstation 2100, 3100, 5000
     Silicon Graphics Inc. R3000
     NeXT workstation

The author of Ox is Kurt M. Bischoff (bischoff@cs.iastate.edu), Department
of Computer Science, Iowa State University.

For more information, please send your e-mail address to:

     ox-request@cs.iastate.edu
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: parrt@ecn.purdue.edu (Terence J Parr)
Subject: PCCTS 1.06 MSDOS, OS/2 Binaries Available
Reply-To: parrt@ecn.purdue.edu (Terence J Parr)
Organization: Compilers Central
Date: Wed, 16 Dec 1992 18:23:33 GMT
Keywords: tools, MSDOS, FTP

A few users are having trouble getting PCCTS 1.06 to work under DOS and
OS/2.  Therefore, we have compiled them and placed working executables in
a directory under the normal PCCTS 1.06 directory at the ftp site:

site:  marvin.ecn.purdue.edu [128.46.179.151]

dir:   pub/pccts/1.06/DOS_OS2.binaries

Files antlr.exe, dlg.exe, and genmk.exe are available.  These executables
work under DOS AND OS/2 and were compiled with Microsoft C 6.0.

BTW, please send a blank email message to our email server at
pccts@ecn.purdue.edu, if you have not already contacted the server, with a
Subject line of:

Subject: register

so that we may send you periodic updates, bug reports etc...

Regards,

     The Authors of The Purdue Compiler Construction Tool Set

     Terence J. Parr, parrt@ecn.purdue.edu
     Will E. Cohen,   cohenw@ecn.purdue.edu
     Henry G. Dietz,  hankd@ecn.purdue.edu
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers