Xref: utzoo comp.sys.ibm.pc:23532 comp.lang.c:15683 Path: utzoo!utgpu!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!agate!bionet!csd4.milw.wisc.edu!nic.MR.NET!shamash!tank!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.sys.ibm.pc,comp.lang.c Subject: Re: TC2.0 bugfree ? Message-ID: <15560@mimsy.UUCP> Date: 20 Jan 89 21:20:38 GMT References: <3785@druwy.ATT.COM> <16674@iuvax.cs.indiana.edu> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 60 In article <16674@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes: >I am cross-posting the following to comp.lang.c, because the language >expertise is there. I am not convinced that you have any guarantee about >just when the post-increments happen -- consider p.50 of K&R 1st edition, >for example. So it's not a TC bug, just an implementor's choice. This is correct. The pANS uses the notion of `sequence points' to decide when a side effect (such as post-increment) must happen; there is no sequence point within a simple assignment expression like the one quoted below. Incidentally, the quoted assembly shows that TC2.0 (Turbo C, I suppose) misses one possible optimisation. >> i = (*cp++ << 8) + *cp++; cp is in the SI register at this point; the goal is to compute AX=[SI]<<8: >> mov al,byte ptr [si] >> mov ah,0 >> mov cl,8 >> shl ax,cl A much better sequence is mov al,0 mov ah,byte ptr [si] A simple peephole optimiser should be able to catch this. More complex analysis might even figure out that i = (cp[0] << 8) + cp[1]; cp += 2; could be computed as mov ah,byte ptr [si] inc si mov al,byte ptr [si] inc si ; i is now in ax while i = cp[0] + (cp[1] << 8); is even more simple: mov ax,word ptr [si] but I would not expect most compilers to manage either of these. (If you rearranged the source to read i = *(int *)cp; I would expect the latter sequence.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris