simple variable question

linuxvolts

I have some code, and I was trying to break it up into separate .spin files to make it more manageable. The problem that I run into is that when I move a PUB object to it's own spin file it no longer knows about the variables of the original file. It there anyway to make the other files aware of the variables in the main file, or do I just have to pass pointers? Am I correct that all VAR declared variables live in main memory? Or am I missing something else about this whole thing.

thanks,
Paul

Mike Green

Spin objects are really intended to represent a logical grouping of routines (methods) along with the variables they use and to hide the details of how things are done internally. As a result, the variables are not directly accessible outside the object (except via pointers). Normally people provide accessing routines to return the value of a particular variable or to set the variable to a new value, one pair of routines for each variable. Because named constants are often used to hide the use of numbers as codes, you can access the names of constants from outside the object along with any public (PUB) routines.

I strongly suggest that you don't divide up code that's all functionally interrelated. It actually make things messier, harder to understand, and often buggier.

linuxvolts

Mike,

Thanks for your response. OK, I think I can make a method in the object to return the value I need. Can you walk me through how calling that method from a different cog gets handled?

thanks,
paul

StefanL38

Hello Paul,

just take a look into a democode that uses an object.

That's the way it works.

I strongly recommend to keep things that are functionally interrelated together.

Acommodate from the "separate it to thousands of files"-style in C/C++ to

the SPIN-Style which is "ONE file for ONE functionality"

best regards

Stefan

Mike Green

Remember that the issue of how to use information from one cog by another cog has nothing to do with whether there's one object involved or several. You can have a program consisting of one object that uses all 8 cogs and you can have a program with multiple objects that only uses one cog for the whole thing.

Say you have a main program and a separate object used by the main program.

Say that the 2nd object has a start method that uses COGNEW to start up a new cog using one or more methods in that object. You'd also have some PUB methods in that object that provide the interface to that cog. Look at any of the Spin-only objects in the Object Exchange for examples of this.

Notice that these interface routines either take some parameters, work with them somehow, and end up changing some of the VAR variables in the object that are also used by the routines used by the separate cog or they take some parameters, work with them and some of the shared variables, and return some value.

There's nothing fancy. You just have some variables that are accessed both by the interface routines and by the separate cog's routines.

The trick is making sure that the main program and the interface routines called by the main program don't access or change those variables at exactly the same time that the other cog is also changing or accessing them. One way is to use LOCKxx statements as described in the Spin Manual. In some special cases, you don't need the LOCKxx statements as long as you write your program so only one cog will change a given variable. One common special case is called the Single Producer / Consumer case and is discussed in pretty much any textbook on multi-processor programming.