HDTenEightyP/NetNews huggingface dataset:
From: franklin@caster.sps.mot.com (Malcolm Franklin)
Subject: Re: Readership
Reply-To: Malcolm_Franklin@chdasic.sps.mot.com
Organization: Motorola ASIC CAD
Distribution: comp
Date: Wed, 13 Jan 1993 00:39:58 GMT

I maintain a CAD tool to perform manufacturability checks on ASIC designs.

-- 
--------------------------------------------------------------------------------
Malcolm L. Franklin                email:   Malcolm_Franklin@chdasic.sps.mot.com
Motorola ASIC CAD                  Phone:   (602) 821-4371
CAE Systems                        Fax:     (602) 821-4963
--------------------------------------------------------------------------------
From: jeff@nsr.hp.com (Jeff Gruszynski)
Newsgroups: comp.lsi.testing
Subject: Re: Readership
Date: 12 Jan 1993 03:15:55 GMT
Organization: Hewlett Packard Santa Clara Site
Distribution: comp
NNTP-Posting-Host: hpmvd069.nsr.hp.com
X-Newsreader: TIN [version 1.1.2 PL7]

Ken Butler (kenb@dadd.ti.com) wrote:
: I'm curious about the readership of this newsgroup.  I've seen some
: postings from some universities and a few assorted other postings, but
: I'd suspect that are many more "comp.lsi.testing" readers out there.
: 
: Would people care to post their name and affiliation to the newsgroup?
: 
: Thanks.
: 
: Ken
: 
: --
: 
: *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
: Kenneth M. Butler                           (214) 917-1759 (office)
: Texas Instruments                           (214) 917-7966 (FAX)
: P.O. Box 650311 MS 3937                     kenb@dadd.ti.com
: Dallas, TX 75265
: *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*


One of the faithful here...


================================================================================
Jeff Gruszynski
Semiconductor Test Equipment
Systems Engineer
Hewlett-Packard Co
================================================================================
(415) or T 694-3381
jeff@hpmvd061.nsr.hp.com
jeff@hpuplca.nsr.hp.com
================================================================================
From: kumar@cleaver.mti.sgi.com (Kumar Venkat)
Newsgroups: comp.lsi.testing
Subject: Re: Readership
Date: 12 Jan 93 18:16:30 GMT
Organization: Silicon Graphics, Inc.



Kumar Venkat
CAD Engineer
Mips Technologies Inc.
Silicon Graphics Computer Systems

kumar@mti.sgi.com
415-390-4428
Newsgroups: comp.lsi.testing
From: rahardj@ccu.umanitoba.ca (Budi Rahardjo)
Subject: Re: Readership
Organization: University of Manitoba, Winnipeg, Canada
Date: Tue, 12 Jan 1993 01:52:16 GMT

kenb@dadd.ti.com (Ken Butler) writes:

>I'm curious about the readership of this newsgroup.  I've seen some
>postings from some universities and a few assorted other postings, but
>I'd suspect that are many more "comp.lsi.testing" readers out there.

>Would people care to post their name and affiliation to the newsgroup?

I don't know if this would do any good, but here goes ...

Budi Rahardjo
Electrical and Computer Engineering
University of Manitoba
Winnipeg, Manitoba
Canada - R3T 4W9

Now, back to ROM (Read Only Mode).
-- budi
-- 
Budi Rahardjo <Budi_Rahardjo@UManitoba.Ca>
Unix Support - Computer Services - University of Manitoba
Newsgroups: comp.lsi.testing
From: ncl@philabs.philips.com (Nai-Chi Lee)
Subject: Re: Readership
Organization: Philips Laboratories, Briarcliff Manor, NY.
Distribution: comp
Date: Tue, 12 Jan 1993 14:22:26 GMT

In article <KENB.93Jan11132835@bigears.dadd.ti.com> kenb@dadd.ti.com (Ken Butler) writes:
>
>Would people care to post their name and affiliation to the newsgroup?
>

Dr. Nai-Chi Lee					<-- don't let that scare you
Microelectronic Devices, Circuits and Systems Dept.  <-- yes we do EVERYTHING
Philips Laboratories - Briarcliff Manor, NY	<-- That's PHILIP with one L!

Hi Mom :-)
From: ncpmont@angelo.amd.com (Mark Montgomery)
Newsgroups: comp.lsi.testing
Subject: Re: Readership
Date: 12 Jan 93 18:51:26 GMT
Organization: Advanced Micro Devices, Santa Clara, CA

Mark Montgomery
MTS - Ethernet Products - Teradyne Testers
'Please Scotty, beam me up to the Pacific Northwest'

---

