cogs ram size
Guyvo
Posts: 21
Hi propellers,
I was wondering since I just started with the propereller chip how much RAM size of the 2K individual of the cogs is free to use ? Because I red that the spin interpreter is running off from there and I saw in the code examples that there can be still some memory allocated with "RES" into the RAM.
Thnx
Guy
I was wondering since I just started with the propereller chip how much RAM size of the 2K individual of the cogs is free to use ? Because I red that the spin interpreter is running off from there and I saw in the code examples that there can be still some memory allocated with "RES" into the RAM.
Thnx
Guy
Comments
firstly the 2 K byte RAM of each Cog is organized as long words and can only addressed by long. There are 512 long words, but the last 16 long words are used as special purpose registers. So you can have 496 long words for code and data if you program in assembly. If you would use Spin for your program the interpreter is located in the Cog and gets the tokens from main RAM.
You can use the RES directive only if you are coding assembly.
Thomas
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
So in fact 2048-16 reserved bytes are free to use alligned as LONG of course if the program is written in assembler. The interpreter code belongs to the cog internally and needs no cog RAM for execution. So a maximum memory example would be:
A combined program of SPIN and asm code written for all 8 cogs gives:
508 LONGS / cog (code/data) X 8 cogs = 4064 LONGS in asm written
8192 LONGS for the written spin code/data (full 32K RAM)
So we have a total of 32K + (2032 * 8) = 32768 + 16256 = 49 024 bytes totally free to program
Did I understand this well
Guy
The last 16 long words of each cog's ram are reserved for control registers. Some of these words can be used for data (as "shadow" registers) in restricted circumstances. When these read-only registers are accessed via the destination field of an instruction, the "shadow" register is accessed rather than the control register. In addition, if you're using the Spin interpreter in any cog, the first 16 bytes of hub memory are expected to contain some control information. Specifically, when the Propeller is initially loaded from the PC or EEPROM, a Spin interpreter is running in one cog and a minimal Spin program is about 32 bytes ... one that starts up an assembly routine in the same cog from the next 512 long words in memory. This assembly routine can use all of hub memory. With these exceptions, all of hub and cog memory is available for you to use as you wish.
if you want to know how much memory you could use for code and data then your calculation is wrong.
A Cog has 512 long words (512 * 4 byte = 2 K byte) whereof the last 16 longs are used as control registers. So you have 496 longs (= 1984 bytes) per Cog.
The main memory is 32 K byte of RAM whereof the first 16 bytes are used for control information.
So you could use (32768 - 16) + 8 * 1984 = 48624 bytes for code and data.
But in real life you can use less than (32768 - 16) bytes because you need some space for runtime data in main memory like stack for the Spin interpreter. The code for a Cog is also located in main memory after start of the Propeller and will be copied at runtime into the Cog.
Thomas
Each Cog has 496 long words which can be used however you want, all of them. That not used for Cog program code can be used for Cog data.
Program code and any pre-initialised data ( but not RES defined variables ) to be loaded into a Cog takes up some space in the Hub ( 32KB ) memory. How much Hub memory is used depends on how much Cog program code and pre-initialised data there is.
You must understand that I come from AVR/ARM and intel embedded so this kind of program style and memory organisation is a bit odd to me at first. But with all your replies it is started to get a bit clear. Before I want to dive in to programming (quit a nice language i must say and I saw a lot of languages yet
Yes i made a small mistake in my previous calculation but the main line was correct so I think I get the picture right now.
So to finalize this thread this is what I learned:
THE 2K /COG RAM names naturally the COG RAM
-last 16 longs reserved control/shadowed
-only assembler CODE/DATA
-DATA must be in the form of RES LONG
THE 32K RAM names HUB RAM (shared over all cogs )
-first 16 bytes information startup PC/EEPROM (applicable on COG 0 i presume)
-mixed SPIN /ASM CODE/DATA possible
-DATA must be pre-initialized (VAR / DAT section fi )
-no RES here
I already found a good abbreviation for IPC here we can say ICC with the LOCKED mechanism
Guy
you are certainly right, that some chapters in the manual would have needed some more attention. I shall try to cover this in further chapters of my tutorial..
You are certainly not right with the summary you gave; still too many misunderstandings
From the side of Spin, there is only one memory, that is shared by 8 Processors (cogs). These processors run spin programs, translated to intermediate code, stored in successive areas in the global memory. The processors fetch these commands one by one and execute them with help of a microcode: the spin interpreter. So the cog are virtual spin machines. (similar to a JAVA virt.mach.) For the execution of a spin command takes sufficient time, the processing is not slowed down by the fact, that access to main memory can only take part in a round robbing way.
Instead of running the virtual spin machine, a cog can run machine code. This code together with necessary data storage loaded to the main memory an than transfered to the cog. After transfer to the cog, the storage for the assembler program in main memory can be used for other purposes. Any data elements of the assembler program, that have not to have initial values, can be located at the end of the assembler program by "res" The elements so have fixed addresses, but during the loading process they do not exist physically. The next object follows immediately after the last initiated memory cell of the predecessor.
The explanation and comparison with JAVA virtual machine was certainly very clear to me coming from another chip world.
I will post later on a small code snippet with some comments on how I think the flow is worked out inside the propeller. This is perhaps the best way for me to get the all picture. But now I see that every asm section from ORG till end will be transferred to the 2K RAM on per COG basis. This memory comes free in the 32K RAM and can be allocated to serve other things. Quit a good approach ! I already understood the fact of not depending on any scheduling algo like RR to be a loss in performance while executing the 8 COG's simultanously. ( except for the HUB time window of mutual exclusive resources in worst case 22 cycles page 7 in datasheet )
And the RES thing is also clear now that it's just a reservation to finally allocate space after the code when transferring the section to 2K RAM which can later be address linked but in the meanwhile we can refer them in the asm code this way is only possible by uninit data of course.
The propeller community lives I must say !
Thanks all to take some time for a newbieeeee (in PROP world thoug
PS
for DiSilva let me know where I can find your tut, useful work I think with lots of added values for someone like me
Regards and cheers
Guy
Like this:
ORG 0 ‘ start over “counting cells” at 0
FIT n ‘ rise alarm when the recent cell count surpasses n
RES n ‘ increment the cell count by n without allocating HUB memory
Things like such a tutorial can get a place in the manual if you ask me. Also the Tips and Tricks thread is a candidate.
The tutorial is easy to find on the forum if you do a search on "tutorial"
Guy