Jerry Avins <jya@ieee.org> writes:> Randy Yates wrote: > >> Jerry Avins <jya@ieee.org> writes: >> >>>[...] >>>It may compile and it may run, but if it does it will yield >>>unpredictable results. count[] was never initialized. >> >> >> True, but irrelevent. >> >> >>>Anyway, doesn't >>>one want count[i], not i[count]? >> >> >> That's the point - they're isomorphic. > > That's rich!Thanks Jerry! I was incredulous when I first saw it many years ago (12?). Had to try it for myself.> Of course, a + b = b + a. It won't work for 2D arrays, > though. :-)I suppose you're right - the order matters there since there's an implicit scale factor on one.> (It won't work in Forth either, at least not the way I > define my arrays.) > > Jerry > -- > Engineering is the art of making what you want from things you can get. > �����������������������������������������������������������������������-- % Randy Yates % "And all that I can do %% Fuquay-Varina, NC % is say I'm sorry, %%% 919-577-9882 % that's the way it goes..." %%%% <yates@ieee.org> % Getting To The Point', *Balance of Power*, ELO http://home.earthlink.net/~yatescr
Conceptual model for pointer arithmetic in FIR filter implementation?
Started by ●October 13, 2004
Reply by ●October 17, 20042004-10-17
Reply by ●October 17, 20042004-10-17
"Randy Yates" schrieb>> >> [pointer notation vs. array notation] > > Trick question: > > int count[20]; > int i; > > for (i = 0; i < 20; i++) > { > printf("count is %d\n", i[count]); > } > > Will this compile and run? >Yes. The other questions are: will it provide the intended result? Will it provide the same result as count[i]? To the best of my recollection in C, yes. But I'd never write it like that and I would seriously question the sanity of writing it like that (*). C, IMHO, not only gives you enough rope to hang yourself, it also bends over backwards at every possible occasion to entice you doing so. C is a powerful tool, but its power can be easily abused. IMHO. YMMV. Martin (*) If you want to go for raw speed and optimization, I'd propose a proof-of-concept for a new algorithm in C, then hand-crafting it in assembly. And yes, I agree, that there is a place for hand- crafted assembly code, especially in systems that are tight in space and power.
Reply by ●October 17, 20042004-10-17
axlq wrote:> > It's not the same thing at all; defining it that way won't make it so. > > If y is a pointer to an array of floats, and n is an integer, then > y[n] = *(y+n) = *(n+y). In this case n is synonymous with "offset > of n multiplied by sizeof(float) bytes." You can't do n[y] with > n declared as an integer; the compiler won't allow it. If you > cast n to a float pointer, then ((float *)n)[y] won't give you any > meaningful result, and will likely result in an addressing error > on operating systems like unix that manage memory. n[y] means > that the value of n by itself is a memory address (which can be > anything), and incrementing it by y*sizeof(float) will reference > who-knows-what, especially if n is an odd number that doesn't > correspond to a word-aligned boundary. >Sorry - but you're wrong - try it yourself. Even if n is short and y is an array of doubles it still works. And it doesn't even generate a warning with gcc -Wall. Paul
Reply by ●October 17, 20042004-10-17
"Martin Blume" <mblume@socha.net> wrote in message news:<41722856$0$28024$5402220f@news.sunrise.ch>...> "Randy Yates" schrieb > >> > >> [pointer notation vs. array notation] > > > > Trick question: > > > > int count[20]; > > int i; > > > > for (i = 0; i < 20; i++) > > { > > printf("count is %d\n", i[count]); > > } > > > > Will this compile and run? > > > > Yes. > > The other questions are: will it provide the intended result? > Will it provide the same result as count[i]? > To the best of my recollection in C, yes. >Let's see. 'count' array is not initialized. 'i' is not an array or pointer. Compiler will probably bomb on 'i[count]' since 'i[count]' really has no valid meaning. Result will definitely not be: count is 0 count is 1 ... ... count is 19 Could make printf line printf("count is %d\n", i); to get results desired. Dirk
Reply by ●October 17, 20042004-10-17
dirkman@erols.com (Dirk Bell) writes:> "Martin Blume" <mblume@socha.net> wrote in message news:<41722856$0$28024$5402220f@news.sunrise.ch>... >> "Randy Yates" schrieb >> >> >> >> [pointer notation vs. array notation] >> > >> > Trick question: >> > >> > int count[20]; >> > int i; >> > >> > for (i = 0; i < 20; i++) >> > { >> > printf("count is %d\n", i[count]); >> > } >> > >> > Will this compile and run? >> > >> >> Yes. >> >> The other questions are: will it provide the intended result? >> Will it provide the same result as count[i]? >> To the best of my recollection in C, yes. >> > > Let's see. 'count' array is not initialized. 'i' is not an array or > pointer. > > Compiler will probably bomb on 'i[count]' since 'i[count]' really has > no valid meaning.Bzzt.> Result will definitely not be: > > count is 0 > count is 1 > ... > ... > count is 19Bzzt.> Could make printf line > > printf("count is %d\n", i); > > to get results desired.Could fly to the moon too. Crash and burn, Dirk. If you haven't already seen the subsequent post of actual code and results, please do. Or better yet, try it for yourself - it's not hard. -- % Randy Yates % "She's sweet on Wagner-I think she'd die for Beethoven. %% Fuquay-Varina, NC % She love the way Puccini lays down a tune, and %%% 919-577-9882 % Verdi's always creepin' from her room." %%%% <yates@ieee.org> % "Rockaria", *A New World Record*, ELO http://home.earthlink.net/~yatescr
Reply by ●October 17, 20042004-10-17
Randy Yates <yates@ieee.org> writes:> dirkman@erols.com (Dirk Bell) writes:> >> > int count[20]; > >> > int i;> > Let's see. 'count' array is not initialized. 'i' is not an array or > > pointer. > > > > Compiler will probably bomb on 'i[count]' since 'i[count]' really has > > no valid meaning. > > Bzzt.Indeed - quoth the standard: "x[i], which is equivalent to (*((x)+(i)))" Phil -- They no longer do my traditional winks tournament lunch - liver and bacon. It's just what you need during a winks tournament lunchtime to replace lost ... liver. -- Anthony Horton, 2004/08/27 at the Cambridge 'Long Vac.'
Reply by ●October 18, 20042004-10-18
All right Randy, What am I missing? I put it in my C++ compiler (Borland C++ Builder), it did compile, but printed meaningless numbers. Bzzt? When the print line was changed as I suggested it produced the results that I said the original code would not produce. Bzzt? Please don't make me read the entire thread to see what you are talking about. Bzzt? Dirk Randy Yates <yates@ieee.org> wrote in message news:<vfd984fc.fsf@ieee.org>...> dirkman@erols.com (Dirk Bell) writes: > > > "Martin Blume" <mblume@socha.net> wrote in message news:<41722856$0$28024$5402220f@news.sunrise.ch>... > >> "Randy Yates" schrieb > >> >> > >> >> [pointer notation vs. array notation] > >> > > >> > Trick question: > >> > > >> > int count[20]; > >> > int i; > >> > > >> > for (i = 0; i < 20; i++) > >> > { > >> > printf("count is %d\n", i[count]); > >> > } > >> > > >> > Will this compile and run? > >> > > >> > >> Yes. > >> > >> The other questions are: will it provide the intended result? > >> Will it provide the same result as count[i]? > >> To the best of my recollection in C, yes. > >> > > > > Let's see. 'count' array is not initialized. 'i' is not an array or > > pointer. > > > > Compiler will probably bomb on 'i[count]' since 'i[count]' really has > > no valid meaning. > > Bzzt. > > > Result will definitely not be: > > > > count is 0 > > count is 1 > > ... > > ... > > count is 19 > > Bzzt. > > > Could make printf line > > > > printf("count is %d\n", i); > > > > to get results desired. > > Could fly to the moon too. > > Crash and burn, Dirk. If you haven't already seen the subsequent post of actual code > and results, please do. Or better yet, try it for yourself - it's not hard.
Reply by ●October 18, 20042004-10-18
dirkman@erols.com (Dirk Bell) writes:> What am I missing?Dirk, The main point is that the syntax a[i] is equivalent to *(a+i), so much so that the order of "a" and "i" are not relevent since, on the one side, a+i is equivalent to i+a. --Randy -- % Randy Yates % "Rollin' and riding and slippin' and %% Fuquay-Varina, NC % sliding, it's magic." %%% 919-577-9882 % %%%% <yates@ieee.org> % 'Living' Thing', *A New World Record*, ELO http://home.earthlink.net/~yatescr
Reply by ●October 18, 20042004-10-18
Hi Randy, I agree with you when an architecture is very simple (like a DSP with three or four functional units) and the program is very simple (like an FFT or filter that is repetitive), but it is less clear when the processor has 30 or even 300 functional units and the code must include control code and complex operations that don't so readily code into nice pipelined iterative simple loops. Nor is it so clear when one may be dealing with not just one processor with a fixed architecture but coding for a whole family and aiming to produce code that can be re-used some years later on a new architecture. If the compiler makes decisions that are as good as, or better than, a really good assembler programmer would make then isn't it sensible to use the compiler? And to avoid every programmer having to be as good as that 'really good assembler programmer', isn't it justifiable to put the knowledge into the tool? If the tools get used a lot over a long time then don't they pay for themselves in the long term? The compilers I am thinking of were first developed more than 10 years ago and have been applied since then to very many large projects, so the initial cost though high may have been worthwhile. What I now find difficult in writing very efficient assembler that 'beats' the compiler is not in the assembler where the code is obvious, repetitive and small (FFTs, filters etc) but in applications where the compiler can exploit parallelism in the architecture - in such cases the compiler is better than I am at finding parallel opportunities that may be far separated in the initial C code: and it has a much better and more complete model of the processor than I have. For example one of these cores has 32 functional units with various allowed combinations and latencies - I find it very easy to write very simple assembler, but I can't find ways to use all those units efficiently in more general code: the compiler tends to be upwards of 80% efficient (that is, it can use 80% of the available units all the time from general C code). New processors like the 'Silicon Hive' ULIWs have more units - may hundreds, in parallel threads - and I think I will find those even more difficult to second-guess the compiler. By the way, anyone from this group going to CES next January? Chris =================================================== Chris Bore BORES Signal Processing chris@bores.com www.bores.com Randy Yates <yates@ieee.org> wrote in message news:<u0suhdfl.fsf@ieee.org>...> chris_bore@yahoo.co.uk (Chris Bore) writes: > > > As to the question whether real DSP on non-traditional architectures > > is done in C, then yes very much so - most of Philips and Sony work on > > audio and video for digital and analog TV is done in C, even in C++ - > > this at least for the Nexperia processors. They use VLIW for this. The > > compilers become enormously expensive (hundreds of man-years of > > effort) and the code base becomes highly valuble (hunderds of millions > > of dollars) - so the software tools start to cost almost as much as > > the system-on-chip itself. > > And all this to avoid a little assembly language programming? Methinks > we have our heads up our rears. Put that effort into the base implementation > and you're light years ahead in terms of speed, code size, performance, > and man-years. Even time-to-market won't suffer when compared to such > gargantuan efforts for the tools.
Reply by ●October 18, 20042004-10-18
Randy,
And that relates to my comments how? The code snippet does not work
in any reasonable way as I pointed out. The modification that I
suggested, which was criticized for something I still do not
understand ("crash and burn" IIRC) worked fine.
The point that you state is obvious, but the relation to my comments I
do not see.
Dirk
Randy Yates <yates@ieee.org> wrote in message news:<8ya4k61q.fsf@ieee.org>...
> dirkman@erols.com (Dirk Bell) writes:
>
> > What am I missing?
>
> Dirk,
>
> The main point is that the syntax a[i] is equivalent to *(a+i), so
> much so that the order of "a" and "i" are not relevent since, on the
> one side, a+i is equivalent to i+a.
>
> --Randy
