file directive in DAT section in old Spin 1 and old fastpin vs spin 2
ke4pjw
Posts: 1,169
I am updating one of my old programs that was written when the P2 was Rev. A silicon. It was written with fastspin's implementation of spin 2. I am pretty sure that both fastspin and spin 1 would load file data into the hubRAM. Now I am getting an error that a relatively large amount of data will not fit. (12k) Do I need to do an orgh above the file directive in order for it to load into hubRAM?
Comments
I must do an orgh to get it to load into hubram. If performed within an org, does it load the file into cogram? It feels like it does it, based on the error I got. Curious minds want to know
Hardly anything is loaded into cogram by default, it has to have a coginit. But if you put something in an ORG section it does try to make sure it will fit in cogram when it does get loaded, and not many files are small enough to fit.
Ok, so if the file was small enough, would it load into cogram? Just curious because I am working on some old code from the flexgui/fastspin days. It was griping that the file was too big, until I added the orgh directive above it.
In the P1, the FILE contents -- and everything else in the program -- load into hub RAM. They only get loaded into a cog on a COGNEW or COGINIT. I assume the same has to be true with the P2. I mean, how would the loader know ahead of time which cog to load it into?
-Phil
Good point! However, based on the error message, I suspect it will copy the file contents into the cog on COGNEW or COGINIT following an org statement, and not with an orgh statement.
FILE is just like BYTE, really. That is, if you have a file called "greet.txt" that contains just the string "hello" with a carriage return and line feed (so it's 7 bytes long), then the two statements:
and
will mean exactly the same thing. So yes, FILE can go in an ORG section to indicate some data that should go in COG memory, just like BYTE can. At least, that's the case in FlexProp, and I'd be shocked if it's any different in any other compiler.
Terry,
Your surmising is correct in that a FILE directive following an ORG directive tries to fit the binary file data specified to cogRAM address ranges. And a FILE directive following an ORGH directive tries to fit the binary file data specified to hubRAM address ranges. But there is a couple of technicalities:
1: The fitting process is at compile time. An obvious statement I know but this means the error is from the compiling rather than loading of any file into the Prop2.
2: When actual loading takes place it's 100% into hubRAM. Only after that does execution of the program start. And first execution step is the loader issues a COGINIT. What COGINIT does is to copy a contiguous block of 504 longwords (496 in the Prop1) from hubRAM into cogRAM and then begin executing that code. The block may or may not include data from a FILE directive, COGINIT doesn't much care, it just copies the data from hubRAM.
PS: This is for pure Pasm2 now I think about it. I have no idea if FILE directive has meaning in Spin.