Mark Montgomery - Networks R' Us		| Disclaimer : Yes, it's mine!
Advanced Micro Devices, Network Products Div.	|______________________________
P.O.Box 3453, Mailstop 45			(408) 987-2368
Sunnyvale, CA. 94088				(mark.montgomery@amd.com)
Newsgroups: comp.lsi.testing
From: cseb@frodo.lfi.uni-hannover.de (Christian Sebeke)
Subject: Re: Readership
Reply-To: cseb@frodo.lfi.uni-hannover.de
Organization: Univ. Hannover, LFI, Abt. Design&Test
Date: Tue, 12 Jan 1993 09:37:54 GMT


---

Christian Sebeke, Univ. Hannover/LFI, Schneiderberg 32, D-3000 Hannover 1                             Tel: +49 511 762 5035                    sebeke@frodo.lfi.uni-hannover.de
From: dean@cbmvax.commodore.com (Jeff Dean - LSI Test)
Newsgroups: comp.lsi.testing
Subject: Re: Testing..
Date: 11 Jan 93 14:55:22 GMT
Organization: Commodore


comp.lsi.testing is for discussion of the TEST PROFESSION.
Please put your news tests elsewhere.
-- 
==============================================================================
|   |\ /|                                               Commodore Technology |
|   'O O`   Jeffrey Dean                                   1200 Wilson Drive |
|   > v <   VLSI Test and Design Assurance            West Chester, PA 19380 |
|     ^                                                   dean@commodore.com |
==============================================================================
Newsgroups: comp.lsi.testing
From: rambo@st.simbirsk.su (Alexander Kotceruba)
Subject: Re: testtest
Organization: SystemoTechnika Center, Dimitrovgrad
Date: Tue, 05 Jan 1993 08:52:56 GMT
X-Newsreader: Tin 1.1 PL4

test test
-- 
-- Alexander Kotceruba, Sistemotecnika Center, Dimitrovgrad
   rambo@st.simbirsk.su                !Voice (84-235)38901
				       !Fax   (84-235)37311

Newsgroups: comp.lsi.testing
Newsgroups: comp.lsi.testing
Subject: Re: Readership
From: michele@deis21.cineca.it (Michele Favalli)
Date: 12 Jan 93 12:41:30 +0100
Distribution: world
Organization: Dept. of Electronics, Computer Science & Systems, Univ. of Bologna, Italy

Michele Favalli

============================================================================== 

Michele Favalli 
DEIS - University of Bologna                 tel. 39-51-644-3082 
Viale Risorgimento 2                         fax. 39-51-644-3073
40136 Bologna - ITALY                        e-mail: michele@deis16.cineca.it 

==============================================================================
From: dean@cbmvax.commodore.com (Jeff Dean - LSI Test)
Newsgroups: comp.lsi.testing
Subject: Re: Testing..
Date: 11 Jan 93 14:57:36 GMT
Organization: Commodore

Newsgroup comp.lsi.testing is for discussion of issues relating to the TEST
PROFESSION.  Please take your news tests elsewhere.

==============================================================================
|   |\ /|                                               Commodore Technology |
|   'O O`   Jeffrey Dean                                   1200 Wilson Drive |
|   > v <   VLSI Test and Design Assurance            West Chester, PA 19380 |
|     ^                                                   dean@commodore.com |
==============================================================================
-- 
==============================================================================
|   |\ /|                                               Commodore Technology |
|   'O O`   Jeffrey Dean                                   1200 Wilson Drive |
|   > v <   VLSI Test and Design Assurance            West Chester, PA 19380 |
|     ^                                                   dean@commodore.com |
==============================================================================
Xref: sparky comp.lsi:764 sci.electronics:21955
From: apn@Apple.COM (Alex Novickis)
Newsgroups: comp.lsi,sci.electronics
Subject: Re: Lattice & GAL questions...
Date: 4 Jan 93 23:46:22 GMT
Followup-To: comp.lsi
Organization: Apple Computer Inc, Cupertino, CA

In article <1992Dec28.023739.9176@softwords.bc.ca> jmacphai@cue.bc.ca (James MacPhail) writes:
>Is there a Lattice Semiconductor engineer or e-mail address
>here-abouts? I'm looking for the answers to the following:
>
>What's the difference between a GAL16V8 and a GAL16V8A?
>
16v8  = 1st design
16v8a = product terms added to allow feedback paths in simple mode
16v8b = added pullups to all pins
16v8A-QP = quarter power 16v8a design

>What are the product term disable fuses useful for?
>(Other than the obvious... why are these in the architecture?
>do they alter the speed/power dissipation?)
>
YES!! They alter the power usage. Bingo. However I have yet to see a 
programmer & software package that allows you to set these. Apparently
the bottleneck is in the programmer, but I can't see why exactly.

