Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!think!snorkelwacker!bloom-beacon!eru!luth!sunic!infovax!bl
From: bl@infovax.UUCP (Bj|rn Larsson)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Turbo C far pointers
Message-ID: <310@infovax.UUCP>
Date: 18 Nov 89 18:16:29 GMT
Article-I.D.: infovax.310
References: <1697@bruce.OZ>
Reply-To: bl@infovax.UUCP (Bj|rn Larsson)
Organization: Infovox AB, SOLNA, Sweden
Lines: 85

In article <1697@bruce.OZ> alanf@bruce.OZ (Alan Grant Finlay) writes:
>
>In Article <6689@esegue.segue.boston.ma.us> John R. Levine writes:
>
>>In article <579@gmuvax2.gmu.edu> 2179ak@gmuvax2.UUCP (JDPorter) writes:
>>>>>That's ridiculous. *(A+1), A[1], and 1[A] all produce exactly the same code.
>>
>>>*(A+1) does NOT produce the same code as A[1].  (not for MSC, anyway.)
>>
>>Congratulations, you've found an optimization bug in MSC.  In Turbo, assuming
>
>As I am doing research in programming language semantics I can't resist putting
>my oar in.  This is an issue I have much meditated upon in the past.  As I see
>it the semantics of high level programming languages are best left independent
>of efficiency specifications.  This is partly due to the need for machine
>independence but also for more philosophical reasons.  With high level languages

I have not read the original article or most of the followups but as I
see it, it is best to use the syntax

	A[i]

to access an array element if A is actually an array which is accessed
directly, and

	*(A+i)

if you access an array element via a pointer (A in this case) which points
to the start of the array. In other words, in the first example, A is the
ARRAY ITSELF - in the second, A is a POINTER TO the array. To me, any
other practice is MISLEADING as to what is really going on in the hardware,
although the same effects are achieved. To me it is actually somewhat
unfortunate that C allows this kind of 'aliasing' for fundamentaly diffe-
rent access methods. The example

	i[A]

mentioned above should NOT work. in fact it is awful!  The compiler would
have to assume that i is a pointer, but of which type?  Except this being
a syntax error, the compiler needs to know the size of the element type
that i points to, so it knows how much to multiply A (which is also not
an integer type) to yield the offset in BYTES from where i points... YUCK!!!
Still, this might actually work on machines that have the same size of
integers and pointers... and a very forgiving compiler indeed.

This is also the area where 'C' programmers who don't know assembly
language make the most mistakes. Sometimes you can see horrible errors
being made, and when one tries to explain why it is an error, they don't
understand - they just don't have the concept of 'primary memory' which
you can either write into directly or access indirectly via pointers.

Note I don't discuss optimizer efficiency above. But why would you expect
a compiler to actually generate the exact same code if the source code
is different. Wouldn't it be possible that an optimizer WILL find other
optimizations methods (based on the surrounding statements) if the source
code is different? The important thing must be that if you give a function
some input, you get the correct output, independent of the algorithm and
coding practices.

To rely on the knowledge of how one specific compiler generates code I
consider bad practice - your assumptions will not hold if you port to
another compiler/environment. Of course, I'm stretching my point somewhat
here - you usually code in a way that is generally efficient - but be
aware that there may be machine architectures where 'normally efficient'
coding practices are LESS efficient. For example, often DSP's (signal
processors) need to be coded in a very different way, since they
allow a greater degree of parallell data transfering and instruction
pipe-lining, and 'normal' coding will not make use of these possible
advantages.

Furthermore, the speed differencies caused by different optimizations
will probably be extremly minor. Usually, if you use code size optimi-
zation with MSC or Turbo C (all versions) you'll only save a few hund-
red bytes in a typical 32k program. When I have tried speed optimization,
it usually hasn't even been possible to measure any resulting improvements
when executing the code, although the machine code WAS indeed different
(but alas, not faster). Note: this is my experience for PC's - I think
under UNIX you will probably get a measurable improvement by using the
optimization flags (5-10% maybe?). Just don't expect miraculous bene-
fits!
-- 
 ====================== InfoVox = Speech Technology =======================
 Bjorn Larsson, INFOVOX AB      :      ...seismo!mcvax!kth!sunic!infovax!bl
 Box 2503                       :         bl@infovox.se
 S-171 02 Solna, Sweden         :         Phone (+46) 8 735 80 90