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