Object exceeds runtime meory limit by 1 long, dat and assembly
TransistorToaster
Posts: 149
Hello,
I'd like some advice on how to solve this problem. I've been programming in assembly for a couple cogs under this pattern:
I am getting the compiler error of "object exceeds runtime memory limit by 1 long" but I am not overpopulating. Each cog has 512 longs and I take up about 75 longs in data and nowhere close to 400 lines of instructions in the assembly code. Since I use the ORG 0 statement at the beginning of each block, I would expect the compiler to properly think that each block is meant as an assembly program plus ram space and restart the counting to check that I don't exceed 9bits=512 longs when referencing registers in the instruction s and d fields; although I could be mistaken.
The overall profile (F8) says I still have a lot of room:
Prog 1693 longs
Var 317 longs
Stack/Free 6178 longs
What is wrong?
Frank
Post Edited (transistortoaster) : 3/23/2007 3:52:09 PM GMT
I'd like some advice on how to solve this problem. I've been programming in assembly for a couple cogs under this pattern:
DAT ORG 0 asmprog1 ... RES VAR1 1 ORG 0 asmprog2 ... RES VAR2 1 ORG 0 asmprog3 ... RES VAR3 1
I am getting the compiler error of "object exceeds runtime memory limit by 1 long" but I am not overpopulating. Each cog has 512 longs and I take up about 75 longs in data and nowhere close to 400 lines of instructions in the assembly code. Since I use the ORG 0 statement at the beginning of each block, I would expect the compiler to properly think that each block is meant as an assembly program plus ram space and restart the counting to check that I don't exceed 9bits=512 longs when referencing registers in the instruction s and d fields; although I could be mistaken.
The overall profile (F8) says I still have a lot of room:
Prog 1693 longs
Var 317 longs
Stack/Free 6178 longs
What is wrong?
Frank
Post Edited (transistortoaster) : 3/23/2007 3:52:09 PM GMT
Comments
Placing one org per Dat section cured it. Also it may be just a typo but the assembly var declarations are :
Yes, I just typed up erroneously the same var identifiers here. That is not legal to do.
>Placing one org per Dat section cured it.
i tried that right now, without improvement.
Just to clarify, the 512 longs is the combined total of space not just ram or program. So it may be that your routine is taking up the space.
Other than that I guess I would be scratching my head too!
The combined plus a couple of cog specific special function registers, so I should say a tad less than 512
Right now, I don't see the logic of an ORG 0 directive before the variables. They can't be starting at zero address because they are following the assembly instructions in the 512 longs block.
I just call it from my Top Object File and forget it.
>might be a problem is the use of RES, then ORG in the same DAT section.
Could you explain with more words please? I have more than one program in the dat section.
EDIT: I replicated the error, it appears when the total amount of VAR+PUB+DAT memory used exceeds 32KB. I'm also interested in how you could view the 'Overall Profile' if you get a compile error - did you comment something out? something huge?
Post Edited (Jasper_M) : 3/23/2007 4:49:46 PM GMT
On p107 it's written
[noparse][[/noparse]quote]
To run Spin code, the new cog needs some run-time workspace, called “stack space,” where it can store temporary things like return addresses, return values, intermediate expression values, etc.
Each time I start up a new assembly program, I do cognew(@asmStart, @var), where var is a single long that I use to pass information between the spin program that requested the assembly program to start on a new cog. In the propeller manual on p 189, it talks about passing a pointer to stack space. On p107 it says that 9 longs were enough for a led blinker program. Now, I don't see the concept of stack in the assembly, but I wonder could that have anything to do with a runtime memory error flagged by the compiler?
My comment was based on the fact that RES causes the cog address counter in the assembler to increment, but not the DAT address counter. That's why a RES can only appear at the end of a cog's code. It shouldn't affect anything if you follow the RESs with an ORG.
Again, I suspect the problem is in the stuff you didn't show in your posting.
Could the org 0 be the problem?
"org" is just a shorter way to write "org 0" , so it shouldn't be.
I commented out the drops that made the vase overflow.
Post Edited (TransistorToaster) : 3/23/2007 6:38:33 PM GMT
EDIT: Sorry, I didn't notice the first one of those two posts.
_stack = ($3000 + $3000 + 100) >> 2 'accomodate display memory and stack
This is like 3/4 of whole RAM. So you have VERY LITTLE space left actually - remember that the free space is Stack/free - and the stack takes 24KB.
EDIT: No, wait, I understand now - it just prevents the stack from expanding on the buffers.
And this is the source of the problem - I created the error by adding stuff, then removed it by subtracting the number of longs from _stack. So it really means it's an out-of-memory case.
I was meaning to ask at point point where all the RAM is allocated for the video memory. I could use the video mode that has no buffer (i.e. direct drawing to the screen) and recover a lot of RAM.
You mean tile-based mode? Graphics can't be done using Parallax drivers without a bitmap buffer. TV_text doesn't have a bitmap buffer AFAIK.
All video on the Propeller requires a driver program written in assembly language that runs in one or more cogs. These drivers always (for speed) have a small buffer in the cog memory, but this is usually enough only for one or two scan lines. Some of the hires VGA text drivers have a byte-wide text buffer in main RAM, but most of them and the TV driver use a word-wide buffer for each character. This word contains a pointer into the ROM font table entry for the character and some color information as well. The bitmapped graphics drivers (VGA and TV) use the same pointer, but it points to a bitmap for a 16 x 32 or 16 x 16 pixel "tile" in main memory. The graphics.spin driver knows about this tile layout for the screen's bitmap.
The Hydra "sprite" graphics are done differently. There's still a "tile" layout to the video display since that's how the video hardware works, but the Hydra graphics drivers generate the tile information "on the fly" from the sprite information. You'll have to read the Hydra manual for details.
Umm, what tile layout? I don't quite get it... The display is not mapped into tiles - the video drivers usually handle the output as a pixel stream, not tiles. Are you referring to that a fixed number of pixels are outputted with each waitvid with "that's how the video hardware works"? But it's not really a tile layout since the division to blocks is only horizontal. And by shifting, smooth scrolling etc. are still achieved. Or do you refer to their way of using tilemaps as backgrounds?
How come?
From graphics_demo.spin:
_stack ($3000 + $3000 +100) >>2
bitmap_base=$2000
display_base=$5000
gr.setup(16,12,73, display_base) ' or put bitmap_base
gr.copy() 'it contains the code to copy from one memory region to the other with nothing more. I thought that according to what is put in the gr.setup the graphics routines either wrote to the memory actively scanned by the video dedicated cog or the off screen memory region that is copied.
EDIT: Of course, it will cause flickering.