HDTenEightyP/NetNews huggingface dataset:
From: ynhst1@europa.ee.pitt.edu (Y. Hsieh)
Newsgroups: comp.lsi
Subject: critical delay estimators
Keywords: delay estimation
Date: 23 Jul 92 16:29:53 GMT
Reply-To: ynhst1@europa.ee.pitt.edu (Y. Hsieh)
Organization: Electrical Engineering, Univ. of Pittsburgh

Hi,

     Does anyone know of any tool that could estimate critical delay based on
extracted cmos layout.  An old tool called crystal is the only tool that I know
that estimates critical delay based on extracted layout.  Unfortunately, it 
only handles nMOS, not CMOS.  Any help would be greatly appreciated.  Thank you
in advance.

Yee-Wing Hsieh
ynhst1@ee.pitt.edu
Newsgroups: comp.lsi
From: odkahn@eos.ncsu.edu (Opher D. Kahn)
Subject: Looking for Nam-Sung Woo
Organization: North Carolina State University
Date: Tue, 28 Jul 1992 14:25:34 GMT

Does anyone have the e-mail address or phone number for Nam-Sung Woo
from AT&T Bell Laboratories, Murray Hill, N.J. ???

-- 
 Opher D. Kahn 
Xref: sparky comp.lsi:490 comp.lsi.cad:818 comp.lsi.testing:168 comp.arch:8265 biz.comp.hardware:180 comp.cad.cadence:189
From: wyle@synopsys.com (Mitch Wyle)
Newsgroups: comp.lsi,comp.lsi.cad,comp.lsi.testing,comp.arch,biz.comp.hardware,comp.cad.cadence
Subject: Synopsys info posted to biz.comp.software
Date: 24 Jul 92 02:27:16 GMT
Organization: Synopsys Inc.

I am about to post the following press information to biz.comp.software:

Subject: (Jan 24)   SYNOPSYS PORTS SYNTHESIS AND SIMULATION TOOLS
Subject: (March 16) SYNOPSYS ADDS VHDL DEBUGGING TO VHDL SYSTEM SIMULATOR
Subject: (April 13) SYNOPSYS INTEGRATES HIGH-LEVEL DESIGN TOOLS
Subject: (May 4)    SYNOPSYS INTRODUCES TEST COMPILER PLUS
Subject: (May 11)   TEXAS INSTRUMENTS ENDORSES SYNOPSYS VHDL SYSTEM SIMULATOR
Subject: (June 1)   SYNOPSYS SIGNS AGREEMENT WITH NEC ELECTRONICS INC.
Subject: (June 8)   SYNOPSYS INTRODUCES BREAKTHROUGH IN SYNTHESIS TECHNOLOGY
Subject: (June 22)  SYNOPSYS TO ACQUIRE MAJORITY INTEREST
Subject: (July 8)   Y. HIRANO NAMED PRESIDENT OF NEWLY ESTABLISHED NIHON

Synopsys Inc. develops, markets and supports high-level design automation
software for designers of integrated circuits and electronic systems.  The
Company currently offers a comprehensive set of synthesis, simulation and
test tools, which are supported on the most widely used UNIX workstations.


				-=-


Please send flames, comments, and opinions to me:

wyle@synopsys.com

Mitch Wyle                     (415) 694 4076 (work)
Synopsys Inc                   (408) 255 1848 (home)
700 E. Middlefield Rd.         (415) 965 8637 (fax)
Mountain View, CA  94043-4033  (800) 843 5669 x4076 (VoiceMail)




Requests for press releases or other marketing information can be sent to:

Lois DuBois                    lois@synopsys.com
Synopsys Inc                   (415) 694 4255
700 E. Middlefield Rd.         (415) 965 8637 (fax)
Mountain View, CA  94043-4033  (800) 843 5669 x4255
From: pakst5@gl.pitt.edu (Paul A Kwan)
Newsgroups: comp.lsi
Subject: question on Mosis Analog Run
Date: 23 Jul 92 15:52:26 GMT
Distribution: usa
Organization: University of Pittsburgh


  I have been working on a Analog BiCMOS chip, can I send it
