Reply by glen herrmannsfeldt January 7, 20082008-01-07
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
Reply by Ron N. January 4, 20082008-01-04
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
Reply by Adrian Hey January 4, 20082008-01-04
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
Reply by Jim Thomas January 4, 20082008-01-04
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.
Reply by Vladimir Vassilevsky January 4, 20082008-01-04
"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
Reply by Allan Herriman January 4, 20082008-01-04
On Thu, 03 Jan 2008 10:08:35 -0500, Jim Thomas <jthomas@bittware.com>
wrote:

>pulse_web@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? >> >> Cheers... > >I can't think of a good reason. Globals remain sinful in my book.
Shucks, I ain't got nuttin' but globals when I design my hardware. I leave all that fancy indirect stuff to the software folk. I leave the bugs to them as well. Allan
Reply by Adrian Hey January 4, 20082008-01-04
Tim Wescott wrote:
> Using globals instead of pointers means that the addresses of the data is > known at link time, which saves a level of indirection, which speeds > things up slightly. > > If the _only_ thing you care about is speed of execution, then using > globals everywhere is appropriate. If you can stand to lose a few clock > ticks to indirection it is much easier to write portable, reusable code > by passing data in the function call.
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. 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, or what really happens when they open a socket, or how an interrupt handler really works (for example). Umm.. Regards -- Adrian Hey
Reply by Vladimir Vassilevsky January 4, 20082008-01-04
"Tim Wescott" <tim@seemywebsite.com> wrote in message
news:KaqdnY-9k7RCXeDanZ2dnUVZ_tjinZ2d@web-ster.com...

> Globals are, IMHO, best when used very sparingly, but as you say you > can't get rid of them.
You mean passing the data between the threads? This could be done by messaging, although it could be too heavy solution. Vladimir Vassilevsky DSP and Mixed Signal Consultant www.abvolt.com
Reply by pal.debabrata123 January 4, 20082008-01-04
>Jim Thomas wrote: >> pulse_web@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? >>> >>> Cheers... >> >> I can't think of a good reason. Globals remain sinful in my book. > >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 :-) > >Regards >-- >Adrian Hey >
Globals cannot be bad in all situations. Who wants to pass pointers all throught a chain of 100 functions? That is the concern for optimization. ( arguments passing may use stack. perhaps the original variable is also on stack because it is local to caller function).In a "run to completion" module globals may help. Better have a list where you cannot use a global. a reentrant function ( not run to completion ) is one example perhaps.
Reply by Tim Wescott January 4, 20082008-01-04
On Thu, 03 Jan 2008 06:38:29 -0800, pulse_web 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? > > Cheers...
Using globals instead of pointers means that the addresses of the data is known at link time, which saves a level of indirection, which speeds things up slightly. If the _only_ thing you care about is speed of execution, then using globals everywhere is appropriate. If you can stand to lose a few clock ticks to indirection it is much easier to write portable, reusable code by passing data in the function call. -- Tim Wescott Control systems and communications consulting http://www.wescottdesign.com Need to learn how to apply control theory in your embedded system? "Applied Control Theory for Embedded Systems" by Tim Wescott Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html