Cog <- 496?
Rsadeika
Posts: 3,837
In a lot of the threads, the number 496 has been referred to, but what does that really mean. Below is a program I just started to put together, just to see how that works out in terms of cog ram. I am using BST, so I used the 'Compiler Information' command to get the following:
Program: 369 longs
Variable: 178 longs
If I am interpreting the information correctly, I come up with a figure of 127 longs available for the program. I still need to add access to an SD card reader, and an RTC module, plus whatever code, in the main program, to make it all work. Hopefully this gives a real example of what, and how fast the cog ram gets used up.
Just from this casual exercise, I can see that my project, using Spin, will probably not work out. So, what do I do now? I guess there are no easy answers, I guess I could spend a lot of time trying to balance out the code between other cogs, but the availability of cogs is getting slim to. I could go with C, because of the LMM, but there is no equivalent for "IR_remote", any kind of SD card reader programs, and whatever else that would come up.
I am NOT slamming the Propeller, just trying to get a good idea of what are some realistic programs that can be done with it. It is not the first that I would have put in a lot of time, and resources just to find out that you have run out of memory, or the clock speed is not fast enough to get the job done. Hopefully, for the beginners, it will give them a more realistic picture as to what can be done with the Propeller. If anybody sees a flaw in my logic, please state your case.
Ray
Program: 369 longs
Variable: 178 longs
If I am interpreting the information correctly, I come up with a figure of 127 longs available for the program. I still need to add access to an SD card reader, and an RTC module, plus whatever code, in the main program, to make it all work. Hopefully this gives a real example of what, and how fast the cog ram gets used up.
Just from this casual exercise, I can see that my project, using Spin, will probably not work out. So, what do I do now? I guess there are no easy answers, I guess I could spend a lot of time trying to balance out the code between other cogs, but the availability of cogs is getting slim to. I could go with C, because of the LMM, but there is no equivalent for "IR_remote", any kind of SD card reader programs, and whatever else that would come up.
I am NOT slamming the Propeller, just trying to get a good idea of what are some realistic programs that can be done with it. It is not the first that I would have put in a lot of time, and resources just to find out that you have run out of memory, or the clock speed is not fast enough to get the job done. Hopefully, for the beginners, it will give them a more realistic picture as to what can be done with the Propeller. If anybody sees a flaw in my logic, please state your case.
Ray
'' Prop0.spin
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
IRdetpin = 0
VAR
long IRremstack[noparse][[/noparse]40]
long CBdevstack[noparse][[/noparse]40]
long BTdevstack[noparse][[/noparse]40]
byte IRcode
OBJ
IRrem : "IR_Remote"
misc : "tools"
ser : "FullDuplexSerial"
PUB Main
cognew(IRremote, @IRremstack)
cognew(CBdev, @CBdevstack)
cognew(BTdev, @BTdevstack)
PUB CBdev
ser[noparse][[/noparse]0].start(5,6,0,230400)
repeat
PUB BTdev
ser.start(7,8,0,57600)
repeat
PUB IRremote | cog, scode
cog := IRrem.start(IRdetpin, @IRcode)
if cog > 0
repeat
if IRcode <> IRrem#NoNewCode
scode := IRcode
IRrem.Start(IRdetpin, @IRcode)
case scode
IRrem#power : Pwr_btn
IRrem#chup : Ch_up
IRrem#chdn : Ch_dn
IRrem#volup : Vol_up
IRrem#voldn : Vol_dn
IRrem#mute : Mute
IRrem#last : Last
IRrem#one : One
IRrem#two : Two
IRrem#three : Three
IRrem#four : Four
IRrem#five : Five
IRrem#six : Six
IRrem#seven : Seven
IRrem#eight : Eight
IRrem#nine : Nine
IRrem#zero : Zero
IRrem#sleep : Sleep
IRrem#enter : Enter
IRrem#tv_vcr : Tv_vcr
IRrem#menu : Menu
PRI Pwr_btn
LED1
PRI Ch_up
LED1
PRI Ch_dn
LED1
PRI Vol_up
LED1
PRI Vol_dn
LED1
PRI Mute
LED1
PRI Last
LED1
PRI One
LED1
PRI Two
LED1
PRI Three
LED1
PRI Four
LED1
PRI Five
LED1
PRI Six
LED1
PRI Seven
LED1
PRI Eight
LED1
PRI Nine
LED1
PRI Zero
LED1
PRI Sleep
LED1
PRI Enter
LED1
PRI Tv_vcr
LED1
PRI Menu
LED1
PRI LED1
misc.high(1)
misc.waitms(250)
misc.low(1)
Comments
So the 496 is not relevant for your SPIN code, even if you start a function in a new COG. Because SPIN functions are not started themselves. A SPIN interpreter is started instead and this will execute your function.
In SPIN you can use the whole HUB RAM·as program code if you want - and if you don't need variables ;o)
If you look at the list file window in bst, when you compile your application, for each FIT statement it will tell you in the listing right under the FIT how many longs you have free in the cog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Yes, vga, keyboard, sd card, serial, rtc and suddenly there are not very many cogs left. So it is all about optimisation. The propeller probably can do what you want but will need some lateral thinking. For example
looks very much like serial code, and am I guessing right by suggesting you are loading the code twice - and that is taking two cogs? If so, there is an object which can drive 4 serial ports in one cog.
Of course, the 'main' program in spin is going to have a lot more longs free (what is it, 32 kilobytes which is 8 kilolongs?) And there are optimisations to load cogs and reuse the hub space. And with one external ram chip you can easily add 512k (128 kilolongs) and catalina c and CP/M running C or Basic can exploit that extra space.
But going back to basics, I'm looking at the statement
"together, just to see how that works out in terms of cog ram. I am using BST, so I used the 'Compiler Information' command to get the following:
Program: 369 longs
Variable: 178 longs"
I think BST is reporting the space used in total, and that is the total out of 8192 longs, not out of only 496. So I think you still have lots of code space left [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
In this context, bst is supposed to report precisely what the Propeller Tool reports. The nice blue bit at the right end of that bar show the free/stack space. General rule of thumb. Some blue is good, more blue is better.
Program: 369 longs
Variable: 178 longs
Works out to 2.3k from 32k.. loads of space free. You are metaphorically rattling around the dance hall on your own. The band and crowd has already left and you have plenty of space.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
So, my program is dealing with hub ram, which is part of the 32KB that is available. The part that I should really be looking out for is if, and when I want to implement assembly code, within a cog? Does my logic lead me to the conclusion that when you are developing a strictly assembly code program, you have to worry about the 496 longs restriction per cog? Even if you were a super-duper assembly programmer, that does not leave you with a lot of memory to work with. Is this what the controversy is all about?
Ray
Your questioning will lead you to enlightenment.
The Prop has 32KB of HUBRAM. In addition, each cog has 512 LONGs of RAM, of which 496 are available for program/memory space. With SPIN programs an interpreter is loaded into a cog. If you launch a new cog with a SPIN program then the interpreter is used. The interpreter fits within the 496 and reads the program out of HUBRAM, which is kind of slow. If you launch a new COG with an ASM routine the ASM routine will need to fit within the 496 longs. ASM routines execute really fast, but timing for reading HUBRAM is important.
I don't consider myself an expert, but I write a lot of ASM drivers and programs and haven't had trouble with the 496 constraints. The programs I am doing probably don't tax the system a whole lot either.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com
Simplistically that is right. Spin can use the entire ram (except a bit for variables and stack), but the PASM in each cog is practically limited to 496 longs. Now this is less of a problem that it might seem, but you only discover this when you get to writing PASM.
Yes, PropBASIC right now generates native PASM code, so each TASK is limited to 496 longs. Again, this is not quite the limitation it might seem because as much of a hack as a BASIC to PASM translator might seem, it is *very* clever code that creates some nice assembler.
Now, having said that, later in the year PropBASIC will generate LMM code. LMM is a clever kludge where you can fill the hub with assembler code and execute it from within a cog. It's a bit of a three legged dog. It's a bigger than spin (so you fit less code in the hub) and it's slower than PASM, so it's kinda a halfway house. The C compilers use LMM (or XMM, but that's a whole other complex story).
Yes, and as I said above. You really can fit a metric crapload of code into 496 longs x 8 cogs if you are thinking along the right lines. It's just not as limiting as people might have you believe.
Having said that, the Prop is not a magic bullet. If you have an application that needs stuff the prop does not do natively, you are *really* better off using the right tool for the right job.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
· This limitation was recognized early on, but I wanted PropBASIC to generate native PASM code so you could write video drivers and other FAST code with it. You might be surprised how much PropBASIC code will actually fit within the 496 instruction limit.
· LMM in PropBASIC is implemented, but not·tested or documented (and won't be until AFTER the initial public release of version 1.0). But if you want to play around with it simply append LMM to the end of the PROGRAM line. Like:
PROGRAM Start LMM
Each task can also be either native or LMM by appending LMM to the end of the "TASK taskname" line. Like:
MyTask· TASK
TASK MyTask LMM
·· ' code here
ENDTASK
LMM code runs much slower (about 5 times slower than native PASM), but still beats the pants off spin.
See this thread for more information http://forums.parallax.com/showthread.php?p=878924
Bean
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
Post Edited (Bean) : 2/24/2010 2:52:18 PM GMT