to Mosis for an ORBIT ANALOG run ?  Or is ORBIT ANALOG just for CMOS only ?
My answer to the first question is Yes, but I am not 100% sure.

Any help is appreciated.
Thanks.

paul
From: bardo@ief-paris-sud.fr (Bardo Muller)
Newsgroups: comp.lsi
Subject: Re: 2D Network Simulation
Keywords: node elimination, multi-terminal resistance
Date: 27 Jul 92 09:59:54 GMT
Reply-To: bardo@ief-paris-sud.fr
Organization: Universite de Paris


The relevant articles are:

@article{SAK79,
	author =	{C.~M.~Sakkas},
	title =		{Potential Distribution and Multi-Terminal DC 
			Resistance Computations for LSI Technology},
	pages =		{640--651},
	journal =	{\IBMJ},
	label =		{Sak79},
	volume =	{23},
	number =	{6},
	month =		{nov},
	year =		{1979}
}

@article{MITSU87,
	author =	{T.~Mitsuhashi {et} K.~Yoshida},
	title =		{A Resistance Calculation Algorithm and Its
			Application to Circuit Extraction},
	pages =		{337--345},
	journal =	{\CAD},
	label =		{Mitsu87},
	volume =	{CAD-6},
	number =	{3},
	month =		{may},
	year =		{1987}
}


Additionally, I had the problem dealing with COMPLEX admittances. I therefore
programmed a piece of C-code operating immedeately on the nodes, without
any matrix set-up. It works semi-symbolicly and puts out a fractional representation
of the complex multi-terminal admittances. 


Bardo

___________________________________________________________________________
| Bardo MULLER                          | phone  : [33] [1] 69 41 78 50    |
| Institut d'Electronique Fondamentale  | fax    : [33] [1] 60 19 25 93    |
| Bat. 220 Universite Paris Sud         | e-mail : bardo@ief-paris-sud.fr  |
| 91405 ORSAY CEDEX FRANCE              |          THE NET WORKS !         |
|_______________________________________|__________________________________|
From: pagey@kailash.cse.iitb.ernet.in (S Pagey)
Newsgroups: comp.lsi.testing
Subject: Looking for Dr. D. A. Anderson
Date: 30 Jul 92 18:26:06 GMT
X-Unparsable-Date: Thu, 30 Jul 92 14:28:04 IST

I am looking for the address of Dr. D. A. Anderson. He has done PhD from
the University of Illinois at Urbana_champaign in 1971. In fact I am interested
in a copy of his PhD thesis entitled "Design of self-checking networks using
coding techniques". If anybody from UIUC can guide me as to whom I can contact
for this publication, that would be very helpful.
Thanks in advance.
-------------------------------------------------------------------------
Sandeep Pagey,
Dept. of Computer Sc. and Engg.,
IIT Powai,
Bombay 400 076. INDIA.
email : pagey@cse.iitb.ernet.in
-------------------------------------------------------------------------
From: haney@m.cs.uiuc.edu (Michael Haney)
Subject: 1149.1 for Xilinx FPGA's
Summary: Has anyone put 1149.1 into a Xilinx 3k FPGA?
Keywords: 1149.1 Xilinx
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Fri, 24 Jul 1992 19:39:25 GMT


Does anyone have an 1149.1 implementation for the Xilinx 3k
family that they would be willing to share?

Specifically, I am thinking about putting boundary scan into
an XC3042-based project that I am working on, and I am curious
as to how many CLB's it will cost for the controller and the
boundary cells.

I don't want to use Xilinx's configuration readout; I wish to be
JTAG compliant with other devices in the project...

Any information would be welcome.

