DAT block

Don Pomplun

If all (objects') DAT blocks reside in main RAM, what keeps the elements defined in various objects from overlapping? . . . or is that Just Taken Care Of ?

Related: Most of my app works OK, but there are occasional anomalies. Is there a rule that e.g., the end of everything defined in one object's DAT block should end on a Long boundary?

TIA,
Don

PS - oh yeah, I can't find a Forum setting that emails me when there is a new post on a followed thread. Does it exist for this forum software?

Mike G

DAT block variables are allocated by type in the order defined. Any run-time object can overwrite a variable using a pointer.

Checkout AN003
http://www.parallaxsemiconductor.com/an003

MagIO2

Code, DAT and VAR can't overlap! The compiler takes care of HUB-RAM and in case your code is to big to fit into the 32k, it will tell you!

The problem you can have is with stack-space, with arrays or with direct HUB-RAM access. In all these fields you should really know what you do.

In more detail:
There is no check in the interpreter whether the stack is big enough. So, if not, your code can end up overwriting data/code unintentionally by simply calling functions. This can cause any kind of weird problems depending on what meaning you put on the memory locations you overwrote.

There is also no check for array boundaries. If your code extends the index used to write into the array, you'll overwrite memory that does not belong to the array.

Of course you have full access to HUB-RAM even without using variable names. In some cases this makes sense. But there is also the risk of overwriting memory locations that hold code or variables.

Don Pomplun

Yeah, one of the bugaboos I discovered was the Stack. I used the Stack Length to find one problem. Hard to know when you've exercised code enough to have found the real needed stack size. Fixing one of those took care of some funny stuff. I'll do it some more.
Good suggestion on the array boundaries. I'll make sure my code explicitly checks them.
Thanx

Don Pomplun

MagIO2 wrote: »

There is also no check for array boundaries. If your code extends the index used to write into the array, you'll overwrite memory that does not belong to the array.

.

Hah! Found onesuch . . . Had a circular buffer with different methods in different cogs. One added elements, advancing the Head pointer. The other took elements out when pointers weren't equal. But the depositer incremented the pointer, then checked to see if that would exceed the array size, in which case it would set it back to zero. But the withdrawer could catch the pointer while it was out of bounds and act on fictitious data!

Heater.

If you make your circular buffer a power of two in size, 4,8,16,32...then you can use masks to get rid of the high bits of the indexes which will insure they never exceed the array bounds. Then you only need to compare the head and tail indexes to see if there is room in the buffer or not. Makes the code simpler, smaller, quicker and safer than checking for reaching the end of the array and resetting to zero all the time.
It also has the benifit that the reader and writer can be separate tasks(cogs on the prop) and they won't corrupt the buffer even without using locks. Sadly I don't have an example cyclic buffer in Spin to hand. Surely somone here has.