Pointers on pointers (ha...ha...ha..)

"Adrian Hey" <ahey@NoSpicedHam.iee.org> wrote in message
news:x4WdnRFX9sVrd-DanZ2dnUVZ8radnZ2d@pipex.net...

> More importantly IMO, there are many situations where the use of top
> level (aka "global") variables is absolutely the "Right Thing To Do"
> (TM) for semantic and safety reasons.

Do you distinguish "static" and "global" ?

> They provide important uniqueness
> guarantees. Of course such situations are generally hidden from typical
> apps level programmers by well abstracted IO interfaces. So well hidden
> in fact that many seem completely unaware of how the OS's or language
> RTS's or IO libs or GUI "frameworks" (or whatever) that they are
> dependent on *actually work*.
>
> But someone has to implement these at the end of the day. Maybe those
> who believe "global variables" are the root of all evil should stop to
> ponder how malloc really works,

Which malloc? There can be any number of heaps and mallocs. You can add to
them as you like :)

> or what really happens when they open
> a socket,

Which socket at what interface ? There can be any number of theese. You can
add to them as you like :)

> or how an interrupt handler really works (for example).

friend void Interrupt_Handler(CONTEXT *context)

> Umm..

Doh..

VLV

Jim Thomas wrote:
>> I can't think of a good reason.  Globals remain sinful in my book.

Adrian Hey wrote:
> It's funny how this myth gets propogated. So you never use globals?
> (I don't believe this). I can understand that these days, what with
> OS's and canned IO libs and wotnot, most programmers can (and evidently
> do) delude themselves about this, but I wouldn't have thought comp.dsp
> folk lead such sheltered lives :-)

Yes, I do use globals, but sparingly, and mostly for items of truly 
global scope (one exception being the well-known "errno" variable).

The OP wrote, "I've noticed that they've not used pointers or passed 
anything between procedures and relied on global variables."

The "sin" I'm calling out is that of using globals in lieu of passing 
arguments between procedures.  This practice makes it pretty difficult, 
for example, to scale a one-channel project to a multi-channel project.

It also complicates code re-use, as globals are very much like tentacles 
that have to be amputated and then either cauterized or grafted.  Having 
code be as self-contained as possible with well-defined boundaries makes 
it a lot easier to debug and understand.  Globals are like hidden 
interfaces between a function and its caller.  So yes, I do prefer the 
shelter of an explicit interface.

OTOH, it's also quite possible to overuse argument passing.  If a 
function has more than five arguments (my personal threshold), it raises 
a red flag in my mind, and I reexamine the interface between the 
function and its caller.  I sometimes write functions with more than 
five arguments, but that's pretty rare, and I ALWAYS take another look 
when I do.

-- 
Jim Thomas            Principal Applications Engineer  Bittware, Inc
jthomas@bittware.com  http://www.bittware.com    (603) 226-0404 x536
Today is the last day of your life so far.

Vladimir Vassilevsky wrote:
> "Adrian Hey" <ahey@NoSpicedHam.iee.org> wrote in message
> news:x4WdnRFX9sVrd-DanZ2dnUVZ8radnZ2d@pipex.net...
> 
>> More importantly IMO, there are many situations where the use of top
>> level (aka "global") variables is absolutely the "Right Thing To Do"
>> (TM) for semantic and safety reasons.
> 
> Do you distinguish "static" and "global" ?

No, but I think I should. Here I'm just using the convention that
everyone else seems to use when I get involved in flame wars about
this. Most people seem to call any mutable variable that occurs at
the program top level (I.E. statically allocated) a "global",
whether or not it's exported.

I would prefer to use the word "global" to refer to only variables
that really do have global scope (they are potentially accessible
anywhere by anyone), but this doesn't seem to be what most people
mean by "global". BTW, I would agree that such things really are
sinful and should never be used.

>> They provide important uniqueness
>> guarantees. Of course such situations are generally hidden from typical
>> apps level programmers by well abstracted IO interfaces. So well hidden
>> in fact that many seem completely unaware of how the OS's or language
>> RTS's or IO libs or GUI "frameworks" (or whatever) that they are
>> dependent on *actually work*.
>>
>> But someone has to implement these at the end of the day. Maybe those
>> who believe "global variables" are the root of all evil should stop to
>> ponder how malloc really works,
> 
> Which malloc? There can be any number of heaps and mallocs. You can add to
> them as you like :)
>