Mike Haney
haney@cs.uiuc.edu
From: jcooley@seqp4.sequoia.com (John Cooley)
Newsgroups: comp.lsi.testing
Subject: Re: DTMF Decoder Project
Date: 23 Jul 92 15:19:13 GMT
Organization: Sequoia Systems Inc., Marlboro, Mass.


> From: shing@spot.colorado.edu (Shing Pui-Shum Benson)
>
> Okay, does this sound complicated yet?  Let me show you what I want remapped:
>  
>  _         _    _         _         _    _    _                    _
> | |    |   _|   _|  |_|  |_   |_     |  |_|  |_|   _    _   |_|   |_  |_
> |_|    |  |_    _|    |   _|  |_|    |  |_|    |  |_    _|         _  |_  blank
>  
> 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111
>            _    _         _         _    _    _    _              _         _
>  _|    |   _|   _|  |_|  |_   |_     |  |_|  |_|  | |   _    _   |_|  |_   |
> |_|    |  |_    _|    |   _|  |_|    |  |_|    |  |_|   _|  |_   | |  |_|  |_
>  
> How's that?  I was thinking of screwing with a bunck of AND, OR, NAND and NOR
> gates to help me with this IF-THEN type of remapping, but maybe someone else
> has a better idea (aside from "SCRAP IT!" and "GIVE UP" :)
>  
> Any and all replies appreciated...
>  
>                 Shing


Shing,

	This is not an especially challenging task for any engineering
type person to solve.  (You'll probably find an optimized and completely
detailed solution to this if you just walked into your school's EE Department
- most Sophmore or Juniors are knowledgeable enough to not botch something
as simple as this up!)

	But what they may miss is that you've defined your "6" and "b"
to look exactly alike!
					- John Cooley
					  ASIC Designer & CAE Grunt

