Propeller Memory Management

Neighborhood Physicist

When starting a new COG what if the difference between SPIN and assemby code with respects to where it finally gets exectued?

From what I have read it sounds like assemby code is loaded into the COG memory and executed soley in the COG.

What happens if you write spin functions? Does it have to marshal back and forth between the COG and main memory.

How do you define variable that will reside in cog memory vs main memory?

Looks like you can have max of 512 - 16 lines of assembly code·and longs in a·COG.· Does the FIT command work based on main memory or COG memory.

How long does the hub stay at each COG?

I am just starting to use the chip, so thanks for the help in advance.

·

Rayman

Where's deSilva?

1. Assemble gets loaded in COG RAM before running. SPIN stays in HUB and COG gets loaded with SPIN interpreter.

2. SPIN assigments refer to HUB RAM. Assembly assignments refer to COG ram, just declare bytes in DAT section for variables.

3. FIT is for COG memory. You can use STACK for main memory.

4. I don't remember... But, it says in the datasheet.

PS: I have some beginner info here: http://www.rayslogic.com/propeller/propeller.htm

Neighborhood Physicist

Thanks Rayman,

Your web page helps alot.

Mike Green

1) Spin code is compiled into interpretive byte codes and the Spin interpreter is what gets loaded into the cog from ROM to do the actual work. The Spin interpretive code stays in hub memory and the Spin interpreter reads it from there. You're right in that the assembly program gets copied into the cog memory during the COGNEW/COGINIT instruction's execution where it's executed.

2) You can't call Spin functions from assembly since the Spin code is not translated into machine instructions. An assembly program could replace itself with a copy of the Spin interpreter and pass information to the interpreter that would tell it where to start executing, but there would not be a way to return to the assembly program.

3) Since the assembly code is loaded as a block of 512 long words from the hub to the cog's memory, you just include the variables in between subroutines or at the end of the block of instructions using the LONG / WORD / BYTE directives or the RES directive.

4) The FIT directive checks the cog memory limit. The assembler effectively keeps two location counters, one for the location in the hub where the data is stored, the other for the location in cog memory when the assembly program is actually running there. The 2nd counter is what is used for putting together the instructions.

5) The cogs run continuously (unless stopped or paused for some reason), so they execute one instruction every 4 clock cycles (for most instructions). The hub memory access instructions require the attention of the hub memory management hardware and each cog gets one of 8 slots to do its access. Page 24 of the Propeller Manual has a good description of the timing between the cog and hub for memory access.

Neighborhood Physicist

Rayman,

I am going thru your ASM tutorial. In ex01, your say that the "pattern LONG $AAAAAAAA" is in "register 5." I typed it in and it looks like register 7 to me. Each row in the HEX display is 4 registers, right?? Just want to make sure that I am not missing something.

Rayman

Uh, you must mean deSilva's ASM tutorial, right? (Maybe I need to better clarify that...)

Rayman

Only the actual assemby commands count... "loop" and "ex01a" are just labels...

deSilva

Neighborhood Physicist said...
Each row in the HEX display is 4 registers, right??

Certainly not, but we should examine whatyour misunderstanding could be... It is not counting lines but counting their contents..

You generally need not know the actual number of the cells (=registers). You just have to make sure they do not exceed 496

Neighborhood Physicist

I really must me missing something. The HEX display window has rows with 16 hex elements in each row. I thought each hex element was 8 bits so 4 elements would give you 32 bits. This would give 4 instructions per row in the hex display.


I assume that since each line of assembly code was 32 bits that you could have 496 lines of assembly code (maybe minus 1 or 2 for the min spin code).

Ariba

What you see in this HEX display is the content of the MainRAM. You are right in that every line shows 16 bytes = 4 longs = 4 instructions, but you don't know where the Assembly code begins. The IDE compiles all the Spin code, Assembly code and Datas to one big HEX file that is written to the MainRAM. If you start a new Cog with an Assembly code, the right part of the MainRAM is copied to the CogRAM. So in the CogRAM the Offset is different from what you see in the HEX display.

If you like to see how the CogRAM looks and what is going on in a Cog, I suggest you to use PASD:
http://forums.parallax.com/showpost.php?p=0

Andy

Neighborhood Physicist

Thanks Andy,

The tool looks great and I am sure it will help alot.

Neighborhood Physicist

I don't understand the HUB interaction with the cogs.

The doc says that each cog gets access to the hub every 16 cycles.
A hub instruction is supposed to take 7 cycles with possibly an extra 15 waiting for the hub.

What I don't get is what happens if more than one cog is writing to the HUB?
Does this mean that up to 3 cogs can access main memory at the same time?
Why not let all 8 cogs access memory and get rid of the hub?

Thanks.

Neighborhood Physicist

Yet another question.

If I have a 1M eeprom attached to the chip, can I, on the fly, change a portion of the 32 KB of RAM memory. This could allow you to load code into the cogs and then replace that code in main memory.

Neighborhood Physicist

You could extend this to have several eeproms that serve as a function libraries that can be pulled into main memory for execution on the cogs.

This would be a great feature.

Mike Green

1) Each cog is assigned a specific 2 clock slot in the 16 clock cycle, so all 8 cogs could access the hub in one hub cycle as long as they all attempt access in the proper timing window for that hub cycle. Remember that that cogs are running at full speed (one instruction every 4 clocks for most instructions). Cogs can be synchronized to a specific relationship to the system clock using the WAITCNT instruction, so it's not hard to set up for "simultaneous" access to a specific hub cycle.

Any kind of memory, unless it's specifically designed for multiple read/write accesses, can only handle one read or one write at a time. For multiple accesses, you have to have multiple copies of the address decoding logic, read/write logic, wiring into and out of the data array, special logic to detect and deal with simultaneous access to the same memory cell (if the addresses are the same), etc. The hub memory doesn't have any of this because the hub logic only lets a single cog access it at any one time.

2) Think of the hub memory as a special purpose internal I/O device while an EEPROM is an external I/O device. A cog processor can copy data from one I/O device to another under control of a program that handles the details. A program running on a cog can also just copy data from either kind of memory to its own local memory. It's impractical to do this as you describe (paging in stuff from EEPROM) only because of the amount of code required to handle I2C EEPROMs and the low speed. It would be pretty easy to do this from hub memory and the "Large Memory Model" is designed to be able to do this ... read the thread on it. The initial release of the C compiler from Image Craft won't do this, but later releases might.

Neighborhood Physicist

Thanks Mike,

I will take a look at the Large Memory Model thread.

deSilva

Neighborhood Physicist said...
I will take a look at the Large Memory Model thread.

Still, you should clarify your concept of how the Propeller works before...

said...
...into main memory for execution on the cogs.

This makes no sense....
WITHIN a COG an assembly program - which is contained in the COG memory - is executed by the COG CPU.
That's all!

The COG is not in the least interested in things like HUB or EEPROM. It can access them, after some effort (RDLONG etc. or some INA/OUTA instructions)

I think Rayman explained this very well and concise in the second posting of this thread...

Edit: Improved my grammar

Post Edited (deSilva) : 11/2/2007 11:06:17 PM GMT

Neighborhood Physicist

It looks like this is already being done with the hydra and the large memory map.