Making some code external with PropGCC

n_ermosh

I am working on a project which involves a large function (~10KB when compiled with CMM) that only needs to be called once during initialization. To save space for the rest of the code, I want to store this in an external 64k EEPROM, then retrieve it when I need to execute it. Is this possible? If so, how do I compile the code/link it with the main program that is CMM?

DavidZemon

In the same way that you can use "_COGMEM" to say that a variable should be stored in cog memory, I think there is a keyword that can be used to say "store in upper half of EEPROM". I think it's either HUBTEXT or HUBDATA, but I can't remember which.

Dave Hein

CMM doesn't know anything about the EEPROM. A CMM program must be less than 32K in size. If your initialization code contains large arrays you could re-use the arrays for data storage. You could run your program from EEPROM using XMMC, but it will run slower than CMM.

David Betz

Dave Hein wrote: »

CMM doesn't know anything about the EEPROM. A CMM program must be less than 32K in size. If your initialization code contains large arrays you could re-use the arrays for data storage. You could run your program from EEPROM using XMMC, but it will run slower than CMM.

Also, running XMM code from a 64k EEPROM doesn't gain you as much code space over CMM as you might expect. This is because all XMM code is really LMM code and has lower code density than CMM. In addition, you need to allocate some of hub memory for a cache to speed up access to code in external memory. Finally, some of the EEPROM will contain code that the Propeller loader will load on reset. This doesn't have to be a full 32k but it will eat into the space available for XMM. You really need an external memory that is bigger than a 64k EEPROM to get benefit from the XMM memory model.

DavidZemon

I'm not sure how often this would be helpful... But what if a utility function were written as part of propgcc, something like eeprom_memcpy. If cmm and lmm supported a special keyword that meant "store in upper memory", then rarely used functions like this or big read only tables could be dropped up there and manually loaded on-demand.

You'd have to use function pointers, but a couple well-documented examples would make it easy enough for the intermediate user.

That would probably require a significant rewrite, I know. Don't kill me, I'm just brainstorming

David Betz

SwimDude0614 wrote: »

I'm not sure how often this would be helpful... But what if a utility function were written as part of propgcc, something like eeprom_memcpy. If cmm and lmm supported a special keyword that meant "store in upper memory", then rarely used functions like this or big read only tables could be dropped up there and manually loaded on-demand.

You'd have to use function pointers, but a couple well-documented examples would make it easy enough for the intermediate user.

That would probably require a significant rewrite, I know. Don't kill me, I'm just brainstorming

Actually, something like this is already possible for PASM drivers. You can store them in the upper part of the EEPROM and load them at runtime. This allows you to save 2K of hub memory for each PASM driver. However, it requires a 2K buffer in hub memory so it isn't really useful unless you have at least two PASM drivers you're going to store in EEPROM. We had another idea for a two-stage loader that would first load all PASM COGs and then load the main program. This would allow up to 14K of hub memory to be saved but would require that the PASM drivers be able to initialize without the main program being present. In fact, Catalina C supports something like this already. The problem is, there was great resistance to placing any constraints on how PASM drivers could be written so we never implemented our ideas.