Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: comp.lang.forth Subject: Re: CASE mis-understanding? Date: Tue, 18 Feb 2014 18:19:04 -0500 Organization: Aioe.org NNTP Server Lines: 45 Message-ID: References: <52e54d17.461102185@news.demon.co.uk> <2014Feb13.162903@mips.complang.tuwien.ac.at> <2014Feb15.171430@mips.complang.tuwien.ac.at> <2014Feb17.150541@mips.complang.tuwien.ac.at> <2014Feb18.103428@mips.complang.tuwien.ac.at> <2014Feb18.151937@mips.complang.tuwien.ac.at> <7xppmks7v9.fsf@ruckus.brouhaha.com> NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:28544 On Tue, 18 Feb 2014 11:28:26 -0500, Paul Rubin wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> It's not just what the hardware does. It's what gcc does, unless the >> "optimizer" comes into play. On MIPS it compiles + of signed integers >> into addu, not add (which produces an exception on overflow); on Alpha >> into add, not addv (again exception on overflow). On IA32 into add >> without following it with into. When I rearrange the code so that the >> "optimizer" does not see everything together, gcc does what I intend >> the code to do. A proper optimizer does not change that. > > Are you seriously saying that the optimized program always has to do the > exact same thing as the unoptimized one, [...] It should, yes. It should do exactly what I told it to do. That's our expectations as a programmer, well, definately my expectation. However, all high-level code must be converted to assembly or binary and the correlation is not always one-to-one. > Are you seriously saying an optimizer should preserve that behavior? Of course, it's impractical to preserve boundary effects during optimization. This affects evenly lowly languages like Brainfuck. The sequence: [] will continue if the current cell is zero, but is an infinite loop if non-zero. [] occurs *frequently* in Brainfuck code, especially so if the code is generated by program. The questions that arise are: 1) Did someone intentionally code an infinite loop to halt the program, or does the code always continue? 2) Even though an infinite loop is valid code in Brainfuck, can it be assumed to be useless, i.e., generated by program not a person, and safely be optimized away? Rod Pemberton