Feasibilty: Cogs as storage areas
RiJoRi
Posts: 157
This is NOT for a project. It's simple curiosity.
Would it be possible to use cogs for storage? That is, each unused cog would have a reader and a writer routine, and the working code would do something like "IndexX=WriteCogX(longDatum)" or "longDatum=ReadCogX(IndexX)" or something like that. Of course, error checking and limit testing would be needed.
--Rich
Would it be possible to use cogs for storage? That is, each unused cog would have a reader and a writer routine, and the working code would do something like "IndexX=WriteCogX(longDatum)" or "longDatum=ReadCogX(IndexX)" or something like that. Of course, error checking and limit testing would be needed.
--Rich
Comments
Since the PropII is about one year away (see Chip's recent video), any techniques to increase fast RAM space such as this will be valuable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Post Edited (James Michael Huselton) : 5/21/2009 7:10:38 PM GMT
So yes. But you might have to be desperate for space to to it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thanks MagIO2, I've fixed the bug. (One I've made before, and will probably make again - you'd think I'd learn.)
The amount of fuss this topic has generated is ... amusing.· I whacked out this routine just to show one way it could be done - a minimal but functional version.· (Actually, this is the second version, but I think only JMH saw the first one.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: http://forums.parallax.com/showthread.php?p=800114
NTSC color bars (template): http://forums.parallax.com/showthread.php?p=803904
Post Edited (ericball) : 5/24/2009 10:25:16 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
--Rich
that's of course a nice exercise, but I'd prefere to use erics version ... after only a minor change. I'd let the PASM routine set the adress back to 0 after it did it's job, so the program that needs the extra RAM does not have to take care of stopping the PASM to overwrite the HUB/COG-RAM again and again.
The problem I have with your version is that it adds a lot of overhead and needs more COG RAM. RAM access should be as fast as possible. Erics version is presumably fast enough for SPIN that you can use the copied value with the next SPIN instruction after setting the adress. Your version uses extra getter and setter functions which only waste time and HUB-RAM.
I prefer clarity over clever, and as I stated this was a programming exercise for myself and possibly to help others learning to mix PASM into Spin programs. I made no claims about it other that I tested it and it works. And, finally, it does in fact do what the original poster asked for (write and read longs with named routines).
If you're going to lay into someone with unsolicited criticism perhaps you should have the decency to post working code. Talk is cheap.
Jonny,
Although Mag's posting seems critical, I do not think he was trying to be. I presume he was only pointing out areas which may be improved. I find Mag is typically helpful, or has been for me in the past.
Everyone seems to be on edge lately. I hope everyone can settle down and be more flexible.
James L
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer
Lil Brother SMT Assembly Services
Please note: Due to economic conditions the light at the end of the tunnel will be turned off until further notice. Thanks for your understanding.
{{ Exchange data between hub and cog. cmdaddr points to a single long: w000000c_cccccccc__hhhhhhhh_hhhhhhhh, where w = 1: write data to cog; w = 0: read data from cog; c_cccccccc = cog address; and hhhhhhhh_hhhhhhhh = hub address. The entire long should be assigned at once, not as two separate words, e.g.: command := WRITE | cogaddr << 16 | @hubvar, where CON READ = 0 WRITE = $8000_0000 Once the transfer is made, the command is zeroed. }} VAR byte cog PUB start(cmdaddr) stop return cog := cognew(@hubxcog, cmdaddr) + 1 PUB stop if (cog) cogstop(cog - 1) DAT org 0 hubxcog rdlong outa,par 'Read command. mov frqa,outa 'Write source address to bot transfers. rol outa,#16 wc,wz 'Swap words in command. Carry is high bit of cog addr. :xferin if_c_and_nz rdlong outa,frqa 'If command is non-zero and carry set, transfer data in. :xferout if_nc_and_nz wrlong outa,frqa 'If command is non-zero and carry clear, transfer data out. if_nz wrlong dira,par 'If command is non-zero, zero it. jmp #hubxcog 'Back for another command.-Phil
I appreciate you comments, James, but will say that it is NOT helpful for anyone to post criticisms without demonstration that the criticism is something more than opinion. That said, it takes time to write working code and no time at all to run someone else's work down. It's rude.
Look, I'm new to the Propeller and freely admit it; I write programs for others as a way of stretching my own programming muscles. But this isn't the first time that something I've posted has been met with an snobby reply, and I don't need it -- that treatment is not in the spirit of the way these forums (overall) have worked in the past. I think I'll just do my experiments at home and save what I create for my Nuts & Volts column; this forum (outside of Phil and a couple others) seems filled with a group of people who want nothing more than to prove how clever they are. And I thought the Propeller was supposed to be fun....
If one needs to use COG registers for storage it seems important make the handler routine as small as possible.
Clarity would be less important unless maybe you're writing an article for Nuts & Volts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
dira is only used as a zero and will always be zero. It never gets written to. The B registers would work, too.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Maybe it's an occupational disease that you can not withstand criticism - but you posted in a forum. If you don't like what might come as a response, then DON'T POST!
I think I started very good, didn't I? And what came after that was by no means harsh or degrading, I only said my opinion AND I think each other who's learning should be aware what the drawback in your solution is. If you don't take care of execution speed and/or HUB/COG-RAM usage, then fine ... your version works as well without any doubt.
If you only light some LED's you can easily say so. But even you propeller would not run with clever programming - e.g. have a look at the spin interpreter or the FullDuplexSerial. The propeller has been designed to do clever things with it (but it will also work for you.)
Erics code is working, isn't it? (besides the little bug) So I can't see a reason to post it again. But I think you refere to
well ... that shows that you don't understand Erics version at all ... but somehow that fits to "I prefer clarity over clever".
Let me explain it:
Erics version is simply an endless loop. You start it with giving an adress of 2 longs. Each long holds a HUB-RAM and a COG-RAM adress. The first long is used to copy from HUB to COG, the second is used to copy from COG to HUB. If one of these longs equals 0 that particular copy is skipped. As the PASM itself does not set the longs to 0 after the job, the code outside of the COG has to take care of that. If it's some SPIN code·setting the long to 0·would increase runtime much more than letting the COG set the long to 0 itself. If you are not clever enough to add 2 wrlong to Erics code, let me know and I'll provide a version including some demo-code.
Now I got a little bit harsh ... but you asked for it.
I know others here which do not post much appreciate you and others like you who openly share their experience and code. I too appreciate people who do share their code, although I have not "borrowed" any of yours as of yet.
I agree, you make a valid point. Coding does take time, and talk is cheap.
I personally find the majority of the members here are very willing to help, and knowledgeable. There is always going to be a percentage of members who "one up" the next or criticize someone else.
I try to bridge the gaps, and keep the conversations friendly, especially if I know the offending poster does have the knowledge to help.
I still find fun with the propeller, and know others do as well.
James L
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer
Lil Brother SMT Assembly Services
Please note: Due to economic conditions the light at the end of the tunnel will be turned off until further notice. Thanks for your understanding.
Another nice version. Eric's version is still interesting if you have two SPIN COG's running. One can write to the RAM, the other one can read from it simultaneously. Would make a good FIFO buffer.
This is my *problem* -- most of what I write has to be explained, in detail, for others. The tragedy (my opinion) of this forum is that there are great programmers who don't seem to want to document or fully demonstrate their code; that makes it tough on those of us with less experience who are trying to learn from it. What's obvious to one person isn't always obvious to another.
I will push on. I've never claimed to be the sharpest tool in the shed and it may take me longer to get it that the rest of you.
Jonny,
Don't feel alone. I'm about as sharp as a spoon, most of the time.
I too find the same problem as you, when reading others code. I even have a hard time when it's documented to death. If you don't believe me, ask Mike Green. I had to ask him how to use one of his objects, and he tends to document pretty well (my opinion).
James L
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer
Lil Brother SMT Assembly Services
Please note: Due to economic conditions the light at the end of the tunnel will be turned off until further notice. Thanks for your understanding.
Oh, boy! I bet I've broken one or two forum taboos with that admission!
-Phil
Now........Into the dungeon with ye!!!!
Yea....but some of us can't compete on the "one up" combat. I can't "one up" anyone. I guess I'll have to watch.
James L
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer
Lil Brother SMT Assembly Services
Please note: Due to economic conditions the light at the end of the tunnel will be turned off until further notice. Thanks for your understanding.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
@Steve: You're "clarity" comment was understood in the spirit it was intended.
@Phil: You do post some crazy code that sometimes makes my head spin (no pun intended), but to your great credit you always add comments that give us mere mortals a fighting chance to figure it out. Thank you for that.
It turns out that -- with the small fix pointed out -- Eric's code does indeed work (nobody's surprised). I've attached a demo that uses Eric's PASM code but I've changed the interface a bit after seeing the way Phil did it; this just seemed a little safer to me. For you guru's (who are not interested in beating me about the head and neck) please let me know if I've erred in the comments added to Eric's code. Thanks.
Post Edited (JonnyMac) : 5/24/2009 12:26:58 AM GMT
I had to go look up venal in wikipedia
Mag, I appreciate your explanation of eric's code. I didn't think you were being upity the first post, but even being bad because you were falsely accused of being bad isn't justified.
Jonny, check out http://forums.parallax.com/forums/default.aspx?f=25&p=8&m=343952. mctriva did an excellent job at getting back to the issue even though he was attacked. The attacker later came back with some useful contributions, and it worked out well for everyone involved.
It's a bit of a long thread, but it is a good example of clash mitigation.
Just my 10 bits worth.
Doug
You should have left Erics header in the code, you can see on a first glance how to pass the parameters instead of reading the whole code.
Now only one exercise is left: Eric's Code is running in an endless - loop. So, if you don't clear the adress-pointers after the value has been copied, the COG will copy it again and again. This is error-prone as it can possibly overwrite a value that has been updated by the SPIN-code meanwhile. If the COG set's the adress to 0 after the copy-job, this is no longer a problem as it copies the value only once. That's what the Z flag is good for. Of course the loop will be a bit slower, but it's still faster than setting the adress-parameters to 0 in the SPIN-code.
What I'd be interested in is,·does the inval have the correct value in the next SPIN-instruction already or do you have to wait for it for a short while?
This piece of code can be very useful in case you want to/have to divide data collection from data processing in a so called First In First Out manner. One COG is busy with reading data from ... dunno .. the serial interface in high speed. So no time is left to process the data without loosing the next characters. Then it could simply write into this COG and another SPIN-code running in an additional COG can get the data from there and process it.
Post Edited (MagIO2) : 5/24/2009 6:48:34 PM GMT
Here's an idea: Along with your theories and criticisms, why not post some code for the rest of us to learn from?... Tested code, that is.
[noparse][[/noparse]Edit] I'm not sure what caused the problem yesterday but today's a new day so I went back and tried Eric's header again. Today I made sure that I set the destination for either call first; I don't know that I had done this yesterday and this may have caused the program to overwrite something critical and hang the program.
Post Edited (JonnyMac) : 5/24/2009 9:05:30 PM GMT
This is what I meant with Eric's header ... well my mistake it's not the header of the file, but the header of the PASM section. I think keeping this comments helps in understanding how the parameters work.
org 0 [color=green]cogstart mov outa, par ' get address of wrcommand rdlong outa, outa wz ' hub --> cog command? (not 0) movd hub2cog, outa ' cogdest is dest field for rdlong [/color] [color=red]if_nz wrlong ctra, par[/color] [color=green] shr outa, #16 ' outa := hubsrc[/color] [color=green]hub2cog if_nz rdlong 0+outa, outa ' cogdest <-- hubsrc mov outa, par add outa, #4 ' point to rdcommand [color=red]mov outb, outa[/color] rdlong outa, outa wz ' cog --> hub command? (not 0) movd cog2hub, outa ' cogsrc is dest field for wrlong [/color] [color=red]if_nz wrlong ctra, outb[/color] [color=green] shr outa, #16 ' outa := hubdest[/color] [color=green]cog2hub if_nz wrlong 0+outa, outa ' cogsrc --> hubdest[/color] [color=green] jmp #cogstart[/color]That's how I would have changed Eric's code. (And now I did ;o) The green part is the original code. As I already mentioned it's an endless loop and it's much faster than the SPIN code. Each time it fetches the wrcommand or the rdcommand it set's the zero-flag. So, if the wr/rdcommand is 0·the according value is not copied at all. In Erics version the SPIN code has to clear wr/rdcommand to avoid the PASM code to overwrite data again and again. In my modified version the PASM-code set's the wr/rdcommands back to zero itself. So in the next loop it won't copy again unless it get's a new adress from the SPIN-code. If you have some other PASM program which uses this RAM-COG, then it's even more helpful, because then this can be used to synchronize both COGs. PASM COG sets an adress and waits until the RAM-COG set the parameter back to 0. Then the PASM COG can be sure that the value has been copied.
And .. I tried the usage of the COG-RAM with your SPIN-test-program. And the PASM-code is really fast enough to copy the data in 'no spin-time' ;o) So, the invar can directly be used in the next SPIN instruction. Please have a look at the attached modified version of your code. I added a cpyinvar and asssigned it the value of invar straight after setting the rdcommand and it got the right result - no failures.
.... have to go to bed now ... have a nice day/night ... whatever ... CU
Post Edited (MagIO2) : 5/25/2009 1:52:35 PM GMT
@JohnnyMac - if you update hubsrc before cogdest then you will probably overwrite the copy code (kaboom!) since it sits at cogdest := 0.
To a certain extent, the code I made is just a starting point. It lacks any kind of handshaking required for use by multiple hubs. Instead it's the absolute minimum required to do the job (store data in HUB RAM and later retrieve it). On the plus side, this maximizes the amount of storage available and the speed of operation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: http://forums.parallax.com/showthread.php?p=800114
NTSC color bars (template): http://forums.parallax.com/showthread.php?p=803904