RDLONG not recognized by Propeller Tool(?)

egenriether

Hi, I'm fairly new to the Prop so this is probably something I'm just doing wrong but when I try to use rdlong or wrlong, they aren't recognized by the compiler. In fact they don't turn into boldface type when I enter them either. I want to move some longs in one cog into another. I'm using longmove in one cog (that's working fine) and was hoping to read the values in the other cog with rdlong but it's not happening. Anyone know what I might be doing wrong?

Thanks

-Brian

Phil Pilgrim (PhiPi)

You're using rdlong in Spin, but it's an instruction only in PASM. What is it that you're trying to do in that statement?

-Phil

Duane Degn

egenriether wrote: »

I want to move some longs in one cog into another. I'm using longmove in one cog (that's working fine) and was hoping to read the values in the other cog with rdlong but it's not happening.

All the memory accessible from Spin is in the hub. "rdlong" allows hub memory to be read from a cog running PASM. There is not a way for one cog to read another's RAM.

Each cog only has about 2KB of RAM. Cog RAM is used from within the cog for program execution in the case of a cog running PASM code. If a cog is used to run Spin code, the cog gets loaded with the Spin interpreter. The cog then reads the Spin code from the hub (little pieces at a time) and executes the instructions. The shared RAM of the hub has most of the Propeller's memory (32KB).

egenriether

Phil Pilgrim (PhiPi) wrote: »

You're using rdlong in Spin, but it's an instruction only in PASM. What is it that you're trying to do in that statement?

-Phil

What you see there was me trying different things to get it to work, not how I originally had it, but the essence of it is this: I have a long in memory from longmove in another cog, stored in "output". I wanted to get it out out of memory to access it in a different cog. It sounds like Duane is saying my variable is in main memory. If so, can I just call the memory variable by name in any cog?

Thanks,

-Brian

Ariba

egenriether wrote: »

What you see there was me trying different things to get it to work, not how I originally had it, but the essence of it is this: I have a long in memory from longmove in another cog, stored in "output". I wanted to get it out out of memory to access it in a different cog. It sounds like Duane is saying my variable is in main memory. If so, can I just call the memory variable by name in any cog?

Thanks,

-Brian

If you have the code for both Cogs in te same Object (file) then you can access the variable by name ("output").

If your second cog is in another object, then you can not access the variable by name, the object variables are all privat.
Normally you provide a public methode that returns the value to make a variable accessible:

obj 1:

  var1 := getOutputVar


  obj 2:

PUB getOutputVar
  return output

Andy

Mike Green

You're making it way too complicated. First of all, it sounds like you are using several cogs, each running Spin code. In that case, all of the variables in the program (and all of the compiled code) are actually in hub (main) memory with the exception of the special registers (like INx, OUTx, DIRx, PHSx, FRQx, etc.) The cog memories are full of the Spin interpreter's instructions and data and are effectively invisible to you. When you do a LONGMOVE, you're just moving data from one place in hub memory to another and this has nothing to do with what cog is running the code. Any cog can refer to any location in hub memory.

Now, objects are different and cogs and objects are independent concepts. You can have a program in a single object (the main program) that uses all 8 cogs. You can also have a complex program with many objects that uses only one cog to run the whole thing. An object is a way to encapsulate some code and variables, making some of the code available for other objects to call while hiding a lot of the details of the object from the rest of the program. As a result of this hiding, one object can't directly refer to variables in another object. The "outside world" passes values to routines in the object and receives values from the object as the return values of routines. When an object needs to refer to some variable from outside, the outside code passes the address of the variable to the object (@variable) and the object can refer to that memory location using something like LONG[address].

egenriether

Thanks a lot Mike, I suspected I was over complicating things. Good explanation, I'll restructure the program accordingly.

-Brian