Perhaps so but what if you want to borrow such a "coglet" for use in language other than Spin? Arranging to get binary blobs of "firmware" started in a COG is hard enough with having to also start up a Spin interpreter to configure the thing and get it going.
It's fairly easy to start up a Spin program anywhere in memory. This could be done from any language. This way you only write the PASM startup code once in Spin, and it doesn't have to be redone in each language that you support. The drawback is that you need to write a Spin program loader routine in the language you are using, but an OS has to do that anyway. The other issue is that you need a standard way to pass parameters to the PASM startup programs. In Spinix, I use the (argc, argv) method that is used for C programs. This is very flexible, and it works well in the Spinix architecture.
Another advantage to including the Spin code with the PASM cog code is that it goes away after the cog is loaded, and that memory is available for use by other programs. This may not be a big issue for some PASM dirivers where all that is needed is a cognew. However, some PASM drivers require quite of bit of setup, such as a display driver or a memory cache driver. PropGCC uses a Spin program to set up the memory cache driver. In theory, Spin programs could use the same driver to access external memory.
The only part that needs to be converted to another language is the API used to talk to the driver.
Perhaps so but what if you want to borrow such a "coglet" for use in language other than Spin? Arranging to get binary blobs of "firmware" started in a COG is hard enough with having to also start up a Spin interpreter to configure the thing and get it going.
Gosh, it seems like we've been round this loop so many times now that I now get dizzy just thinking about it. Although I haven't had as much time for such things as I'd like recently, I've already implemented all the necessary techniques (i.e. the ones described here) in Catalina. It has made everything much simpler, and the overhead is quite low - in fact, programs often end up smaller now than they used to be, since this approach generally requires less messing about in Spin. I should have a version ready to release in a few days. I'll go back and update that document after I do - there have been a a couple of minor changes and additions to what I originally proposed.
Someone recently asked me if I could support multiple serial ports in Catalina, and so I thought the OBEX "4 port serial driver" would make a perfect example of the benefits to be had. It took a couple of hours to port and test and it works a treat. It required no changes to the orignal PASM code (which is just as well, since I have no idea how it works internally, and nor do I want to - just reading the code makes my brain hurt!) and only a couple of changes to the Spin code - most of it I simply delete as it is no longer necessary. The main reason I do this is that Homespun does not automatically remove unused Spin methods, so leaving them in just eats up potential code space for no good reason - but (thinking about it now) perhaps it would make sense to leave them in but put a simple "#ifdef .. #endif" around them - that way, exactly the same OBEX object could be used from Spin, C or any other language that implemented the same technique. I may go back and do this just to provide a complete multi-language example. I already have all the Spin code, since Catalina's initialization code is now just a simple Spin program (the complexity that many people used to find so confusing is now gone - thanks largely to the adoption of these techniques).
I think it's a real shame that more people don't seem to see the potential benefits in writing all OBEX objects this way - there are heaps of amazingly clever and really useful objects already in the OBEX that could easily be used from multiple languages with quite trivial re-work. Just imagine the thousands of hours of duplicate effort we would all have saved - and also how much more attractive it would make the Propeller if all varieties of developers - hobbyist or professional - could use the same set of "vetted" objects - no matter what language they chose to use. Sigh!
It's fairly easy to start up a Spin program anywhere in memory. This could be done from any language. This way you only write the PASM startup code once in Spin, and it doesn't have to be redone in each language that you support. The drawback is that you need to write a Spin program loader routine in the language you are using, but an OS has to do that anyway. The other issue is that you need a standard way to pass parameters to the PASM startup programs. In Spinix, I use the (argc, argv) method that is used for C programs. This is very flexible, and it works well in the Spinix architecture.
Another advantage to including the Spin code with the PASM cog code is that it goes away after the cog is loaded, and that memory is available for use by other programs. This may not be a big issue for some PASM dirivers where all that is needed is a cognew. However, some PASM drivers require quite of bit of setup, such as a display driver or a memory cache driver. PropGCC uses a Spin program to set up the memory cache driver. In theory, Spin programs could use the same driver to access external memory.
The only part that needs to be converted to another language is the API used to talk to the driver.
Ah! didn't read far enough down in the thread before responding - yes, I agree with Dave. And we already have everything we need to make it work!
Comments
Another advantage to including the Spin code with the PASM cog code is that it goes away after the cog is loaded, and that memory is available for use by other programs. This may not be a big issue for some PASM dirivers where all that is needed is a cognew. However, some PASM drivers require quite of bit of setup, such as a display driver or a memory cache driver. PropGCC uses a Spin program to set up the memory cache driver. In theory, Spin programs could use the same driver to access external memory.
The only part that needs to be converted to another language is the API used to talk to the driver.
Hi C.W.
I don't have an ETA at the moment.
It will be after Propeller-GCC Beta start.
I'm shooting for Beta next week ... we'll see.
Gosh, it seems like we've been round this loop so many times now that I now get dizzy just thinking about it. Although I haven't had as much time for such things as I'd like recently, I've already implemented all the necessary techniques (i.e. the ones described here) in Catalina. It has made everything much simpler, and the overhead is quite low - in fact, programs often end up smaller now than they used to be, since this approach generally requires less messing about in Spin. I should have a version ready to release in a few days. I'll go back and update that document after I do - there have been a a couple of minor changes and additions to what I originally proposed.
Someone recently asked me if I could support multiple serial ports in Catalina, and so I thought the OBEX "4 port serial driver" would make a perfect example of the benefits to be had. It took a couple of hours to port and test and it works a treat. It required no changes to the orignal PASM code (which is just as well, since I have no idea how it works internally, and nor do I want to - just reading the code makes my brain hurt!) and only a couple of changes to the Spin code - most of it I simply delete as it is no longer necessary. The main reason I do this is that Homespun does not automatically remove unused Spin methods, so leaving them in just eats up potential code space for no good reason - but (thinking about it now) perhaps it would make sense to leave them in but put a simple "#ifdef .. #endif" around them - that way, exactly the same OBEX object could be used from Spin, C or any other language that implemented the same technique. I may go back and do this just to provide a complete multi-language example. I already have all the Spin code, since Catalina's initialization code is now just a simple Spin program (the complexity that many people used to find so confusing is now gone - thanks largely to the adoption of these techniques).
I think it's a real shame that more people don't seem to see the potential benefits in writing all OBEX objects this way - there are heaps of amazingly clever and really useful objects already in the OBEX that could easily be used from multiple languages with quite trivial re-work. Just imagine the thousands of hours of duplicate effort we would all have saved - and also how much more attractive it would make the Propeller if all varieties of developers - hobbyist or professional - could use the same set of "vetted" objects - no matter what language they chose to use. Sigh!
Ross.
Ah! didn't read far enough down in the thread before responding - yes, I agree with Dave. And we already have everything we need to make it work!
Ross.