HDTenEightyP/NetNews huggingface dataset:
From: dattier@ddsw1.mcs.com (David W. Tamkin)
Subject: Re: How do we include a "|" in vi macros ??
Keywords: vi, macros, special characters
Organization: Contributor Account at ddsw1, Chicago, Illinois  60657
Date: Tue, 1 Sep 1992 05:22:56 GMT
X-Disclaimer:  Material posted in this article is the sole responsibility of
                the poster and does not represent MCSNet or the system owners.

mschee@bcarh600.bnr.ca (Michael SamChee) wrote in
<1992Aug31.185656.12365@bnr.ca>:

| Does anyone know how one can include the pipe character "|" in a vi macro?

This ought to be in a vi FAQ.

| eg. map ^A :!exec cat tmp | more

Quote it with a hard ctrl-V; in other words, type ctrl-V *twice* in front of
the pipe symbol so that one hard ctrl-V stays in the macro definition.

map ^A :!exec cat tmp ^V| more

David W. Tamkin   Box 59297   Northtown Station, Illinois  60659-0297
dattier@ddsw1.mcs.com    CompuServe: 73720,1570    MCI Mail: 426-1818
Newsgroups: su.vaxhax,apple.general,comp.editors
From: qtdaw@tacom-emh1.army.mil (David Walters)
Subject: Re: vi help
Organization: U.S. Army Tank Automotive Command (TACOM)
Distribution: ba
Date: Tue, 1 Sep 1992 19:04:13 GMT


David Walters
TACOM

Newsgroups: comp.editors
From: it1@ra.msstate.edu (Tim Tsai)
Subject: Re: VI for the PC
Organization: Mississippi State University
Date: Sat, 29 Aug 1992 01:06:23 GMT

pgf@cayman.COM (Paul Fox) writes:
>Or vile -- at ftp.cayman.com, in pub/vile

  Anybody know how to change vile to use 25 lines on a PC?  I browsed
through the source but couldn't find any variable settings that
affects the # of lines..  Thanks.
From: speri@cactus.org (Sankarappan Periyasamy)
Subject: Re: VI for the PC
Organization: Capital Area Central Texas UNIX Society, Austin, Tx
Date: Fri, 28 Aug 1992 17:57:38 GMT