If there are multiple heap spaces (e.g. for different memory regions)
then the corresponding mallocs are distinguished by *name* in the
exposed user interface. They don't take a pointer to the heap state
being managed as an explicit argument. But of course at the end of the
day all these mallocs will need such a thing, so they must be getting it
as a "global" (albeit a hidden one :-)

>> or what really happens when they open
>> a socket,
> 
> Which socket at what interface ? There can be any number of theese. You can
> add to them as you like :)
> 
>> or how an interrupt handler really works (for example).
> 
> friend void Interrupt_Handler(CONTEXT *context)
> 
>> Umm..
> 
> Doh..

You seem to be relying on some RTS magic here, so what you're calling
"Interrupt_Handler" is not the actual hardware interrupt handler, but
a routine which gets vectored to by the real interrupt handler. I've
never encountered a processor where the real interrupt handler (I.E. The
code that gets invoked immediately by the hardware) gets any kind of
argument in registers or on the stack.

The only thing an interrupt handler can rely on is that the stack
pointer points to a valid stack and that the interrupt return address
has been pushed onto the stack (or is stored in a specialised register).
So the address of any other data structures, vector tables or whatever
(or pointers to such) used by the handler must be statically determined.
IOW, they are "globals" (at least according to the definition most
people seem to use).

Regards
--
Adrian Hey

On Jan 3, 6:38 am, pulse_...@hotmail.com wrote:
> Hi
>
> New to all this DSP stuff but I'm programming the TI DM642 in C.
> Looking at some sample sourcecode for a similar task from someone who
> knows a lot about DSP, I've noticed that they've not used pointers or
> passed anything between procedures and relied on global variables.
> I'd always been taught global variables are the most sinful thing a
> coder can do but wondered if there was some reason this was done for
> a DSP?

If you have a limited amount of memory and a problem
that barely fits in that amount of memory, then a static
allocation may be required to make sure everything fits and
that there will be no surprises at run-time (e.g.  overflow
of the local stack, etc.)  For some hard real-time software
on some CPU implementations, static allocation may be
required to prevent cache trashing or latency variability.
For instance, one may not want 2 convolution vectors sharing
the same direct-mapped cache-line due to accidents of
local allocation.  For some CPU/OS/compiler combinations,
the only way to absolutely control the static memory layout
of all data is to put all of it in one global data segment
or heap.



IMHO. YMMV.
--
rhn A.T nicholson d.0.t C-o-M

Adrian Hey wrote:

> Vladimir Vassilevsky wrote:

>> "Adrian Hey" <ahey@NoSpicedHam.iee.org> wrote in message
>> news:x4WdnRFX9sVrd-DanZ2dnUVZ8radnZ2d@pipex.net...

>>> More importantly IMO, there are many situations where the use of top
>>> level (aka "global") variables is absolutely the "Right Thing To Do"
>>> (TM) for semantic and safety reasons.

I agree, but it depends a lot on the application.  For routines that
are likely to be reused in a different context, global variables of any
kind can cause problems.  For something very specialized the situation 
is very different.   Consider, for example, a program used to do weather
forecasting.  It might have a large array with temperature and pressure
at different points around the earth.  That array, and related arrays, 
may be used by most of the routines in the program.  Many routines using
that array will be very specialized to the data structures in use.
There would be a fairly high overhead passing that array, and the 
associated arrays, around to all routines that needed them.
The routines are specialized enough that it is unlikely that they
would be used anywhere else.

>> Do you distinguish "static" and "global" ?

> No, but I think I should. Here I'm just using the convention that
> everyone else seems to use when I get involved in flame wars about
> this. Most people seem to call any mutable variable that occurs at
> the program top level (I.E. statically allocated) a "global",
> whether or not it's exported.

There aren't so many uses for static variable data.  One of the
more common ones is the state variable for a random number generator.
There are more uses for static data that doesn't change, mostly
in the form of look-up tables.

> I would prefer to use the word "global" to refer to only variables
> that really do have global scope (they are potentially accessible
> anywhere by anyone), but this doesn't seem to be what most people
> mean by "global". BTW, I would agree that such things really are
> sinful and should never be used.

-- glen