LMM bytecode as a macro language?
Larry Martin
Posts: 72
in Propeller 1
Is it possible to:
* compile a small SPIN or C function to LMM code on the PC
* load it to Prop 1 RAM
* run it in C via a function pointer?
Here's the big picture. I have a project in PropGCC LMM mode that needs to format data from RFID reader reply and barcode data into an RFID write command. The data formatting is pretty variable. It can be anything from raw data at some offset, to an NFC/NDEF data template with barcode injection, to Marta style Luhn checksums. In the past I have spun special SPIN code versions for unforseen formats and computations. Now that I am moving to PropGCC, I am trying to design a macro that can be loaded at runtime. My code is translated from SPIN via spin2cpp --ccode --gas, so all my former VAR variables are now in a global structure, including the data inputs to my computations. I have a mechanism for loading RAM data based on Intel hex record format, offsets determined from the base of the global variable structure. So "all I need" is a calling convention and a way to compile and call the bytecode.
I've thought of adding a Forth interpreter but this approach seems "easier" given gcc function pointers. As long as it has a hope of working.
This seems like the kind of thing that would take a couple of days to try, and I don't want to waste time if the effort is doomed. So has anyone tried this? Got any hints?
Thanks very much,
Larry
* compile a small SPIN or C function to LMM code on the PC
* load it to Prop 1 RAM
* run it in C via a function pointer?
Here's the big picture. I have a project in PropGCC LMM mode that needs to format data from RFID reader reply and barcode data into an RFID write command. The data formatting is pretty variable. It can be anything from raw data at some offset, to an NFC/NDEF data template with barcode injection, to Marta style Luhn checksums. In the past I have spun special SPIN code versions for unforseen formats and computations. Now that I am moving to PropGCC, I am trying to design a macro that can be loaded at runtime. My code is translated from SPIN via spin2cpp --ccode --gas, so all my former VAR variables are now in a global structure, including the data inputs to my computations. I have a mechanism for loading RAM data based on Intel hex record format, offsets determined from the base of the global variable structure. So "all I need" is a calling convention and a way to compile and call the bytecode.
I've thought of adding a Forth interpreter but this approach seems "easier" given gcc function pointers. As long as it has a hope of working.
This seems like the kind of thing that would take a couple of days to try, and I don't want to waste time if the effort is doomed. So has anyone tried this? Got any hints?
Thanks very much,
Larry
Comments
The GCC overlay is something that greatly intrigues me. I currently have no use for it, and therefore have not looked into what could be done in PropWare to make it easier. However, if someone takes a look at PropWare and takes a look at GCC overlay and says "YES! I'd love to use these two tools together!" then that would be enough motivation for me to go try and implement something.
However, I wasn't able to understand why you wouldn't just convert your Spin code to C/C++ and compile it into your executable like any other C/C++ code. What makes this any different from any other objects that you want to use?
@David Zemon:
It's compile time vs. run time. This code is used at my customer sites. I am trying to come up with a mechanism I can use to cover unforseen circumstances without a complete code load. It's also important to be flexible - my customers do different jobs for _their_ customers. Loading Propeller code for each job change gets tedious. I already have a job file mechanism that configures the Propeller for different tasks. I want to add a data setup macro to that mechanism.
Make sense?
Larry
http://forums.parallax.com/discussion/163970/overlay-code-with-gcc
That definitely makes sense, and sounds like exactly what overlay was made for. Good luck, and I'll be curious to here about your experience with it.
Another option might be to embed a scripting language -- you mentioned Forth. This would be flexible in a different way; it would easily allow you to update code, but performance may be an issue if you need to do something radically different from what you've already provided in the scripting language core. I have two embeddable languages for the P1: tinyscript and proplisp. They have pretty similar interfaces. proplisp is a bit faster and more flexible, but probably consumes more resources at run time. They're both very easy to interface to C, so you can extend them with your own C functions. I think these would be a lot easier to interface with C code than a general Forth interpreter would be (although there may be a Forth interpreter written in C for the Prop).
Eric
In SPIN, this code had 5500 longs free for stack/heap per PropTool. Translated in spin2cpp --ccode --gas and built in LMM, it looks like the heap starts at 770a, giving me 2294 _bytes_ to end of cog memory at 7FFF. Something tells me I'll be switching to CMM pretty soon, and still needing to conserve memory and cogs.
Am I reading that right?
I long ago set up a PASM "CompuCog" for things that had to happen fast, so I don't think I really need the speed of LMM.
forums.parallax.com/discussion/104558/slow-crc-computation
I was very interested in the ability to use code overlays with the Elev8 FC project, but was told that the latest iteration of PropGCC and Propeller Loader would likely have the support for those features removed.
I'd like very much to be mistaken though. Do PropGCC / Propeller Loader continue to support code overlays? I don't mean to hijack the thread here, but if this works in CMM or LMM it would likely help the OP as well. Forum user Macca posted a project that used the ECOG area to load & run a pair of overlay functions that were shoved into high eeprom (driver area?) by the PropGCC tools. When I started poking around with it I was told that there was a push to drop support because no one was using those features and they complicated the wifi support. David / Eric?
The code overlay is implemented with a linker script "trick": it basically says that the code and data from a certain object file must be linked with a specific origin (the start of the common overlay area in memory) and placed in a specific object memory area (the eeprom address above 32k). The toolchain doesn't need to support anything else to make it working, these things are used by other targets and I don't see any reason why they could be dropped in the future.
The loader however must recognize the eeprom area address in the elf file and provide a way to write the binary image to the eeprom. This support is already implemented because of the ecog drivers support (binary cog code that is stored in the upper eeprom locations so it doesn't take any extra space in hub memory), the code overlay uses the same memory area so the loader doesn't need any additional support. As long as the loader knows that anything starting from address 0xC0000000 must be written to the eeprom starting at address 0x8000 the trick works.
As far as I can tell, the latest propeller-load code from David Betz's repository is broken because it is missing the eeprom_cache.dat needed to load the code into the upper eeprom locations (see https://github.com/dbetz/propeller-load/issues/4). The file can be easily restored from the repostiory and recompiled or the binary can be copied from an old release (if I remember correctly the official Parallax GCC toolchain has the binary file).
The support for overlays can be implemented in an IDE to make things easier, so far the only tool I have that supports overlays is the IDE for my P8X Game System (the Abbaye des Morts game uses the overlays for the game code). I'm working on adding overlays support to another tool.