===========================================================================
Trapped trying to figure out a Synopsys bug?  Want to hear how others dealt
with it ?  Join the E-Mail Synopsys Users Group!  To join, E-mail me today! 
===========================================================================
     !!!     "It's not a BUG,    |           jcooley@sequoia.com
    /o o\  /  it's a FEATURE!"   |         jcooley@sds.sequoia.com
   (  >  )                       |        "Yes, We make trees here!"
    \ - /       |
    _] [_       |        "This here ain't no one's opinion 'cept my own."
Newsgroups: comp.lsi.testing
From: schuppan@infotech.tu-chemnitz.de (Holger Schuppan)
Subject: Wanted: Documentation on Algotronix CAL
Organization: University of Technology Chemnitz, FRG
Date: Thu, 30 Jul 1992 09:54:56 GMT


Dear netters,
I'm looking for documentations on Algotronix CAL chips, 
including some information about development tools, prices
and addresses of distributors.
Any pointers are very welcome.
Thanks in advance,
 Holger 
	  email : schuppan@infotech.tu-chemnitz.de

	  address:  Holger Schuppan
		    neuroTECH GmbH
		    Ruhrorter Str. 9
		    D-W-4200 Oberhausen 1
From: hv@csi.forth.gr (Vagelis Halkiadakis)
Newsgroups: comp.lsi.testing
Subject: Wanted: Oppinions for Fault Simulation Tools
Keywords: fault analysis, fault simulation
Date: 30 Jul 92 15:49:51 GMT
Distribution: comp.lsi.testing

Dear Netters,
I would like to have your opinions about fault simulation
tools that you might have used (as well as aproximate
list prices if available).

Particularly I'm intrested in the following:
VERIFAULT (CADENCE)
STATGRADE (  ===  )
TESTGRADE (  ===  )
QUICKFAULT (MENTOR)
QUICKGRADE (  ==  )
but any opinion about other tool is also welcome.

Please answer by e-mail if possible.

Thanks in advance,
Vagelis Chalkiadakis  			email: vhal@intranet.gr
VLSI Project Coordinator		       hv@csi.forth.gr
Development Programmes Dept.
Intracom S.A.
Athens - GREECE
Newsgroups: comp.lsi.testing
From: g3uasg@tenore.fnma.com (Al S. Ghandchi)
Subject: Re: m
Organization: Fannie Mae, Washington, DC
Date: Tue, 21 Jul 1992 14:26:27 GMT


Just a Test !!!
Newsgroups: comp.lsi,comp.ai.neural-nets
From: harry@neuron6.jpl.nasa.gov (Harry Langenbacher)
Subject: analog neural-net hardware engineer WANTED
Organization: JPL Pasadena CA
Date: Thu, 23 Jul 1992 19:42:24 GMT



We have a job opening for an engineer with neural-net and VLSI design
experience - MS/PHD or equivalent experience.

We currently work with (analog, digital, and optical) neural net
and concurrent processing devices and hardware systems. We build special-
purpose and general-purpose analog, digital, mixed-signal, and
opto-electronic chips. We develop neural net algorithms that suit our
applications and our hardware.

For over 7 years we have been a leader in hardware neural nets .

If you're interested, please get in touch with me.
-- 
Harry Langenbacher 818-354-9513 harry%neuron6@jpl-mil.jpl.nasa.gov
Concurrent Processing Devices Group, FAX 818-393-4540
JPL,  M/S 302-231, 4800 Oak Grove Dr, Pasadena CA 91109        USA
From: pagey@kailash.cse.iitb.ernet.in (S Pagey)
Newsgroups: comp.lsi
Subject: Looking for Dr. D. A. Anderson
Date: 30 Jul 92 18:25:45 GMT
X-Unparsable-Date: Thu, 30 Jul 92 14:26:56 IST

I am looking for the address of Dr. D. A. Anderson. He has done PhD from
the University of Illinois at Urbana_champaign in 1971. In fact I am interested
in a copy of his PhD thesis entitled "Design of self-checking networks using
coding techniques". If anybody from UIUC can guide me as to whom I can contact
for this publication, that would be very helpful.
Thanks in advance.
-------------------------------------------------------------------------
Sandeep Pagey,
Dept. of Computer Sc. and Engg.,
IIT Powai,
Bombay 400 076. INDIA.
email : pagey@cse.iitb.ernet.in
-------------------------------------------------------------------------
Newsgroups: comp.lsi
From: sdh@uicc.com (sheldon haynie)
Subject: Semiconductor Manufacturing Equipment Interface (SECS) Code
Summary: looking for SECS-II Code 
Keywords: SECS data collection 
Organization: Unitrode Integrated Circuits Corp., Merrimack, NH
Date: Tue, 28 Jul 1992 12:12:07 GMT

If any one has a lead on pre-written code for SECS-II implementation,
please e-mail me, (I'll post if enough interest). We are looking to 
hookup data collection tools such as Nanospecs, OSI, Tencors etc.

The Grapheq package from Bayliss Automation is all that we have found
so far, and it is rather expensive for a toolkit. ($25k US)

thanks

Sheldon Haynie		|
Unitrode IC Corp	|( this space for rent)
7 Continental Blvd.	|
Merrimack, NH 03054	|
FAX:603-424-3460	|voice:603-424-2410 (EST)|	sdh@procad.uicc.com
******************************************************************************
From: macrakis@osf.org (Stavros Macrakis)
Subject: Re: Software address translation - request for info
Reply-To: macrakis@osf.org (Stavros Macrakis)
Organization: OSF Research Institute
Date: Thu, 30 Jul 1992 21:38:56 GMT
Keywords: architecture

phjk@doc.imperial.ac.uk (Paul H J Kelly) writes:

   We need a way of applying a non-trivial mapping to every data address
   issued by a C program....:

    1) Post-process the assembler and intercept all loads and store
       instructions.

A bad idea because you lose all the compiler's common-subexpression
elimination and arithmetic simplifications (which should buy you a lot in
this case).  But probably the easiest and most reliable on a load-store
(RISC) architecture (where you don't have to decompile addressing modes
etc.).  Don't forget computed jump addresses.

    2) modify the back end of a retargetable compiler (e.g. gcc) to
       generate C instead of assembler, so we can then redefine
       a couple of macros used in the generated C to change the mapping,

