Compiler target help
VonSzarvas
Posts: 3,555
Hello!
I've been experimenting with an M4 cortex board with 320KB SRAM and 4MB PSRAM. It occurred to me (perhaps foolishly) that the resources might be enough to compile the openspin or flexprop compilers?
I gave it a test with openspin; replaced the file system calls in openspin.cpp (with a const bytearray of a spin source file for testing - later I figured on littlefs using the PSRAM), and satisfied all compiler warnings.
Yet the compile fails with what looks like a spectacular memory overrun:cannot move location counter backwards (from 001ff0b8 to 0002fc00)
Has anyone been down this road ?
Should these resources be sufficient in principal?
What resources would PropellerCompiler need to do it's thing?
Probably such resources could be expanded on the hardware, but I feel lost in knowing what the maximum temporary memory needs are during compilation. Am I blowing too big a hole in that 320KB?
Comments
@VonSzarvas On my Linux PC I see that openspin needs about 1M of code and 3M of data space at compile time (plus whatever dynamical allocation it performs). ARM will be a little bit different, but as an order of magnitude I'd say it probably won't fit in your board. If it doesn't need any dynamic heap, and needs only a tiny stack, and if the ARM compiler is able to make the binary a bit smaller, then maybe it would just fit, but it would be a stretch.
flexspin needs even more resources, so it's definitely not going to fit.
Wow. That's more than I'd figured. I had experimented with pushing the stack into PSRAM, and then figured I was missing something
At the moment the test is with a 640 byte spin source code file. No DAT or OBJ blocks. Just a couple IO pin toggles and some comments.
Was hoping to pass that src bytearray through PropellerCompiler/CompileSpin and get the binary pBuffer back. Blinded by the small src size, I never considered the compile process would expand more than 10x 32K!
I wonder what else might be linkable to external flash. I can certainly bump that to 8MB. Temporary data space looks like the beast to tame first.
Given time and funding, do you think a tiny-resources compiler would even be realistic; in the first instance from SPIN/PASM to binary ? It sounds like it might be a significant re-work, but I'm not sure...
OK, having shoved the data segment out to PSRAM, and then dealing with a less concerning "region `ram' overflowed by 785576 bytes" error.... (ahem),
Now the ARM project is compiling at least. I think I'll try bringing the heap at least back into SRAM, then get exercising the thing!
News to follow...
Hi,
Do you know Spinx? It is a P1 Spin1 compiler running on P1. So such things are certainly possible.
Cheers Christof
Thanks Christof- that's very cool. Probably the ultimate dream; like the RepRap of microcontrollers!
Seems like M-Park put a lot of work into that - I've downloaded the docs and sources to read up.
@ersmith Thanks for those numbers- they got me out of the wrong ballpark.
To feedback, Having increased the PSRAM to 8MB and with heap and data pushed to that external memory, Openspin now runs and compiles code. It looks positive so far
The next hurdle I notice is that all writes to this PSRAM appear to be 32 bytes, and there doesn't appear to be any sort of driver level auto"masking" setting, so with 8-byte writes (for example), they are zeroing out 24 bytes of good data. Hmm. well, maybe I'll find a setting somewhere! Anyway, that's the next thing to solve. Fun!
With any luck this experiment will look sensible soon; and with some meat to share at P2LF.