In article <1992Aug27.012645.11837@ucunix.san.uc.edu> theobald@ucunix.san.uc.edu (Allen M. Theobald) writes:
>Hello Netters!
>
>Does anyone know anything about vi editors for the
>ibm-pc??  I'm looking for a good one (any really),
>and thought this would be the place to start.
>
>These are the ones i've found:
>
>	Oak-Hill's VI (kinda slow)
>
>	Stevie (can't compile)
>
>Any opinions on these would also be appreciated...

Try elvis, which is availbale on simtel.  It is better than many other vi's
for DOS.

- Peri.

-- 
S. Periyasamy                     *  Phone  : 512-990-9116 * Off : 512-838-3482
1915, Wells Branch Pkwy, #607     *  E-Mail : speri@cactus.org * Off : speri%cd
Austin, TX - 78728.               *        s.austin.ibm.com@ibmpa.awdpa.ibm.com
-- 
S. Periyasamy                     *  Phone  : 512-990-9116 * Off : 512-838-3482
1915, Wells Branch Pkwy, #607     *  E-Mail : speri@cactus.org * Off : speri%cd
Austin, TX - 78728.               *        s.austin.ibm.com@ibmpa.awdpa.ibm.com
From: takefuji@donald.EEAP.CWRU.Edu (Yoshiyasu Takefuji)
Newsgroups: comp.internet.library
Subject: Re: Looking for the ftp site of previous postings
Date: 1 Sep 1992 13:32:42 GMT
Organization: Dept. of Electrical Engineering, CWRU, Cleve. OH
NNTP-Posting-Host: donald.eeap.cwru.edu

From newsuser@lth.se Tue Sep  1 03:11:37 1992
From: anders@dit.lth.se (Anders Ardo)
Subject: Re: Looking for the ftp site of previous postings

I am archiving comp.internet.library in a WAIS-database.

About WAIS:
The Wide Area Information Server (WAIS) Project is an experiment,
automating the search and retrieval of many types of electronic information
over wide area networks. More info and programs are available by anonymous ftp
from ftp.think.com in directory wais.

Have fun,     Anders

anders@munin.ub2.lu.se


Here is the .src-file for my server:


(:source
   :version  3
   :ip-address "130.235.162.11"
   :ip-name "munin.ub2.lu.se"
   :tcp-port 210
   :database-name "comp.internet.library"
   :cost 0.00
   :cost-unit :free
   :maintainer "anders@munin.ub2.lu.se"
   :description "Server created with WAIS rel. 8 b5 DRI 1 on Aug 30 19:03:35 199
2 by anders@munin.ub2.lu.se
Index of the newsgroup comp.internet.library
Discussing electronic libraries.
"
)
Newsgroups: comp.internet.library
From: takefuji@donald.EEAP.CWRU.Edu (Yoshiyasu Takefuji)
Subject: letters.8-28-92
Organization: Dept. of Electrical Engineering, CWRU, Cleve. OH
Date: Fri, 28 Aug 92 15:10:30 GMT

From yman@cabsav.vut.edu.au Thu Aug 27 19:55:42 1992
Subject: internet.library
From: Y. M. NG <yman@cabsav.vut.edu.au>

Please add the following to your list

Victoria University of Technology
        zebra.vut.edu.au (140.159.1.46)
Login as user:library


From clarke.stevens@gtri.gatech.edu Thu Aug 27 17:38 EDT 1992
From: clarke.stevens@gtri.gatech.edu (Clarke Stevens)
Subject: Library access

Are any of the libraries in your list available via mailservers?  In other
words, can I send a mail message with a subject, author, etc and get a list
of matching titles sent back to me?

Thanks,
Clarke
From: takefuji@donald.EEAP.CWRU.Edu (Yoshiyasu Takefuji)
Newsgroups: comp.internet.library
Subject: a NEW, IMPROVED Ada Repository!
Date: 3 Sep 1992 13:39:19 GMT
Organization: Dept. of Electrical Engineering, CWRU, Cleve. OH
NNTP-Posting-Host: donald.eeap.cwru.edu

From news@cs.wvu.wvnet.edu Thu Sep  3 09:05:43 1992
From: gunawan@cs.wvu.wvnet.edu (Margaretha W. Gunawan)
Subject: a NEW, IMPROVED Ada Repository!


AdaNET is a FREE to public Ada repository.  It contains a comprehensive
collection of information about all aspects of software engineering,
as well as an extensive collection of public domain software development
efforts.

AdaNET Service Version 3 (ASV3) uses the NASA Electronic Library System
(NELS 1.2) for the library mechanism.  Two user interfaces are available:

     - ASCII Interface: only requires a terminal/PC with a 1200 baud (or
                        higher) modem.  The most similar to the current
                        ASV2.
     - X Interface    : requires a high level PC (X windows capable),
                        a Mac or X terminal with high speed
                        telecommunication capabilities.

ASV3 will be available September 21st!

If you are interested in obtaining a free ASV3 account, please either:
     - call AdaNET Client Service (800) 444-1458
or   - reply to me and include your address, so we can send you
       an application.
Newsgroups: comp.internet.library
From: takefuji@donald.EEAP.CWRU.Edu (Yoshiyasu Takefuji)
Subject: Looking for the ftp site of previous postings
Organization: Dept. of Electrical Engineering, CWRU, Cleve. OH
Date: Mon, 31 Aug 92 21:18:25 GMT

From levie@dutiws.TWI.TUDelft.NL Mon Aug 31 08:32:19 1992
From: levie@dutiws.TWI.TUDelft.NL (M.Levie.TA-tel-7230)
Subject: Looking for the ftp site of previous postings

Hi,

I'm looking for the ftp-site that has all the postings of this newsgroup.
If someone knows where it is, please contact me via e-mail.

Thanks,

M. Levie

levie@dutiws.twi.tudelft.nl
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: Configurable/Switchable Endianess
Date: 29 Aug 92 23:48:54 GMT
Article-I.D.: cbmvax.34741
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Distribution: comp
Organization: Commodore, West Chester, PA

>>I am interested in microprocessors that are able to execute code, or
>>process data in either endianness, and how they achieve this. 
>> The ATT Hobbit has switchable data
>>endianness (how do you switch ?), does this mean that the endianess of
>>code is fixed ? Does anyone implement a "load data of the other
>>endianness instruction" ?

	When implementing the RPM-40, we discussed this, and basically the
only difference as far as we were concerned was the word/byte alignment
module that takes data from the bus and throws it into registers.  Just
implement 2 of them and switch between them as needed, either by pin,
register bit, or instruction.

	The amusing thing I noticed was that the chip designers tended to
use little-endian without thinking, and didn't really care much, while the
software guys cared a lot (and wanted big-endian).  I have a pet theory (almost
undoubtably wrong) about this:  chip designers rarely look at memory dumps
or displays; most of their interaction with memory was drawing memory arrays
on paper and whiteboard.  When drawing, they tended to put 0 at the bottom
right, while the software people (used to looking at memory print on a screen)
put 0 at upper left.  The difference in those two diagrams is basically the
difference between little-endian and big-endian (assuming you read it from
left to right, as most people do).

	Yeah, I know, it's wrong, half-baked, etc.  _Please_ no endian wars,
it was meant to be amusing, not restart old battles.

-- 
"Rev on the redline, you're on your own; seems like a lifetime, but soon it's
 gone..."  Foreigner
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
From: beadle@cc.uow.edu.au (henry beadle)
Newsgroups: comp.arch
Subject: looking fror isp simulator
Summary: looking for an isp simulator I can use for undergraduate teaching
Keywords: isp pms architecture simulator
Date: 26 Aug 92 01:56:47 GMT
Organization: University Of Wollongong

I'm looking for an PMS/ISP simulator I can use as part of an undergraduate
computer architecture course. Ideally it should run on a PC or Macintosh
though Unix is also possible.

If anyone knows where I could get one, or has used and can recomend one please
e-mail me and I will summarise the responses.

Peter
-- 
Peter Beadle
Electrical and Computer Engineering
The University of Wollongong
Locked Bag 8844, South Coast Mail Centre, NSW. 2521, AUSTRALIA
Newsgroups: comp.arch
From: dzoey@frob.eng.umd.edu (Joseph Herman)
Subject: Re: Indexing in microprocessors
Date: Thu, 03 Sep 92 01:05:58 GMT
Organization: /homes/dzoey/.organization

In article <BtxGvn.8MH@pix.com> stripes@pix.com (Josh Osborne) writes:
   In article <1811llINN3ci@usenet.INS.CWRU.Edu> ugurdag@ces.cwru.edu (Fatih Ugurdag) writes:
   >Is there any microprocessor in which we can access registers in an
   >indexed fashion such as      [...]

   National Semi's HPC microcontrollers can do this.  You can address
   any section of memory, even the registers.  If you address the registers
   as memory you take a performance hit though.


	Joe Herman

dzoey@terminus.umd.edu




--
"Everything is wonderful until you know something about it."
From: iwm@doc.ic.ac.uk (Ian W Moor)
Newsgroups: comp.arch
Subject: Re: OS/MFT and Macintosh (was: ..History)
Date: 27 Aug 92 12:31:11 GMT
Reply-To: iwm@doc.ic.ac.uk (Ian W Moor)
Organization: Department Of Computing, Imperial College, London UK
NNTP-Posting-Host: swan.doc.ic.ac.uk


In article <1992Aug26.150429.462@sctc.com>, smith@sctc.com (Rick Smith) writes:
|> pcg@aber.ac.uk (Piercarlo Grandi) writes:
|> 
|> >Hey, the Mac OS technology is middle sixties vintage
|> >(OS/MFT!),
|> 
|> As a point of fact, OS/MFT's operating system technology bears almost
|> resemblance to the Mac OS. OS/MFT provided a "flat" file system. OS/MFT
|> provided a _fixed_ number of concurrently active tasks, while the Mac
|> OS is limited by the available memory (at least in my experience).
The earlier versions of the Mac system had a flat filesystem, even with 
folders, file names were global, and only one task could run at a time
(remember switcher?).
     Ian W. Moor 
iwm@doc.ic.ac.uk   Department of Computing, Imperial College.            
                   180 Queensgate London SW7 UK.               
"Experts from BNFL have advised the Russians to rename Chernobyl as Sellograd
 and open a tourist centre"
Newsgroups: comp.arch
From: phil@news.ccutah.edu (Phillip Neiswanger)
Subject: Question on ISCA proceedings...
Organization: University of Utah Computer Center
X-Newsreader: Tin 1.1 PL3
Date: Thu, 27 Aug 92 21:14:05 GMT

Hi,

I'm interested in obtaining copies of the proceedings of The International
Symposium on Computer Architecture for variuos years.  I have a 1988 copy
and it lists a number of ground mail addresses I can use.  Here are two of
them.

	IEEE Service Center		ACM
	445 Hoes Lane			Order Department
	P.O. Box 1331			P.O. Box 64145
	Picataway, NJ 08855-1331	Baltimore, MD 21264

Are these valid addresses still?  Do either have email address which I may
use?

Thanks for your time.

Note:	For those of you about to email me, please note that the email
	address where this message came from may not work.  I suggest
	using the "csulx" address listed below.

				CYA
				Phil
				email:	phil@csulx.weber.edu
					phil@icarus.weber.edu
From: akhiani@ricks.enet.dec.com (Homayoon Akhiani)
Newsgroups: comp.arch
Subject: Re: trapping speculative ops
Date: 26 Aug 92 15:35:28 GMT
Reply-To: akhiani@ricks.enet.dec.com (Homayoon Akhiani)
Organization: Digital Equipment Corporation



In article <BtEzrK.Jso.2@cs.cmu.edu>, lindsay+@cs.cmu.edu (Donald Lindsay) writes:
|>From: lindsay+@cs.cmu.edu (Donald Lindsay)
|>Newsgroups: comp.arch
|>Subject: Re: trapping speculative ops
|>
...........................
|>
|>But this is just a specific optimization. The broader question is,
|>waht about traps while executing speculatively? There seem to be two
|>answers:
|>
|>1) Let the hardware do all the speculative execution. This puts it on
|>the hardware's head to not trap until it knows it really should have.
|>
|>2) Allow compiled code a way to postpone consequences until it
|>wants to know. This covers e.g.
|>
|>	if( b != 0 ) c = a/b;
|>
|>and an assortment of other cases.
|>
|>The problem with (1) is that it makes for complex hardware. The
|>problem with (2) is that instruction sets are generally not set
|>up to allow such leeway.
|>-- 
|>Don		D.C.Lindsay 	Carnegie Mellon Computer Science
|>