Huh?  Why generate C?  Anyway, doesn't work in general because the
compiler may generate loads and stores that aren't visible to the user
(e.g. register saving over procedure calls).  On the other hand, if you
can avoid doing address translation on stack addresses, perhaps this will
work.

    3) Write a front-end preprocessor, which modifies the C concrete or
       abstract syntax to introduce the mapping,

Same problem as solution (2).  If what you really want is this address
mapping facility ONLY on (so-called) static variables, then the best
solution is probably this preprocessor.  In fact, you may be able to
rewrite the static variables as macros (depending on what you do with
them).

    4) Run standard binary as emitted by the C compiler, under a
       simulator (e.g. spim) - then modify spim to perform address 
       translation.

This will work fine, but will be very slow of course.

By the way, don't forget that ALL your libraries (including invisible ones
like will also need to be recompiled or rewritten (if assembler).

Some other solutions:

5) Do a transformation at intermediate-language level.  Again, you run the
risk of `invisible' compiler operations coming in later (depending on the
exact operation of the compiler and what you're doing about the stack).

6) Rewrite the back end.  Probably the best solution....

By the way, you mention that addresses might change during execution.  In
that case, your address calculations have to be done `safely' and can't be
optimized away.  Probably solution (1) is best in this case, but you still
need some way of guaranteeing that the address doesn't change halfway
through an address calculation....

	-s
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: moss@cs.umass.edu (Eliot Moss)
Subject: Re: Pros and cons of high-level intermediate languages
Reply-To: moss@cs.umass.edu (Eliot Moss)
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
Date: Thu, 30 Jul 1992 00:08:32 GMT
Keywords: C, storage

graham@maths.su.oz.au (Graham Matthews) said:

> (Hans Boehm) writes:
>>a) (the one I'd personally most like to see fixed) The treatment of 
>>source languages that require garbage collection is tricky.

> I am not sure I understand what you are talking about here Hans.  As
> far as I can see if the C code you produce is not safe in the presence
> of garbage collection then you are generating incorrect C code. There
> is nothing in C that makes it "garbage collection unsafe" even with a
> non-conservative garbage collection.

Suppose we have something like the following code:

	int *p, *q;
	int i;
	for (i = 0; i < 100; i++)
	   p[i] = q[i];

Since C compilers are generally written assuming that allocated things do
not move during execution, we might get code like this for a machine
supporting two index registers in an addressing mode:

	ld rp,p		; rp <- p
	addi rl,rp,400	; rl <- p + 100 * 4  (4 byte integers)
	ld rq,q		; rq <- q
	sub rq,rq,rp	; rq <- rq - rp
label:	ld rx,0(rp,0)	; rx <- p[i]
	st rx,0(rp,rq)	; q[i] <- rx
	addi rp,rp,4	; rp <- rp + 4
	blt rp,rl,label	; loop if rp < rl (rl = the limit)

This appears to be perfectly legal code, yet it is possible that no
pointer to q exists, and we might gc (you might argue not in this case,
but I can add a call in the loop or something and fix that, or we can say
there are multiple threads and another thread causes gc).

This is the kind of subtle transformation that Hans was referring to. Note
that the transformation here improves performance by reducing the number
of items that need to be kept in registers from 3 (i, p, q) to 2 (p and
q-p) and requires only one increment around the loop. Strength reduction
and induction variable elimination definitely head this way.
--
		J. Eliot B. Moss, Associate Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.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: rbe@yrloc.ipsa.reuter.com (Robert Bernecky)
Subject: vector intermediate languages
Reply-To: rbe@yrloc.ipsa.reuter.com (Robert Bernecky)
Organization: Compilers Central
Date: Wed, 29 Jul 1992 17:41:39 GMT
Keywords: translator, vector, question

Since IL's seem to be in vogue in this group lately:

I'm looking for references to Vector or Array intermediate languages,
and retargetable code generators using such ILs. The immediate application
is compilers for APL and J.

Thanks. Bob

Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: antel!ernst@texsun.com (Daniel J. Ernst)
Newsgroups: comp.compilers
Subject: Cygnus tools?
Keywords: question
Date: 24 Jul 92 19:31:50 GMT
Reply-To: antel!ernst@texsun.com (Daniel J. Ernst)
Organization: Compilers Central

I am currently evaluating cross compilers/assemblers/linkers/loaders for
the Motorola 68040 and the rest of the 68k family. 

One company I am considering is Cygnus.  They provide support and maintenance 
for their GNU derived C software development tools.

I would be grateful if anyone in internetland that has dealt with Cygnus
and their products would mind sending me email detailing their thoughts
and experiences.  I am interested in their level of support and
responsiveness as well as the quality of their tools.

Please email responses to "antel!ernst@texsun.com". I do not have direct
access to internet news groups.

I will summarize results and post if there is adequate feedback.

Thanks,

Dan
--
Daniel J. Ernst
AnTeL, Inc.
625 Digital Drive
Suite 107
Plano, Texas 75075
Phone: (214) 867-9000 Ext. 17
FAX: (214) 867-0897
email: antel!ernst@texsun.com

-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: moss@cs.umass.edu (Eliot Moss)
Newsgroups: comp.compilers
Subject: Re: berkeley yacc on DOS
Keywords: yacc, MSDOS
Date: 21 Jul 92 13:25:58 GMT
Article-I.D.: comp.92-07-066
Reply-To: moss@cs.umass.edu (Eliot Moss)
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)