>Why is the architecture configuration still accessible after
>programming the security fuse? It seems to me that this saves
>a few hours for the buggers off-shore (or on-shore!) that are going
>to reverse engineer my product!
Modern programmers have built-in algorithms to detect what
if the type of device you plugged-in matches the device you selected.
This is sometimes important to prevent damage to both device and
programmer.

The only time I can see this to be of significance is when you include
test vectors in your download to the programmer.

>And finally... why is the 16V8 so much cheaper than the 22V10? 
>A factor of two seems reasonable to me, but 4-6x seems excessive.
>I've been putting in two 16V8s instead of a 22V10 in most cases,
>and am happy to continue to do so, but it seems to me that there
>would be more profit for Lattice if the 22V10 came down some.
16V8 production volumes are much higher.

>
>Thanks for your time...
>
>James MacPhail  jmacphai@cue.bc.ca  james@mirg2.phy.queensu.ca

Call 1-800-fast-gal for GAL info. They usually have an engineer
type you can talk to within minutes.

Strangely, I just knew most of thes of the top of my head, and I'm
*not* associated with lattice.


-- 
Alex P. Novickis, Real Time systems demi-guru.  (W)   408-862-4541
ALINK:alex.n                                    (H)   415-691-0657
UUCP:{amdahl,claris,pyramid,sun,decwrl,well,ubvax,ames}!apn@apple.com,apn@nonvon
"I think... I think it's in my basement. Let me go upstairs and check"-Escher.
Xref: sparky comp.lsi:772 comp.lsi.cad:1282 news.answers:5149
From: TDARCOS@MCIMAIL.COM (Paul Robinson)
Newsgroups: comp.compilers
Subject: [TDR] Mixed Language Compiling
Keywords: optimize, design
Date: 8 Jan 93 02:39:38 GMT
Article-I.D.: comp.93-01-042
Reply-To: Paul Robinson <TDARCOS@MCIMAIL.COM>
Organization: Compilers Central

When I was doing programming on the Univac 90/60 series machines on VS/9,
(A mainframe with a better operating system than anything IBM has ever
made, with the identical machine code as a 360 plus some of the 370
features) it had the capability to do mixed language programming, and the
language manuals showed you how.

You could call a FORTRAN subroutine from a COBOL main program or COBOL
called program.  You could also call an assembly language program or an
assembly language program could call these.  You simply had to code the
parameters for passing arguments correctly.

The reason this worked is that IBM developed a standard calling convention
for programs written for the IBM 360 series machines: Register 13 points
to a save area to store the other registers.  Register 1 is a pointer to
the list of arguments.  Register 0 is a return value for integer return
values.  Floating point register 0 is the return value for REAL
subroutines.  Even the software that UNIVAC wrote for its IBM 360/370
clone used the same conventions as IBM software.

What was interesting is the termination code.  On a Univac 90/60, VS/9
used two supervisor calls; SVC 9 to clear all terminal and I/O buffers,
and SVC 28 to indicate program termination.  Under IBM's DOS/VSE operating
system, only SVC 14 was needed for program termination.  Something makes
me suspect the COBOL compiler was the same on both; a STOP RUN code on
VS/9 generates SVC 9 / SVC 28.  A stop run code on DOS/VSE generates SVC
14 / SVC 14.

Digital Equipment Corporation's RT11 operating system did something
similar.  Register 5 points to a list of arguments (if any), with the
hardware providing register 6 as a stack and register 7 as the Program
Counter.  So you simply passed arguments around.

When MS-DOS came out, there were no standard conventions for the passing
of arguments from one language to another.  As a result the "standards",
if any, are ad-hoc.  There is little or no standardization between
languages except on a limited level, with some compilers using the BX
register as a pointer and some using INT calls with argument lists pointed
to by anything.  There is really no standardization because the people who
designed these things had no thought to people wanting to use multiple
languages.

What does this tell us?  That we are inventing the wheel all over again,
that all the lessons painfully and expensively learned over thousands of
man-years in the mainframe programming environment are being re-learned
all over again, at significant expense, in the PC environment.

---
Paul Robinson -- TDARCOS@MCIMAIL.COM
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: davidm@questor.rational.com (David Moore)
Newsgroups: comp.compilers
Subject: Re: Code quality
Keywords: optimize, comment
Date: 6 Jan 93 19:24:21 GMT
Article-I.D.: comp.93-01-020
Reply-To: davidm@questor.rational.com (David Moore)
Organization: Rational

