Path: csiph.com!aioe.org!.POSTED!not-for-mail From: Rod Pemberton Newsgroups: comp.lang.forth Subject: Re: LLVM and Forth Date: Wed, 5 Apr 2017 00:44:35 -0400 Organization: Aioe.org NNTP Server Lines: 116 Message-ID: <20170405004435.4706b792@_> References: <21153661-abf5-4958-82c7-e3c442b45cb9@googlegroups.com> <065e774c-c5fb-4e68-9489-00b5357142d6@googlegroups.com> <72a319fa-8035-4a17-a5a2-2b2884a57b15@googlegroups.com> NNTP-Posting-Host: ZTD62cW/Uw8bymX5ok+0NA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:56739 On Tue, 4 Apr 2017 17:57:52 -0700 (PDT) krishna.myneni@ccreweb.org wrote: > On Tuesday, April 4, 2017 at 8:37:46 AM UTC-5, Albert van der Horst > wrote: > > In article <72a319fa-8035-4a17-a5a2-2b2884a57b15@googlegroups.com>, > > wrote: > > Having a special action for 1+ is silly anyway. > > The ++ operator is a remnance of the PDP11 era, there is not a shred > > of a reason to use it in output for a translator. ... > > Isn't there an INC operation in x86? > 16-bit. Yes. 32-bit. Yes. 64-bit. No. (It was reassigned for the REX prefix.) You can see this on Sandpile.org's "1 byte opcodes" page: http://www.sandpile.org/x86/opc_1.htm Sandpile.org "The world's leading source for technical x86 processor information." http://www.sandpile.org/ > > Everyone using ++ or -- in the output of a Forth to C translator > > is an idiot. > > > > I would think the criteria for being an idiot is more general than > that, at least with present day C compilers. > Today, adding one or subtracting one optimizes just as well, but isn't as compact to code. There is nothing wrong with ++ or -- , AS LONG AS you follow the ANSI C rules for using them. Of course, almost no one knows or remembers or uses these rules ... ANSI C introduced rules for their use with the "sequence points" concept of ANSI C. This resulted in the pre- and post-decrement or pre- and post-increment operations to sometimes erroneously affect the result of a computed value when the sequence is optimized or compiled. I.e., the order of operations for ANSI C was changed and is not guaranteed to be identical to that of K&R C or earlier. The ANSI C rules say that you must separate out the usage or pre- and post-decrement and pre- and post-increment from other C code. These rules carry over into ISO C, even if not stated. This, for ANSI C compliance, v = ++v + 2; should be rewritten as this: ++v; v = v + 2: This, for ANSI C compliance, v = v++ + 2; should be rewritten as this: v = v + 2; v++; Of course, these are equivalent: v += 2; v = v + 2; The rules are because of situations like this one: v += ++v + 2; /* coded */ v = v + ++v + 2; /* equivalent */ If v is 3, is the result 9 or 10? Historically, the expected result in C is 10. I.e., it's equivalent to: ++v; v += v + 2; This is because historically pre-increment was supposed to occur first, prior to any other operations. However, ANSI C's sequence points concept meant that the operation could occur anywhere prior to the semicolon. It doesn't have to explicitly come first. I.e., ANSI C fiddled with the expected order of operations and completion. v++, v=4, v = 4 + 4 + 2, v=10; /* pre-ANSI C, v++ occurs first */ v = 3 + 3 + 2, v++, v=9; /* valid for ANSI C ... */ v++ (2nd only), v = 3 + 4 + 2, v=9; /* valid for ANSI C ... */ It becomes more complicated with sequence points if multiple increments or decrements are involved: v = ++v + ++v + 2 ; The compiler can apply both pre-increments before, both after, one before and one after ... as long as the operations are applied prior to the semicolon. C also has the rarely used comma ',' operator (sequential expression) which allows for multiple statements to occur during the same sequence point. IMO, the sequence point concept is an abomination, but is needed for compilers. And, it is not the only mistake ANSI C committee introduced into C. They spent years correcting a number of other serious mistakes. Rod Pemberton -- All it takes for humanity to conquer the world's toughest problems is to hope, to believe, to share, and to do, in cooperation.