Jim pointed out problems porting yacc to DOS because of 16 bit integers,
limits of 64K bytes in malloc, etc. I don't know exactly when we should
declare pre-386 machines dead, but when we can, we can use 32 bit flat
addressing models for porting such programs, as has been done for GNU
emacs, gcc, bison, TeX/LaTeX, dvips, ghostscript, etc. Some of these have
non-386 versions, but some notably do not, and the 386 versions are
generally faster and offer more capacity since they breakthe 640K bytes
barrier. Anyway, if people want a yacc for DOS and they have 386 or 486
machines, I suggest bison.
--
		J. Eliot B. Moss, Associate Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: graham@maths.su.oz.au (Graham Matthews)
Newsgroups: comp.compilers
Subject: Re: Pros and cons of high-level intermediate languages
Keywords: C, translator
Date: 24 Jul 92 01:19:05 GMT
Reply-To: graham@maths.su.oz.au (Graham Matthews)
Organization: Sydney University Computing Service, Sydney, NSW, Australia

(Olivier Ridoux) writes:
>d) There is no first-class label data-type.  One can neither store and
>read labels, nor goto stored labels.  

I think you will find that gcc 2.X allows you to have arrays of labels.
Any gcc experts out there to confirm this?

As to high-level intermediate languages the biggest problem I see is
making sure that the user gets meaningful errors. On many languages I have
used that translate into C one gets C compiler error messages at times as
part of the language level error messages. YUK!

graham
--
Graham Matthews
Pure Math, Uni.Sydney, Oz
graham@maths.su.oz.au
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.compilers
Subject: Lisp and Func. Programming bibliography
Keywords: bibliography, FTP
Date: 29 Jul 92 20:35:56 GMT
Reply-To: John R. Levine <johnl@iecc.cambridge.ma.us>
Organization: Compilers Central

Dave Mason <dmason@plg.uwaterloo.ca> and Gord Vreugdenhil
<gvreugde@plg.uwaterloo.ca> have contributed a bibtex bibliography of the
Conference Record of the 1992 ACM Symposium on Lisp and Functional
Programming for the compilers archives.  It'll be in the FTP archive as
lfp92-bib.Z, the mail server as lfp92-bib.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl

-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.