drw@zermelo.mit.edu (Dale R. Worley) writes:

>How important is generated code quality these days?  There are a lot of
>good optimization techniques that seem to be adequate for ordinary
>programming.  But they still are at least 10% or 20% worse than the ideal.
>Is there much of a market for another 10% in speed of generated code?

It seems to me that compile time is roughly exponential in the deficiency
of the generated code. So, to produce code that is 10% worse than optimal
takes twice as long as it does to produce code 20% less than optimal (if
your compiler is optimizer-bound). I suspect that programmer time required
to get the optimizer solid is also exponential. 

So getting that last few percent requires a lot of resources.

Perhaps someone has collected some numbers on this? I am just making the
statement based on a gut feeling gotten from writing an optimizer.
[It varies all over the place.  The Princeton/Bell Labs lcc compiler
is supposed to produce better code faster than GCC.  Ken Thompson's Plan 9
compiler is supposed to be better still in both dimensions. -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: prener@watson.ibm.com (Dan Prener)
Subject: Re: Code quality
Reply-To: prener@watson.ibm.com (Dan Prener)
Organization: IBM T.J. Watson Research Center, Hawthorne, New York
Date: Thu, 7 Jan 1993 07:51:54 GMT
Keywords: optimize

drw@zermelo.mit.edu (Dale R. Worley) writes:
> How important is generated code quality these days? ...
> Is there much of a market for another 10% in speed of generated code?

One way to look at this question is to consider the combined performance
of the compiler/processor pair as if they were a black box.  With some
plausible estimate of the rate of increase in processor speeds, your 10 -
20% speed difference corresponds to getting the black box to market
something like 2 - 4 months later.  It is still a matter of opinion as to
how much that is worth.  Surely it varies across market segments.
--
                                   Dan Prener (prener@watson.ibm.com)
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: Complex Constants in Fortran
Reply-To: jlg@cochiti.lanl.gov (J. Giles)
Organization: Los Alamos National Laboratory
Date: Mon, 4 Jan 1993 19:31:59 GMT
Keywords: Fortran, parse

uesu03@giac1.oscs.montana.edu (Lou Glassy) writes:
| [in this construct] 
|>    X = FU ( 1.0, 3.4 )     ! has to be a function call, but
|>                            ! the scanner doesn't know that...
| 
| [should the scanner return (1.0,3.4) as a constant, or should it
| instead return separate ( 1.0 , 3.4 ) tokens?]

The question addresses the distinction between a literal and a
constructor.  A literal is a lexical token which is recognized by its form
as a single data value.  A constructor is a syntactic form that builds
data objects from simpler ones.  A complex constant in Fortran is usually
treated as a constructor.  It is recognized as a parenthesized list
containing two elements and not prefixed by an array or function name.  If
Fortran had been designed with the intent to be extensible later to allow
derived types (records, structs, whatever you prefer to call them), the
design would probably have given the complex constructor a name:

      c = COMPLEX(1.2, 3.4)

instead of just a list syntax, since you can only have *one* type whose
constructor is simply a list (though obviously quaternions could have a
similar constructor with four elements, octonions with eight, etc.).
Fortran was, alas, designed before such ideas were seriously contemplated
for actual programming languages (though certainly the abstract idea of
such derived types was probably present even then).
-- 
J. Giles
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: ec_ind03@oswego.Oswego.EDU (William Jhun)
Subject: Book on Small-C
Reply-To: ec_ind03@oswego.Oswego.EDU (William Jhun)
Organization: Instructional Computing Center, SUNY at Oswego, Oswego, NY
Date: Tue, 12 Jan 1993 02:22:08 GMT
Keywords: books, C

Here is a description of "The Small-C Compiler"

It;s by James E. Hendrix by M&T Books. 
 ISBN#
  0-934375-88-7 <Book Alone>
  1-55851-007-9 <MS-DOS Disk>
  0-934375-97-6 <Book AND Disk>

This is the second edition of the Small-C Compiler Book...

It explaines the C-language in THOROUGH....and explains EVERY SINGLE 
aspect of the compiler. The book compares source code to p-code to
assembly. It goes over a nice set of optimization routines, explains the
parser, the back end, and even includes source code, which the compiler on
the DISK can actually compile itself. It's an extremely interesting book...
check it out...
--
|ec_ind03@oswego.edu           | William Jhun-P.O. BOX 346 Minetto, NY
|SUNY OSWEGO                   | 13115-0346
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: Kriss A. Hougland <hougland@enuxhb.eas.asu.edu>
Subject: Programmagle Logic Controller compilers
Reply-To: Kriss A. Hougland <hougland@enuxhb.eas.asu.edu>
Organization: Compilers Central
Date: Tue, 5 Jan 1993 07:04:19 GMT
Keywords: question

Does anyone know of any good locations/pointers to PLC (programable logic
controller) compilers.  They are usually very simple stack machines.  I'm
wondering if there are more intresting or complex compilers (or
specifications for the PLC compilers)
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: cliftonr@netcom.com (Pope Clifton)
Newsgroups: comp.compilers
Subject: Re: Another Compiler book to add to the FAQ
Keywords: books, interpreter, comment
Date: 8 Jan 93 20:48:04 GMT
Article-I.D.: comp.93-01-051
Reply-To: cliftonr@netcom.com (Pope Clifton)
Organization: Compilers Central

Paul Robinson (TDARCOS@MCIMAIL.COM) wrote:
:    Writing Interactive Compilers and Interpreters
:    by P.J. Brown
  [This is a great book, but it was published by Wiley in 1979 and is long
: out of print.  The ISBN is 0-471-27609-X.  If anyone can find a source for
: it, I'd like a copy myself. -John]

  It was reprinted as a PB in 1985.  I bought two copies then -- one for
work, and one for myself.  It's probably still long since sold out.  The
ISBN on my copy is 0-471-10072-2, so you might check under that number. 
   -- Clifton
--
cliftonr@netcom.com     Home: +1 808 521 9073  Work: +1 808 625 3234
Clifton Royston
[My bookstore says the paperback version is still available for $32.00. -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: "Saumya K. Debray" <debray@skinner.cs.uoregon.edu>
Subject: teaching compiler design: languages and texts
Reply-To: "Saumya K. Debray" <debray@skinner.cs.uoregon.edu>
Organization: Compilers Central
Date: Mon, 11 Jan 1993 20:15:57 GMT
Keywords: courses

mfeldman@seas.gwu.edu (Michael B. Feldman) writes:
> Fischer/LeBlanc is the only compiler book acknowledging Ada as a suitable
> language in which to write a compiler. 
> [...]
> In my opinion, your professor did you a disservice by requiring a book
> that (1) used Ada as the language of discourse and (b) focused on
> hand-coding a compiler, then gave you a project in which you used
> lex/yacc/C to do the actual work. That caused too much "dissonance" ...

I'm not sure why, once students have understood the algorithms involved,
the particular language used to implement them should be an issue: it
should be a straightforward matter of coding, no?  (OK, I can see that
some conceptual hurdles might be encountered if the implementation
language were massively-parallel object-oriented neural nets or whatever,
something truly weird, but come on, Pascal/C/Ada are all pretty much in
the traditional imperative language family.)  If computer science students
advanced enough to be taking compiler design courses are having trouble
reading algorithms in Ada and then implementing them in C, I'd be
concerned less about their compiler design text than about the foundations
of their CS education. 

Saumya Debray
CS Dept, University of Arizona, Tucson, AZ 85721
[temporarily at: CIS Dept, University of Oregon, Eugene, OR 97403]
debray@cs.uoregon.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: Walter Bright <bright@nazgul.uucp>
Subject: Re: IEEE arithmetic handling
Reply-To: Walter Bright <bright@nazgul.uucp>
Organization: Compilers Central
Date: Thu, 7 Jan 1993 08:10:45 GMT
Keywords: optimize, arithmetic

jim@meiko.co.uk (James Cownie) writes:
/Another area where IEEE seems never to be implemented correctly by
/compilers is in the handling of Not a Numbers (NaNs). 
/Similarly (and I've never seen this handled right in an optimising
/compilation),
/	IF (X .ne. X) THEN
/            print *,'X is a NaN'
/        ELSE
/            print *,'X is a number'

Zortech C/C++ 3.0 does implement and handle these cases correctly,
even when optimized (!)
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: Wolfgang Diestelkamp <wd@cs.tu-berlin.de>
Subject: PD scheduling environment available ?
Reply-To: Wolfgang Diestelkamp <wd@cs.tu-berlin.de>
Organization: Compilers Central
Date: Fri, 8 Jan 1993 11:00:07 GMT
Keywords: question, optimize

I'm going to implement a scheduling method that claims to be an
improvement of region scheduling, to make a comparison.

Of course I'd not like to write the whole pass (or worse a whole compiler)
from scratch; is there any public domain compiler out, that I could easily
use to make my implementation ? Ideally, I'd take a beast that already
implements region scheduling to have a basis for comparison, but I'll
appreciate any pointers.

If there's sufficient interest (and answers), I'd post the results.

Thanks

Wolfgang Diestelkamp
wd@cs.tu-berlin.de
wolfgang@first.gmd.de
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.