Does anyone think the constant arguing makes this forum seem like a place where new people might want to hang out and learn about the propeller?
Yes. (I took it as "where new people do not want to hand out" ... sorry.)
This current spat of junk is just a rehash of an old story that was really started by people not wanting to support the official plan of Parallax to make it's own C variant. Instead of support, people proposed only "their way or the highway." And THAT CONTINUES as evidence in this thread shows. Instead of support, all Parallax gets around here is constant haranguing and abuse.
Personally, I'm sick of it all and would be very happy to simply abandon it, but that would be abandoning my friends in Parallax who are counting on me to support their goals. So, I'm stuck.
This current spat of junk is just a rehash of an old story that was really started by people not wanting to support the official plan of Parallax to make it's own C variant. Instead of support, people proposed only "their way or the highway." And THAT CONTINUES as evidence in this thread shows. Instead of support, all Parallax gets around here is constant haranguing and abuse.
Personally, I'm sick of it all and would be very happy to simply abandon it, but that would be abandoning my friends in Parallax who are counting on me to support their goals. So, I'm stuck.
I don't want to get involved in the argument, so I'm not going to comment on it.
I will just say that I think we need to refrain from having discussions like this as part of threads like this one where a new member was asking for advice.
The OP has already mentioned being sorry he asked.
I will just say that I think we need to refrain from having discussions like this as part of threads like this one where a new member was asking for advice.
The OP has already mentioned being sorry he asked.
It would be very helpful to talk about things that can happen. Differences in approach are going to be there. However, good ideas will also be there too.
I see a "let's make gcc call a spin program" project started. This is working and proven in Catalina. So then, making it work the same way in gcc might not be possible due to the differences. Making it work will be possible.
Others, who seek to accomplish their goals will appreciate it being possible. From there, more things need to be possible so more goals are realized.
That project got started due to some discussion about what currently is possible.
I see a "let's make gcc call a spin program" project started.
I'm working on this now. It should be quite easy to load an entire Spin program from C. As you say, RossH has already done it using code originally written by jazzed. In fact, PropGCC already uses similar code to load the DAT section of a Spin program as a driver. Ross has extended this to allow an entire Spin program to be loaded and started and Dave Hein has provided enough information in another thread to make it relatively easy to get PropGCC to do the same thing. However, you still can't just "call Spin code from C". You can either rewrite the Spin portions in C and talk to the PASM driver that was part of the OBEX Spin program or you can run an entire Spin program in parallel with C code. I'm not sure how you get the C and Spin to interact using that model. I haven't gotten that far in studying how Catalina handles this although I have some ideas. In any case, if I ever get this done it will be on the backs of many smart people in this forum including both Dave Hein, jazzed, and RossH as well as others. Thanks for your help!
jazzed I hope that you change your mind about that, you are about the only person that helps me with my stupid C questions and ideas, and hopefully others are getting a little something out of it also. I have noticed that, at least as of a couple of months ago, this forum has turned a little nasty, lots of bickering going on, and not much of anything new is being presented or discussed. Hopefully you will reconsider, and still decide to hang around here. I hope that I did not say something that ticked you off?
The goal should be for C call spin functions directly. For example:
int main(void) {
vga_start(8);
}
Unless you use something like spin2cpp you won't be able to run Spin code in the same COG that is running C code. The best you'll be able to do is start another COG with the Spin interpreter and talk to that COG over some sort of mailbox interface. This will also depend on Spin objects being "well behaved" in that they don't use memory that wasn't explicitly passed to them. All bets are off if they, for instance, think they can just use the top 16k of hub memory as a frame buffer.
The goal should be for C call spin functions directly.
Yes! There are two ways to accomplish this:
1. Remote procedure call to a Spin cog. This would entail prepending a supermain method to the Spin object that monitors a hub mailbox for commands, calls its internal methods, then returns results via the mailbox.
2. Compile C to Spin bytecodes so the C can be interpreted in the same cog as the targeted Spin methods.
I would prefer the second, although it entails a lot more work; but the first would also be acceptable. I'm not crazy about the spin2cpp approach, since critical program timings could be altered, among other things.
It seems like there are two primary ways to interface C and Spin code. One way is to run the two pieces of code in different cogs, and use a mailbox to communicate between them. I believe this is how Catalina supports it. In addition, Catalina uses a registry to allow Spin code to act as plug-ins. It's similar to the method used by some of the other Prop OSes.
The other approach is to convert the Spin code to C using spin2cpp. Personally, I think this is a better approach. It allows the Spin programmer to continue to program in Spin, but the resulting compile code has the advantages of higher speed or access to external memory. In addition, the converted Spin code can be called directly from a C program.
EDIT: I was composing my comment while Phil was posting his. The second approach is already available. Maybe the conversion needs to be automated within the IDE so the interface is seamless. Or maybe it already is. I don't know is SIDE supports automatic conversion of Spin to C code.
And yes, I do understand the limitations. And issues. Not all SPIN programs are going to make sense. That's OK. The ones that do are possible. And really, advancing the possible is what people will be most interested in. From there, people get more and better choices. Maybe and likely not optimal ones, but more and better is always good. Being able to decide whether or not it makes sense to modify a SPIN program or just move it into C is one such, nice choice!
2. Compile C to Spin bytecodes so the C can be interpreted in the same cog as the targeted Spin methods.
I won't be going in this direction for several reasons. I think you mentioned one already yourself, it will produce slower C code. The bigger reason though is that I don't have the time to write an entire new code generator for GCC. I guess a third reason is that I've never seen an adequate description of Spin bytecodes. I know we have the source for the Spin interpreter but I don't have time to reverse engineer that to get a description of the VM. I've been pointed to past attempts to document the Spin VM but they are all incomplete. If there is a complete description out there I'd love to see it.
EDIT: I was composing my comment while Phil was posting his. The second approach is already available. Maybe the conversion needs to be automated within the IDE so the interface is seamless. Or maybe it already is. I don't know is SIDE supports automatic conversion of Spin to C code.
Are you saying that there is already a C compiler that produces Spin bytecodes?
He started a thread specifically with the purpose of integrating in mind. Maybe we can stop posting here now ... or at least until someone has had their last word.
@Ray,
You are my favorite contributor. I can't answer all your questions though. I get more from your coding challenges than all the junk the experts spew.
@Ragametal,
I'm sorry that things have gone so wrong in your thread. You're posts were all intelligent. It's just that so many of the old crew here are exceedingly selfish. ctwardell is the most sane one here.
Are you saying that there is already a C compiler that produces Spin bytecodes?
I misunderstood Phil's suggestion. I thought he was referring to the spin2cpp approach. So there are three different approaches.
1. Run C and Spin in different cogs and communicate through a mailbox
2. Convert Spin to C using spin2cpp
3. Convert C to Spin using something like CSPIN
I realize that Phil's suggestion is to compile C to Spin bytecodes, but that doesn't provide interoperation with Spin.
I like method 2. Phil is correct that it affects timing. Something like a Spin I2C driver doesn't work correctly when converted to C because it runs too fast. However, it can be fixed by using the cycle counter to enforce timing requirements rather than relying on the slow speed of the Spin interpreter.
Surely the ultimate best way to build C and Spin together is to create a SPIN front end for GCC.
Then C and Spin would end up as object files and linked into the finished program binary.
One would get all the optimizations available to C and the ability to target LMM and CMM or whatever.
Calling Spin methods from C is an issue as they are methods on objects not just free functions. what if the are multiple instances or methods with the same name in different objects?
That brings us to C++ territory..
Seems like a lot of work anyway for something that is not going to get used much.
Seems like a lot of work anyway for something that is not going to get used much.
I suppose so but it seems that the first thing people mention here when talking about whether someone should program in C or Spin is the OBEX. How do we get past that other than by providing a way to use Spin objects, especially some of the more popular ones from OBEX, from C programs? Otherwise we end up with the argument that C is not a good choice because it can't make use of the goldmine of OBEX objects.
Surely the ultimate best way to build C and Spin together is to create a SPIN front end for GCC.
We essentially already have that with spin2cpp. It would just have to be modified to allow mixing Spin and C code in the same program. Maybe it does that already. I haven't really used it for anything other than extracting the DAT section from Spin drivers. In any case, the output of spin2cpp gets compiled by GCC so I don't think there would be that much improvement in performance gained by having it target the GCC backend directly. I guess Eric may know more about this though.
I realize that Phil's suggestion is to compile C to Spin bytecodes, but that doesn't provide interoperation with Spin.
'Not sure I understand that statement. If a compiled C program looks like a compiled Spin program and gets interpreted with the ROM interpreter it ought to be able to work with other Spin objects transparently. IOW, the whole idea behind putting a wolf in sheep's clothing is so that it can mingle with the sheep.
I'm also not conviced that the slower speed of interpreted C code is a deal breaker. A fast main C program calling slow Spin objects is sorta like the tail wagging the dog. In any event, I'm thinking mainly about the educational environment, where raw speed is second to ease of use.
I'm also not conviced that the slower speed of interpreted C code is a deal breaker. A fast main C program calling slow Spin objects is sorta like the tail wagging the dog. In any event, I'm thinking mainly about the educational environment, where raw speed is second to ease of use.
-Phil
The thing is, most Spin drivers are fast because their guts are written in PASM. In any case, the effort required to write a C compiler that produces Spin bytecodes is considerable especially if you want something more than just a dumb non-optimizing compiler.
Also, how does generating Spin bytecodes from C code help with interoperablity. How would I call Spin from C? Would the C compiler also have to compile Spin code and provide a way to link them together? OpenSpin or the Propeller Tool don't provide any kind of linker right now. How would the two be combined into a single program?
Also, how does generating Spin bytecodes from C code help with interoperablity. How would I call Spin from C? Would the C compiler also have to compile Spin code and provide a way to link them together?
That's 8*32=256 bits with 2^256 possible values. Such a huge number of possibilities is certainly complex! :-)
Ok, I'll pay that one .
Just going back to the original point of this thread for a minute, the question the original poster had was how to take advantage of the huge number of really useful OBEX objects from C. This has always been a problem for high-level languages on the Propeller (not just C) because neither Spin nor PASM was designed to be called from other languages.
We have all come up with various ways to run Spin programs, but in fact that's not really what's required. We have forgotten sight of the fact that (as David pointed out) most of the Spin objects that get re-used are largely written in PASM with a thin Spin wrapper. They are written that way for speed. In 9 cases out of 10, the part that we want to re-use is the PASM part. The Spin parts are easy to rewrite in C.
Catalina has a method to do that. This method preserves the PASM of OBEX object. In some cases it can do that without modifying the PASM at all, and in other cases some trivial modification is required. Even better, this modification can be done in such a way to make the object usable from either Spin or C.
This method could have been adopted across other compilers, but at the time, nobody seemed to appreciate the need. And so we have a re-run of the same debate every time a newcomer arrives.
We have all come up with various ways to run Spin programs, but in fact that's not really what's required. We have forgotten sight of the fact that (as David pointed out) most of the Spin objects that get re-used are largely written in PASM with a thin Spin wrapper. They are written that way for speed. In 9 cases out of 10, the part that we want to re-use is the PASM part. The Spin parts are easy to rewrite in C.
Catalina has a method to do that. This method preserves the PASM of OBEX object. In some cases it can do that without modifying the PASM at all, and in other cases some trivial modification is required. Even better, this modification can be done in such a way to make the object usable from either Spin or C.
PropGCC uses exactly the same method. We often extract the PASM from an OBEX object and use it with a C wrapper. Many of these C wrappers were written by Steve (jazzed) for the old ICC C compiler and have been moved over to PropGCC. We probably haven't put enough effort into expanding our collection of drivers that work this way though. I think Catalina provides a more complete set of ported OBEX drivers.
PropGCC uses exactly the same method. We often extract the PASM from an OBEX object and use it with a C wrapper. Many of these C wrappers were written by Steve (jazzed) for the old ICC C compiler and have been moved over to PropGCC. We probably haven't put enough effort into expanding our collection of drivers that work this way though. I think Catalina provides a more complete set of ported OBEX drivers.
Yes, Catalina has a very rich set, and more get added regularly. But the point is not the C wrapper, as much as making the PASM component common to any language (not just Spin and C). That way, the Spin version can stay in the OBEX, and all high level languages can make use of any of them - they don't have to (as we both do now) create and maintain our own slightly modified copies.
With the inclusion of a simple preprocessor in Spin (courtesy of openspin), this should now be even easier.
Comments
Yes. (I took it as "where new people do not want to hand out" ... sorry.)
This current spat of junk is just a rehash of an old story that was really started by people not wanting to support the official plan of Parallax to make it's own C variant. Instead of support, people proposed only "their way or the highway." And THAT CONTINUES as evidence in this thread shows. Instead of support, all Parallax gets around here is constant haranguing and abuse.
Personally, I'm sick of it all and would be very happy to simply abandon it, but that would be abandoning my friends in Parallax who are counting on me to support their goals. So, I'm stuck.
This post will self-destruct in 5 minutes ....
Really?
I don't want to get involved in the argument, so I'm not going to comment on it.
I will just say that I think we need to refrain from having discussions like this as part of threads like this one where a new member was asking for advice.
The OP has already mentioned being sorry he asked.
http://forums.parallax.com/showthread.php/153873-Programing-language-advise-Spin-or-C?p=1242743&viewfull=1#post1242743
And that was before the latest 'discussion'.
Chris Wardell
I'm sorry, but I read it the opposite way you wrote it.
Yes, this has weighed heavily on my mind for many weeks before this thread. I'm ready to move on honestly. I can't stand it anymore.
I see a "let's make gcc call a spin program" project started. This is working and proven in Catalina. So then, making it work the same way in gcc might not be possible due to the differences. Making it work will be possible.
Others, who seek to accomplish their goals will appreciate it being possible. From there, more things need to be possible so more goals are realized.
That project got started due to some discussion about what currently is possible.
int main(void) { vga_start(8); }Ray
2. Compile C to Spin bytecodes so the C can be interpreted in the same cog as the targeted Spin methods.
I would prefer the second, although it entails a lot more work; but the first would also be acceptable. I'm not crazy about the spin2cpp approach, since critical program timings could be altered, among other things.
Thanks for looking into this, Steve!
-Phil
The other approach is to convert the Spin code to C using spin2cpp. Personally, I think this is a better approach. It allows the Spin programmer to continue to program in Spin, but the resulting compile code has the advantages of higher speed or access to external memory. In addition, the converted Spin code can be called directly from a C program.
EDIT: I was composing my comment while Phil was posting his. The second approach is already available. Maybe the conversion needs to be automated within the IDE so the interface is seamless. Or maybe it already is. I don't know is SIDE supports automatic conversion of Spin to C code.
And yes, I do understand the limitations. And issues. Not all SPIN programs are going to make sense. That's OK. The ones that do are possible. And really, advancing the possible is what people will be most interested in. From there, people get more and better choices. Maybe and likely not optimal ones, but more and better is always good. Being able to decide whether or not it makes sense to modify a SPIN program or just move it into C is one such, nice choice!
He started a thread specifically with the purpose of integrating in mind. Maybe we can stop posting here now ... or at least until someone has had their last word.
@Ray,
You are my favorite contributor. I can't answer all your questions though. I get more from your coding challenges than all the junk the experts spew.
@Ragametal,
I'm sorry that things have gone so wrong in your thread. You're posts were all intelligent. It's just that so many of the old crew here are exceedingly selfish. ctwardell is the most sane one here.
Is there anything I can do to make it up to you?
1. Run C and Spin in different cogs and communicate through a mailbox
2. Convert Spin to C using spin2cpp
3. Convert C to Spin using something like CSPIN
I realize that Phil's suggestion is to compile C to Spin bytecodes, but that doesn't provide interoperation with Spin.
I like method 2. Phil is correct that it affects timing. Something like a Spin I2C driver doesn't work correctly when converted to C because it runs too fast. However, it can be fixed by using the cycle counter to enforce timing requirements rather than relying on the slow speed of the Spin interpreter.
Then C and Spin would end up as object files and linked into the finished program binary.
One would get all the optimizations available to C and the ability to target LMM and CMM or whatever.
Calling Spin methods from C is an issue as they are methods on objects not just free functions. what if the are multiple instances or methods with the same name in different objects?
That brings us to C++ territory..
Seems like a lot of work anyway for something that is not going to get used much.
'Not sure I understand that statement. If a compiled C program looks like a compiled Spin program and gets interpreted with the ROM interpreter it ought to be able to work with other Spin objects transparently. IOW, the whole idea behind putting a wolf in sheep's clothing is so that it can mingle with the sheep.
I'm also not conviced that the slower speed of interpreted C code is a deal breaker. A fast main C program calling slow Spin objects is sorta like the tail wagging the dog. In any event, I'm thinking mainly about the educational environment, where raw speed is second to ease of use.
-Phil
What are you talking about? The registry does not use a cog. Perhaps you should actually read up on it before you criticize further.
Ross.
I see. Ok, that's great. Did you get rid of the unnecessary complexity? Oh, it's all necessary
Also, how does generating Spin bytecodes from C code help with interoperablity. How would I call Spin from C? Would the C compiler also have to compile Spin code and provide a way to link them together? OpenSpin or the Propeller Tool don't provide any kind of linker right now. How would the two be combined into a single program?
The registry is essentially just 8 longs in upper Hub RAM which keeps track of what is loaded into each cog. What's so complex about that?
Ross.
-Phil
Ok, I'll pay that one
Just going back to the original point of this thread for a minute, the question the original poster had was how to take advantage of the huge number of really useful OBEX objects from C. This has always been a problem for high-level languages on the Propeller (not just C) because neither Spin nor PASM was designed to be called from other languages.
We have all come up with various ways to run Spin programs, but in fact that's not really what's required. We have forgotten sight of the fact that (as David pointed out) most of the Spin objects that get re-used are largely written in PASM with a thin Spin wrapper. They are written that way for speed. In 9 cases out of 10, the part that we want to re-use is the PASM part. The Spin parts are easy to rewrite in C.
Catalina has a method to do that. This method preserves the PASM of OBEX object. In some cases it can do that without modifying the PASM at all, and in other cases some trivial modification is required. Even better, this modification can be done in such a way to make the object usable from either Spin or C.
This method could have been adopted across other compilers, but at the time, nobody seemed to appreciate the need. And so we have a re-run of the same debate every time a newcomer arrives.
Perhaps we should make this thread sticky!
Ross.
I see, so you're not talking about using the grand "use any language spec" then. Excellent! Thanks.
Yes, Catalina has a very rich set, and more get added regularly. But the point is not the C wrapper, as much as making the PASM component common to any language (not just Spin and C). That way, the Spin version can stay in the OBEX, and all high level languages can make use of any of them - they don't have to (as we both do now) create and maintain our own slightly modified copies.
With the inclusion of a simple preprocessor in Spin (courtesy of openspin), this should now be even easier.
Ross.
No, I now limit my scope to only two languages - C and Spin.
Ross.