I believe that there is a 3rd option:
 3) Hardware has Trap Status and Control register
    Using the control resgister, Software will disable all traps.
    So when a exception rises, the hardware will not trap, it will update the
    "Status Register" and follows the normal execution path.

    At a point that Software decided to use the result of the "Speculative"
    flow, Software will read the "Status Register" and if the Status for 
    the chosing flow had no trap in it, the bingo! 
 
    example:
	
        if(z)      c = a/b;  
	else	   c = a/d;    
	(Note that since traps are disabled there is no need for if(b!=0))
	
	Can be executed as follow:
	
	tmp1 = a/b
	tmp2 = a/d
	if(z) {Check status on tmp1, if nothing bad then c = tmp1; 
	else  {Check status on tmp2, if nothing bad then c = tmp2;      

    If we have 2 divider units, we can start both division at the same time.
    Therefore, if z==1 then we simply ignore the result and traps on a/d 
    calcaulation.



--
-------------------------------------------------------------------------------
Homayoon Akhiani                               "Turning Ideas into ... Reality"
Digital Equipment Corporation                       
77 Reed Rd. Hudson, MA 01701            "All Rights Reserved. Copyright(c)1992"
Email: akhiani@ricks.enet.dec.com     "The words are mine, and not my employer"
-------------------------------------------------------------------------------
From: mjohnson@netcom.Netcom.COM (Mark Johnson)
Newsgroups: comp.arch
Subject: Re: ALPHA : Single Transistor Clocking
Date: 3 Sep 92 02:53:09 GMT
Organization: Netcom Online Communications Service

In article <1992Sep3.004732.15291@rkna50.riken.go.jp> wong@rkna50.riken.go.jp (Wong Weng Fai) writes:
   >According to what I know, right dead center of the
   >ALPHA chip is a single, huge transistor that is used
   >for clock distribution. 
   >What are the advantages and disadvantages ?
   >Is it the way to go for distribution of high
   >frequency clocks ?

Have a look at the Alpha technical paper in the 1992 Digest
of Technical Papers of the International Solid-State Circuits
Conference ("ISSCC"), and also the Slide Supplement.

The clock distribution network forms a stripe from
top to bottom, about 1/3 of the way of the left edge
(if you orient the photo the same way I did).

There are definitely more than one transistor in this
stripe; see the figures in the paper for a circuit
topology.  In fact, I would be very surprised to learn
of any microprocessor whose onchip clock was generated
by a single transistor; in the standard circuit style
a lower bound would be two transistors, one to drive the
clock's load to logic-1, and another to drive the load
to logic-0.

"Is this the way to go?" --- depends on who you ask
and what research or design community they represent.
    If you ask the question in Hudson, MA ...... "yes"
    If you ask the question in Pasadena, CA .... "no"

  --mj
From: sites@sousa.ltn.dec.com (Dick Sites)
Newsgroups: comp.arch
Subject: Re: 32 => 64 Transition
Date: 4 Sep 92 18:38:22 GMT
Reply-To: sites@sousa.ltn.dec.com (Dick Sites)
Organization: Digital Equipment Corporation, Littleton MA


Marc writes:
>> Either the compiler always clears the high order bits of short values
>> in registers (the performance hit) or produces inconsistent results.

For a canonical sign-extended 32-bit value in a 64-bit register (to avoid a separate set of 32-bit branches, among other things), change "clears" to "foreces to all-0/all-1 on 32-bit overflow". This is in fact a tight timing path, but not the final cycle time limiter in the Alpha 21064 chip. So, with some design care, there need not be either a performance hit or inconsistent results. For this to work, 32-bit operations must check for 32-bit overflow, not 64-bit overflow. Hi, Marc. 
--
	Dick Sites, who does not speak for Digital, but knows a little about
	Alpha. :-)    sites@tallis.enet.dec.com
Newsgroups: comp.arch
From: bernie@metapro.DIALix.oz.au (Bernd Felsche)
Subject: Re: Program behaviour (was Re: trapping speculative ops
Organization: MetaPro Systems, Perth, Western Australia
Date: Tue, 1 Sep 92 08:40:06 GMT

jesup@cbmvax.commodore.com (Randell Jesup) writes:

>bbs.dennis@tsoft.sf-bay.org (Dennis Yelle) writes:
>>schow@bqneh3.bnr.ca (Stanley T.H. Chow) writes:
>>> Some people (including me), believe that there is only *one* level
>>> of optimization. One should always ship the same binary that one
>>> tested; 

>>I agree.  This is why I am annoyed that most linkers put the
>>debug information in the executable file.  I think that the
>>debug information should be put in a different file (ending with .dbg
>>perhaps).  Then I could test, debug, and ship EXACTLY the same binary.

>	However, adding some types of debug information can modify the 
>generated code, so you have to be careful about it (know your linker/
>compiler/debugger and it's habits).  Good linkers have the ability to
>strip debug information out of an executable for shipping, without modifying
>the code you debugged.

There are some commercial compilers/linkers which always
generate the same code, independent of any debug option.

They typically write out a .dbg file which allows you to
debug optimised code, and you can be sure that the optimised
version which you ship actually works -- or you can find the
problem caused by the compiler optimisation. There is no
subsequent need to strip out debug info, and depending on
the linker/compiler, the symbol table information.

The .dbg file contains pointers into the executeable code.
A special debugger is of course required.

Can you suggest what sort of debug info would need to be 
in the binary?
-- 
+-----+ Bernd Felsche                     _--_|\  #include <std/disclaimer.h>
| | | | MetaPro Systems Pty Ltd          /      \ bernie@metapro.DIALix.oz.au
| | | | 328 Albany Highway,              X_.--._/         Fax: +61 9 472 3337
|m|p|s| Victoria Park, Western Australia 6100  v        Phone: +61 9 362 9355
From: haddad@pa.dec.com (Ramsey Haddad)
Newsgroups: comp.arch
Subject: Re: Interrupts vs Polling---WAS: cooling
Date: 28 Aug 92 17:33:40 GMT
Article-I.D.: PA.1992Aug28.173340.3576
Organization: DEC Western Research Lab, Palo Alto, CA

In article <BtIDsH.8x3@exnet.co.uk> dhd@exnet.co.uk (Damon) writes:
>In article <BtEy50.Ix4.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>>Close to the truth. High-reliability systems (and high priced
>>systems) can justify computer monitoring to detect e.g. a failed fan.
>>Aha, /dev/muffin! - well, actually, it's more likely an interrupt
>>flavor. The DECWRL heat pipe requires a vertical-orientation sensor
>>(and power cutoff).
>
>Let's not use interrupts for this sort of thing.  Just how quickly is the
>temperature going to change.  A once per second poll should be more than
>enough. B^>/2.

I checked with the mechanical engineers involved (Hamburgen & Fitch).  They
say that you should have "a few seconds, but not minutes" after tipping to
perform any shutdown routine.  When first tipped, the thermosiphon actually
works more efficiently at cooling: instead of trying to boil a pool of
liquid, it will only have to boil a thin film of liquid.

-- 
Ramsey Haddad <haddad@decwrl.dec.com>
speaking for myself.
From: davsmith@nic.cerf.net (David Smith)
Newsgroups: comp.arch
Subject: Re: Error Correcting Memory
Date: 3 Sep 92 23:09:56 GMT
Organization: CERFnet

In article <Sep03.210730.68303@yuma.ACNS.ColoState.EDU> shafer@CS.ColoState.EDU (spencer shafer) writes:
>I'm interested in learning about the difference in reliability
>between parity memory and error checking-correction memory.  Can
>anyone provide me with some pointers to related books/articles?
>Or does anyone know straight off what the relative difference is?

Parity memory says, "Dude, you're bummed.  You've got a hosed bit."

ECC memory says "Dude, check it out!  You had a single bit error and I, like,
	fixed it!" or "Dude, you're bummed, two or more of your bits were
	bad."

Parity will generally only be guaranteed to catch single bit errors, while
ECC will correct single bit errors and catch double bit errors (in general,
someone may have implemented an ECC that does more)

From the land of Sun and Cerf,
David L. Smith
smithd@discos.com or davsmith@nic.cerf.net
-- 
David L. Smith
smithd@discos.com or davsmith@nic.cerf.net
From: rw@dcs.ed.ac.uk (Robert Walker)
Newsgroups: comp.arch
Subject: HELP manufactures!!
Date: 3 Sep 92 12:51:04 GMT
Organization: Department of Computer Science, University of Edinburgh

Hi,
   Could anyone out there email me names/addresses for the companies: Mips,
Weitek. This would be result in `pestering' enquires by a friend and I, so be
prepared! Sorry for wasting net bandwidth...

Thanks Rob.

Email at: rw@uk.ac.ed.dcs
Newsgroups: comp.arch
From: anton@mips.complang.tuwien.ac.at (Anton Martin Ertl)
Subject: Re: Program behaviour (was Re: trapping speculative ops
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Fri, 28 Aug 1992 09:50:45 GMT

In article <1992Aug27.202845.10747@bcars64a.bnr.ca>, schow@bqneh3.bnr.ca (Stanley T.H. Chow) writes:
|> In article <l9q6e0INN919@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
|> >As far as loads and stores go, I am similarly mystified by the
|> >insistence that each and every trap from the source program be
|> >preserved in "very-optimized" code (not code compiled for debugging,
|> >or at a "normal" level of optimization).
|> 
|> Some people (including me), believe that there is only *one* level
|> of optimization. One should always ship the same binary that one
|> tested; doing otherwise expresses immense faith in the ability of
|> one's process to recompile the same source as well as the correctness
|> of ones tools - the compilers, optimizes, linkers.

Not only that. Optimization can even uncover bugs in the program that
don't show up in debugging mode. E.g.:

f(i, i++);

This could work as you intended (say, using the same value of i both
times) in debugging mode, but it could deliver different results when
optimized.

The moral of the story: Deliver the same code that you debugged. Let
sleeping bugs sleep:-)

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen