ICCV7 C Code Posted Here + OBEX changes to accommodate GCC
Ken Gracey
Posts: 7,401
Hey all,
Two items to share with you.
The ICCV7 code has been removed from OBEX, so that OBEX is currently free of C code. In the future we will use OBEX for user uploads/sharing of C code that runs in our GCC compiler. The Parallax distribution will include libraries and examples, but we still need a place where users can contribute code.
I have posted the ICCV7 zip on this thread in case we find examples we wish to translate.
I could make this thread sticky if it's of use to everybody.
Ken Gracey
Two items to share with you.
The ICCV7 code has been removed from OBEX, so that OBEX is currently free of C code. In the future we will use OBEX for user uploads/sharing of C code that runs in our GCC compiler. The Parallax distribution will include libraries and examples, but we still need a place where users can contribute code.
I have posted the ICCV7 zip on this thread in case we find examples we wish to translate.
I could make this thread sticky if it's of use to everybody.
Ken Gracey
Comments
Ken Gracey
Hi Ken - I always thought the OBEX was all ICC code - what was the exception? If it was Catalina code, I'll add it in to the next Catalina distribution so it is not lost.
If you are going to include C code in the OBEX, it might be a good idea for contributors to be able to mark whether the code is C89 compatible or not. That way, the OBEX could contain any type of C code, and users of Catalina, ICC or GCC would know before they download whether it will work on their compilers.
However, I understand that the OBEX is one of Parallax's main support mechanisms for new users, so if you want it to contain only code compatible with GCC, that's cool as well.
Ross.
Hey Ross - there was a submital involving GPS that included Catalina C. Jeff Martin will contact the submitter and make sure that they know what were doing.
I fully support the idea of being able to identify the type of C code on OBEX. The challenge I have when it comes to OBEX is that nobody in Parallax maintains it - it was created by a contractor who's not available to continue the evolution we've needed, so the types of changes we make to it are very superficial. Adding pull-downs and other parameters is beyond what we're capable of doing in OBEX. I'd like to move out of OBEX entirely and into some kind of system that supports the same kinds of searching, cataloging, and comments/reviews. If we could identify this system then we could welcome Catalina C too.
Ken Gracey
This is a very exciting development.
A few months back I took some standard Obex code (keyboard, mouse, several display drivers) and translated them to C. It is a bit of a daunting task though and I think I only got about 10 done, but after a while I did get quite good at the process.
Take the Spin and Pasm and separate them. Define an array in C and pass all parameters via that array to the cog. Translate all the Spin into C.
That works fine for simpler objects, but there are some that don't conform to this rule and share variables that are defined in the Spin part of the code, which then become a location in hub and then because the compiler knows this location it can insert that location into the pasm code.
These variables can be scattered through the code and it makes it very hard if you want to define blocks of hub memory that are reused by other code later. To fix the problem you have to go through and find all instances of variables in pasm that are *not* passed in the parameter array at the beginning.
The other huge advantage of only passing parameters via the array at 'par' is that cog code can be reloaded over and over from other locations - eeprom, sd card etc. And it can save 14k of hub ram which is otherwise wasted with cog code.
I would very much like to see libraries of C code for all the common objects. I can share the ones I have done for mouse/keyboard etc if this would be helpful. But I would also like to make a request - if libraries of code are written would it be possible to write them using the standard where C and pasm code only share variables via the par array, and not via variables which can end up in any random location in hub?
In terms of c89 vs GCC syntax, I'm not 100% sure about this. Does GCC use the . format with objects, and C89 use functions? If so, it would be pretty easy to translate one to the other. Not much different to the process of translating Spin to C89.
Ah, so that explains why the password recovery mechanism can't seem to be fixed.
GCC allows you to share variables between assembly and C code, even code on other cogs. The linker fixes the references up automatically. You can tell the linker to place variables in specific sections if you want to isolate them.
There are some advantages to passing parameters only via mailboxes, though, and obviously that can be done as well.
GCC conforms to all the ANSI standards (including c89 and c99). I think what Ross was concerned about was whether the objects used any compiler specific extensions, of which GCC has a lot. For the kinds of things that are going in the OBEX it's pretty hard to stick to the ANSI standard without any Propeller specific hardware manipulation -- this doesn't necessarily have to be compiler specific, though, it could be in the form of libraries to access the hardware. It would be nice to have some common propeller header files that all C compilers could share.
Eric
Yes, that's it in a nutshell.
I did some work to make a header file that could be used to make Catalina and ICC compatible in terms of all the special Propeller hardware functions, and I could extend that to GCC as well (at least I assume I could - I haven't actually looked at how GCC implements these functions, but there are only a few possible ways to do so). This means that if anyone wants to write C code that could be run on any C compiler available on the Propeller then they can do so.
If people write C programs that use GCC extensions, then these programs will not be easily portable to other C compilers. This is fine if that was the intention, or if it is necessary for some reason - but it will also be potential source of annoyance to the users of the other available C compilers (including ICC, which some users bought through Parallax). This seems a bit silly when all that is required to avoid it is for OBEX users to have the option to mark their program as being "ANSI C" compatible - indicating the code can be compiled with any of the available C compilers.
Ross.
Sounds great.
Re compiler specific extensions, a header file sounds a good idea. Could you give an example of propeller specific hardware? Would that be something like "dira" and instead of having that command scattered through your code, you call a function which is in a header library to set the pin direction? And if so, does that use more code/run slower than putting a hardware specific instruction directly in the code?
In an ideal world, C would work like Spin, in that you grab the building blocks of code from the Obex (keyboard driver, display, mouse) and then plug them together with just a few lines of code. At the moment that is difficult because not many of those objects exist and I'm excited that is about to change.
Thinking about the differences between C89 and Objects, Spin has the . but I don't think it is fully exploited because where the . really shines is where you have no idea what methods an object has, so you just type in the name and a . and (in languages like .net), a dropdown menu appears with all the methods. It means you can quickly scan an objects methods and see if it does what you need. I hardly ever need to read the help as a result.
In C89 code in a text editor ends up rather unwieldy once you have thousands of lines of code. Having said that, with 'new and improved' catalina in code::blocks you can shrink down code you know works and in the end shrink everything down except the 'main'. This does make it easier to scan up and down the program between the 'main' and the function you are working on debugging.
I don't know much about C++ - can you use the . method like in Spin, and if so, are there text editors/IDEs that can exploit this with dropdown menus etc?
Yes, exactly -- all of the hardware registers on the propeller would be examples. The ANSI C standard obviously cannot address all of the possible registers on all machines, and so accessing that kind of thing relies on header files that aren't specified in the standard.
Setting the pin direction would be done in different ways by different compilers. In GCC it's: which translates directly into one machine instruction. Some other compilers may require that to be a function call: It'd be a pretty fast function, since it's not complicated. The intent is that we should define macros in a header file that will expand to the appropriate thing depending on which compiler is in use.
I think Eclipse does a pretty good job on C++ code (letting you see what methods are possible on an object with a popup menu, etc.). I assume that there are some other good IDEs for C++ as well.
Eric
Quite correct. Catalina already provides a header file that defines macros (much like the function call shown above), and then translates these into the appropriate statement (for the ICC compiler) or function call (for Catalina). The header file is portable and detects the compiler in use automatically. I'll update it to add automatic GCC detection and support.
Ross.
I have to say, as a C newbie I've found C quite confusing enough, and now it looks like I have to choose between GCC and Catalina? Why haven't Parallax put their support behind Catalina instead of starting a rival?
Hi simonl,
I don't recall seeing an announcement in these forums about it, but ImageCraft dropped support for their Propeller C compiler a long time ago. I think Parallax is just now getting around doing some "tidying up" with regards to their C strategy.
Catalina and GCC have different design objectives, and therefore appeal to different markets. Just as one example, Catalina will never support Aurduino code, whereas I believe this is on the roadmap for propGCC (at least it gets discussed regularly, and is certainly technically feasible). If you want to sell chips to Arduino fans, you will need GCC - this market has a significant non-technical user component who would probably not tolerate a different language (or even a different toolset). This is perfectly understandable - Parallax has a business to run, and Catalina wouldn't help them address that market.
Ultimately, users will choose whichever C compiler best suits their needs. Catalina is fairly mature at this point, so if you are interested in C you could start with Catalina and wait for propGCC to also mature. Nothing you learn on Catalina will be wasted when you move to GCC, and any program you write with Catalina should (eventually) be able to be run under propGCC.
Ross.
Thanks for the info' - makes more sense now. I'm glad I got a Propeller demo board with ICC - at least I got something worthwhile