Is 'Hybrid' programming possible?
LoopyByteloose
Posts: 12,537
I have been studying C for Catalina C and GCC. There has always been Spin and Assembler that can run together. Now I am looking at PropForth.
So I am wondering can different cogs in one Propeller run PropForth, a variation of C, Spin/Assembler in a working relationship all at the same time. I imagine the RAM space for each cog would be limited to 2K, just because the variety would interfer with larger memory models.
It is possible? or is there something that makes these mutually exclusive?
So I am wondering can different cogs in one Propeller run PropForth, a variation of C, Spin/Assembler in a working relationship all at the same time. I imagine the RAM space for each cog would be limited to 2K, just because the variety would interfer with larger memory models.
It is possible? or is there something that makes these mutually exclusive?
Comments
Theoretically I don't see any problem with that.
In practice that need smarter compiler that that separate languages have.
I was just wondering. I am not sure if this is appealing to anyone. I was thinking of running the VGA display and keyboard alongside a cog with Forth and thought that even more might be achieved.
You can run VGA using forth, just as any assembler program. See JupiterACE in propforth 3.5
You CAN run propforth along other programs, BUT
other programs do not define any interface, so we don't know how to talk to them. Propforth defines a common standard interface to all the tasks (cogs) and user tasks, (serial driver, MCS/CSP channels, etc) so all that's left to implements is the OTHER side in spin, C, PASM, etc.
If anybody wants to define a different standard interface we can talk to that, all we need is the definition of the interface.
I suggest it would be easier to implement something that matches the propforth interface, since that already exists and is known good.
Could you please post the code for an example of this. I'm sure many of us multi-language folk would love to see some examples of hybrid programming on the prop.
Running COGs with independent binary blobs generated from either PASM or as COGC code shouldn't be a big problem. Proprforth does that with some modules.
If you could start in on getting folks to consider a standard interface it could happen.
For example, if we reserve the first 8 * X bytes in the hub for the message buffer for each cog, we could set up a simple protocol.
I'd be interested to see how far we get. This is certainly doable, and need not be hard.
Ross has written a standard for it and implemented it in Catalina.
The intent there was more to do with using PASM driver and other binary blobs from any language rather than mixing HLLs in a single application but I guess the same considerations apply.
All in all I'm wondering why you would want to do this. Binding two languages together is always a pain. Just now I'm working on an app that is mostly Pascal with bits of C thrown in. Linking C and Pascal is one of the simpler cases but still a pain. Setting up communications between processes written in different languages might be the easier or indeed only way to go in many cases. Then of course if you are mixing say Forth and C you have two kernels to fit into memory reducing space for real functionality.
All in all there would have to be a really compelling reason to want to get into multi-language applications.
In my own case, it will be a long time before I'll be creating anything in a hybrid sense. I was just wondering if it was possible.
But for others, it may be rewarding. In Linux, I run across support for all sorts of hybrids; but I tend to shy away from them. Usually C is somehow involved and assembler. For some that feel this is a needed career skill, starting small on the Propeller may be a lot easier than doing it on a desktop.
the effort of getting the spin so it could play nice has so far been greater then implementing the function in forth.
if the spin could be converted to some standard, this alone would be worth it for many developers
I really am enjoying PropForth, but it seems rather odd to have to rewrite all and everything in Forth to get something working.
Hear Hear!
I am in favor of this also so that we can do the same with PropBASIC code.
Mickster
PropBASIC is already included in OBEX under the title of Basic. bean has some submissions in OBEX, and they are under that title. I believe that they are still in the process of improving your experience with OBEX.
Ray
A repository would certainly be nice. But I have had a certain amount of frustration with the OBEX way of doing things. It just has never been easy to navigate and locate what you want - it is somewhat like looking at a messy bulletin board in a university dorm.
Makes me wonder why the OBEX is the way it is and what happened. I tend to rely on the SPIN examples that came with the original SPIN IDE before I bother with OBEX as these are far more important to study and to learn to modify.
The OBEX is just "a place for folks to post code". There is nothing about standard interfaces, or common way of dong things, besides the spin rules for the individual functions and indenting. Folks discover and post many things, mostly about the hardware they are focusing on. Concerning how to communicate code from one individual to the next, we've discovered that the OBEX is in some way lacking.
The Gold Standard Repository is an attempt to move a step further. It is a step in the right direction, but obviously there are many steps in a journey. I'm on that team for a "software development process" perspective. I tend to stress the importance of requirements, testability, clarity, and interfaces. But we haven't gotten to that point yet, we are still looking at coding standards, formatting, etc. As I side, this is a long journey with many steps.
The Gold Standard Repository is a new useful tool for those that cannot or prefer not to waste time with the more creative solutions provided by individuals. I was just extremely frustrated with the OBEX headings that tend to have items listed under multiple characterizations, while searches were not quite up to snuff.
The material heater referenced in #12 is already too high level and assumes too many specifics (peculiar to C?), which forces design decisions too early.
For example, a simple interface could be something like:
"The first available 8 longs (or words or bytes) in HUB are always allocated to the interface. offset 0 is for cog 0, offset 7 is for cog 7. When a cog wishes to communicate to other cogs, it places a value in it's own slot. The other cogs can read this value if they choose."
This would be a simple way to start. At this point, it would be up to the developer to define what and how to communicate further to the other cogs. For example value X means ready, value Y means next value is a pointer to a buffer in HUB that has all the data to transfer, etc. But whatever it is, it needs to be simple. Then folks can built on it 'as they write programs that communicate.' So far, nobody as tried this, (to my knowledge) so we have no business restricting any options till forced.
I didn't thhink RossH's suggestions had an C language specifics or any language specifices. After all it is about communicating between COGs in any language.
Feel free to invent your own solution to communicating between languages on the same machine (Which is essentially the same as communicating between COGS unless a binary is built from two or more langugaes compiled and linked together which I don't think is on the table here).
The more standards we have the better:)
Until someone actually tries to do a multi - language app, we have no way of evaluating any other rules as "helpful" or "hindrance".
I must disagree with your previous post, everything in RossH's suggestion is brilliant BUT its at least two levels too deep to serve as a starting point.
On a tangent, I feel that should be fewer, more general standards that say things like "play nice, and be considerate of the next person that has to deal with what you are leaving behind, and don't make decisions that affect others without discussing it or at least letting them know". If folks follow this "standard" most "stupid" problems in this life could not happen.