[vorbis] mdct.c pointer to array conversion

[Keith Wright]

> From: Govind Kharbanda <govind.kharbanda at sli-institute.ac.uk>
> 

> I'm attempting to convert all the pointers to arrays [in] the
> mdct_backward function so it can be partitioned off for a hardware
> implementation.
> 
> As it stands, mdct_backward is passed values by reference i.e.
> 
>  void mdct_backward(mdct_lookup *init, DATA_TYPE *in, DATA_TYPE *out)
> 
> so my modified version starts
> 
>  void mdct_backward_2(mdct_lookup init, DATA_TYPE in[], DATA_TYPE out[])

I don't understand the point of this.  In C, arrays and pointer are
(except for syntax) the same thing.

  $ Every time an identifier of an array type appears in an
  $ expression, it is converted to a pointer to the first member
  $ of the array.  By definition, the subscript operator [] is
  $ interpreted in such a way that E1[E2] is identical to *((E1)
  $ + (E2)).
         -- Kernighan and Ritchie, Appendix A [14.3] (first ed.) 

the 'mdct_lookup init' appears to be a constant table, the pointer is
just to avoid copying.  If this is true, you would want to set it up
in the hardware device during initialization and leave it alone.

> The function contains statements such as
> 
> DATA_TYPE *iX = in + n2-7
>
> from which it appears that iX, oX are being used to index the
> in[] array and out[] array respectively.

I think so too.

> Using a pointer to access memory elements means you do not have
> to keep thinking about the width of your index, however you do
> have to think about this if you take the pointers away which is
> what I'm having problems with.

Both the array index and the pointer are automatically multiplied
by the width of the array element or referenced element (which
are the same thing).

> For instance, init-> trig :
> 
> T[0] through to T[7] contain the values of memory stored at
> (init->trig)+n4 onwards.  I can't pass the pointer init->trig
> directly to hardware since the hardware core will not be able
> to access the memory of the host PC (mapping0.c which calls
> mdct_backward will remain on the host PC for now) so I'm having
> to transfer the structure back and forth using DMA.  So the
> structure will have to be modified slightly so the values from
> init->trig are contained as part of the structure.  How big
> should this trig array be?

So the real problem is when to transfer the trig tables to
the coprocessor.  It appears to me that these are constant
tables that are set up in 'block.c' by two calls to 'mdct_init'.
If this is indeed the case then you could put both of them in
the coprocessor during initialization and refer to them simply
as '0' and '1' when calling 

  #if COPROCESSOR
  #  define MDCT_LOOKUP_N int
  #else
  #  define MDCT_LOOKUP_N mdct_lookup *
  #endif
  void mdct_backward(MDCT_LOOKUP_N init, DATA_TYPE *in, DATA_TYPE *out)

Then the call (in 'mapping0.c') changes from

    mdct_backward(b->transform[vb->W][0],pcm,pcm);

to simply

    mdct_backward(vb->W,pcm,pcm);

> Hope someone can make this less confusing,

Warning!  I am a dangerous ignoramus.  The above random thoughts
are not backed by a deep understanding of Vorbis.  The Xiphites
probably have reasons for the way they did this---of which I
know nothing at all.


-- 
     -- Keith Wright  <kwright at free-comp-shop.com>

Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
         ---  Food, Shelter, Source code.  ---
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.