Usable hub RAM on the P2

Dave Hein

Can all of the hub RAM be used by a user program if interrupts are disabled? I looked at the documentation online, and it seems to be a bit out of date. According to the "Propeller II Documentation" there are 16 longs used in high memory that are used by the debug interrupt. Initially, these contain a RETI0, but could be replaced by a JMP to a debug ISR. I assume I should leave these in place in case I start a new cog, which would immediately get a debug interrupt. Is this still the case, or is more memory used now. I recall some discussion about reserving hub RAM to save the state of the cog on a debug interrupt. How much of the high memory should a user program avoid?

If I don't start a new cog, and I don't enable interrupts, can I use all of the high memory? By the time my program starts the debug interrupt for cog 0 would have occurred and the RETI0 would have executed leaving interrupts disabled. So it seems like it save to used the entire hub RAM for my program.

Cluso99

IIRC Chip said a few days back that each cog requires 32 longs. So that's 8x32x4 = 1KB which is also what I recall. That would be from $FFC00-$FFFFF reserved.

Whether you can in fact use this RAM I cannot answer.

I think that it's ok to load the whole Hub including the ROM space from Flash or downloading by serial. But beware, you cannot load the last 16KB of Hub from SD as it runs in hubexec mode. So does the monitor. TAQOZ copies itself down to the bottom of Hub to run.

Dave Hein

I found Chip's comment about RAM required for the debug interrupt:

cgracey wrote: »

Cluso99 wrote: »

Chip or anyone,
I forget, how much HUB ROM at the top needs to be kept free for the debug and interrupts?

There are 16 longs for buffering cog regs $000..$00F and 16 longs for the debug routine. That's 32 longs per cog. Times 8 cogs means 256 longs, or 1KB. So, $FFC00...$FFFFF are directly needed, plus maybe that much, again, for overlay code to make the whole debugger work. So, perhaps $FF800..$FFFFF should be reserved.

However, I thought only 1 long was reserved for the debug interrupt, and not 16 longs per cog. Anyhow, according to Chip's comment I need to reserve 32 longs per cog. I'm trying to figure out how to set the stack pointer for p2gcc programs so they can run on any of the FPGA boards. The DE0 Nano boards have only 1 cog and 32K of RAM, so I think a stack setting of (32K - 32*4) should be safe for all boards.

jmg

Dave Hein wrote: »

However, I thought only 1 long was reserved for the debug interrupt, and not 16 longs per cog. Anyhow, according to Chip's comment I need to reserve 32 longs per cog. I'm trying to figure out how to set the stack pointer for p2gcc programs so they can run on any of the FPGA boards. The DE0 Nano boards have only 1 cog and 32K of RAM, so I think a stack setting of (32K - 32*4) should be safe for all boards.

The question seems to be 'Do you expect users to run Debug with p2gcc' ?
If you want to support Debug, then it seems safest to leave that space free, even if in theory you might be able to use it in the special case of with no-debug enabled in any COG.

cgracey

I'll get this DEBUG documentation done soon. I got off track before finishing last time. It's the only thing behind in the documentation, I believe.

Dave Hein

jmg wrote: »

The question seems to be 'Do you expect users to run Debug with p2gcc' ?
If you want to support Debug, then it seems safest to leave that space free, even if in theory you might be able to use it in the special case of with no-debug enabled in any COG.

I think if I start the stack at (32K-32*4) it will be safe for the DE0 Nano boards since they only have 1 cog. It won't be a problem at all for the other boards since they have more than 32K of RAM. Of course, a stack at (32K-32*4) only works for programs that are smaller than 32K, which is true of all the demo programs I include with p2gcc. Larger programs would need to initialize the stack pointer appropriately.

Yes, I would like to run debug with p2gcc. It would be nice to provide C source level debugging, but that's a ways down on the wish list.