C++ for the Prop- Works!
heater
Posts: 3,370
Attached is an experimental demo of programming in C++ for the Prop using GCC and Zog.
As delivered it runs a binary, FullDuplexSerialPlus_Test.bin, from HUB Ram. The C++ source of this binary is included along with the Makefile used to build it. Should work on pretty much any Prop platform that can talk to the BST serial terminal.
Output is like so.
But there is a lot more going on here with FullDuplexSerialPlus_Test.bin.
1) FullDuplexSerialPlus.cpp is a rewrite of FullDuplexSerialPlus.spin in C++.
Actually only the basic start, stop, tx and rx methods.
2) The PASM COG code of FullDuplexSerialPlus.spin is extracted using BSTC with the -c switch.
This gives a binary file containing only the DAT block required for a COG to run.
3) The resulting DAT block is converted to a relocatable object module for linking with GCC using GCC's objcopy command.
4) The FullDuplexSerialPlus class, the processed DAT block and the test main function are then all linked together as normal object files.
5) The C++ version of FullDuplexSerialPlus is starting the FDS PASM blob in A COG.
Still needed is cogstop and locks etc etc.
As usual they may take a while now for me to get around to but at least we have here a running example of a new language for Humanoido's Propeller language list[noparse]:)[/noparse]
Edit: I have up dated this as the FullDuplexSerial in C++ is now working in V0.20.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 7/1/2010 7:23:08 PM GMT
As delivered it runs a binary, FullDuplexSerialPlus_Test.bin, from HUB Ram. The C++ source of this binary is included along with the Makefile used to build it. Should work on pretty much any Prop platform that can talk to the BST serial terminal.
Output is like so.
ZOG v0.20 (HUB) All work and no play makes Jack a dull boy. All work and no play makes Jack a dull boy. All work and no play makes Jack a dull boy. All work and no play makes Jack a dull boy. All work and no play makes Jack a dull boy. All work and no play makes Jack a dull boy. All work and no play makes Jack a dull boy. All work and no play makes Jack a dull boy. All work and no play makes Jack a dull boy. All work and no play makes Jack a dull boy. These chars echoed by FullDuplexSerial in C++.
But there is a lot more going on here with FullDuplexSerialPlus_Test.bin.
1) FullDuplexSerialPlus.cpp is a rewrite of FullDuplexSerialPlus.spin in C++.
Actually only the basic start, stop, tx and rx methods.
2) The PASM COG code of FullDuplexSerialPlus.spin is extracted using BSTC with the -c switch.
This gives a binary file containing only the DAT block required for a COG to run.
3) The resulting DAT block is converted to a relocatable object module for linking with GCC using GCC's objcopy command.
4) The FullDuplexSerialPlus class, the processed DAT block and the test main function are then all linked together as normal object files.
5) The C++ version of FullDuplexSerialPlus is starting the FDS PASM blob in A COG.
Still needed is cogstop and locks etc etc.
As usual they may take a while now for me to get around to but at least we have here a running example of a new language for Humanoido's Propeller language list[noparse]:)[/noparse]
Edit: I have up dated this as the FullDuplexSerial in C++ is now working in V0.20.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 7/1/2010 7:23:08 PM GMT
zip
219K
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Not quite "just" yet.
Whether C or C++ there is fair bit to do yet. My plan is to firstly eradicate all Spin code from an app running Zog and C/C++. A loader/starter COG in PASM will get the Zog Cog running and then terminate. From there on everything needs to happen in C/C++.
So before we can get external RAM Zog running I want to equip HUB Zog with cognew/cogstop/locks etc etc. Then there will have to be C/C++ conversions of VMCog and SD card low level drivers. Hopefully there is a C FAT file system small enough to fit. The ones I have now are quite big. Then HUB Zog can start up ext RAM Zog as the Spin code does now.
Then we have the possibility of big C programs but we also need to implement all those cognew/cogstop etc Prop features for big Zog.
Aside: Well of course big external progs will be able to be run before all of the above is done but it lacks "purity" in my mind.
The idea with this release was just to show that it is possible to use C++ in a most basic way to mimic the objects of Spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Good, it gives me time to fix the current VMCOG, and make the "bigvm" version!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Yeah, sort of, that is kind of weird for my hobby projects.
Still a lot of what I have on the road map would be better done with SD card, FDS etc properly sorted out with mailboxes and minos. So if they turn up I could easily be diverted. As it is this converting of Spin objects to C++ seems to be the easy way to go, at least for the objects with simple Spin code and straight forward interface to PASM though HUB memory.
Also it encourages me to get the Propeller specific features working properly in the interpreter.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
PASM blob reuse is a good way to get OBEX COG features quickly.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I guess string will require a heap and memory manger which is, I have too say, is a bit out of my league just now.
Actually I've never used the STL despite programming in C++ quite a lot in recent years. I have used templates in some home grown libraries and more recently those that you end up having to use in Qt. I see no reason why templates could not be used here though.
Just for now I'm aiming to use the minimum amount of C++ features to accomplish what Spin does with objects. To show that it can be done with no code size or performance overheads over doing it in C. Did you see the example of objects in C vs C++ objects that I posted a while back in the Zog thread? The C++ code actually came out smaller by a couple of instructions.
If I actually get this PASM blob reuse to work, which I'm sure it will, then many objects from OBEX and elsewhere can be sucked into the GNU world with just a couple of hours effort.
Helps if they are configured neatly through PAR parameters and have a small clean interface Spin methods. FDS, VMCog and sddpiFemto are good examples.
Zog itself is not a good example. At the moment it has too many things to be set up by "poking" them into the DAT block from Spin prior to launching the COG.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I saw your reference to BSTC being able to deliver COG blobs. I had no idea it could do that. I wrote a utility to in 2008 to perform that function for me. Ross is using that in Catalina now for one of his code modes.
The string class might be missed [noparse]:)[/noparse] Chained memory managers are not so hard. I'm using the one I developed for the JVM project with the Spin based HTML Terminal. So far I'm using stack, queue, arraylist, and hashtable without troubles. Currently it uses word wide pointers only to minimize overhead so that can be a problem for bigger address spaces. Power of 2 chunk allocation is used to make free easier. I may include garbage collection for Spin implementation later since keeping track of free is always difficult for users. I want to use a Heap ADT later if I add garbage collection.
Interesting that C++ code size is smaller than C in some cases. C++ always gets hammered for inefficiency, but I suspect that probably has more to do with crazy polymorphism and base class usage by users [noparse]:)[/noparse]. Sorry that I missed your examples.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Don't tell anyone, I did the same in my version of FDS[noparse]:)[/noparse]
In never occurred to me to raid the OBEX for C code.
You can find examples of C vs C++ objects here : http://forums.parallax.com/showthread.php?p=878273 where I have posted examples of the code generated for calls to C methods with an object parameter or to normal C++ method invokation.
That is in C: someMethod(&someInstance, param1, param2, ....); vs this in C++ someInstance.someMethod( param1, param2, ....)Turns out the code sequence generated are pretty much identical except for some reason C++ shaved a byte of of one of them.
Hence the idea to use C++ sticking to a very basic "Spin style". No objects on heap or stack, no new/delete, no inheritance, polymorphism, no string or streams etc etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I knew bstc could generate "blobs", but I'm not ready to move Catalina to bstc entirely, and I didn't want to use both HomeSpun and bstc (Catalina is complex enough to support as it is!). Your code filled the gap very nicely, and will be included in the forthcoming release (2.6).
@heater,
It is quite understandable that C++ compilers generate better code than C compilers. Put simply - they have to! It is truly astonishing how bloated even quite simple programs can end up when written in C++, so the compiler vendors had to spend a lot of time and money improving their code generation. Unfortunately, some of the problems are inherent in the language itself and there's only so much they can do. This is one of the reasons C++ never overtook C in embedded markets, and is in fact now on the decline (guess which language is still on the increase? See www.embedded.com/218600142!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Interesting statistics there re C vs C++. "Real men program in C" indeed, is that "real old men..." [noparse]:)[/noparse] Oddly enough the project I'm working on at the moment is mostly written in Pascal which I've never seen used for an embedded project before.
Anyway out of curiosity I'm going to continue with this experiment to use C++, as simply as possible, to mimic Spin objects. It seems like a natural fit without any downside/overheads...so far.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
No question that C is old - why, it's almost as old as I am (and that's really old!)
There's probably a moral in there somewhere about "sticking to what you're good at!"
I watch your C++ progress with interest - I don't think you're going to knock C off its pedestal anytime soon, but you may indeed succeed in taking a few chunks out of SPIN! - SPIN++ perhaps?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Sorry to derail your thread again, but while I was just looking for something else I rediscovered this link www.tiobe.com/index.php/content/paperinfo/tpci/index.html, which is the one I originally wanted to use in my previous post but couldn't find.
The only language that beats C is Java - and C is on a sharp increase while Java is on a sharp decrease. C++ is steady but trailing by a long way. I really have no idea why this should be so, but I think it may have something to do with the general decrease in "server side" computing and the big increase in "client side" computing - particularly on hand held devices. One might expect that a lot of those devices are programmed in C#, Java and the like - which may be true of the expensive iPads etc - but the numbers seem to indicate that C is fighting on!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Strangely enough at The University of Kent at Canterbury where I was studying at the time they had, since 1971, developed their own multi-user system for their ICL 4130 computer. The Kent Online System (KOS).
To do this they developed their own systems programming language, "SYMPL" I think it was called, to build it with.
From what I remember of the courses I attended SYMPL looked a lot like C and KOS was designed to be small and portable like UNIX.
So there we have it. A totally different evolutionary path that leads to much the same result. There is no need for anything else but a C like language in that space. I put up Linux as further support of this hypothesis.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That TIOBE index you link to seems a bit iffy to me. Mostly based on the results of search engines. So of course the staple languages C, C++, Java etc get a lot of hits as there is a lot of people using and learning to use them. But then something new like Google's Go can hit the charts in a big way as everyone wants to find out what this new shiny thing is.
Aside: Given that software creation is supposed to be "engineering" it always amazes me how susceptible to fads and fashions it is.
Interesting point about hand held devices. Your observation about C hanging on in hand held devices is proably true but about to change. Notice that Google's Android is intended to have all it's apps written in Java. Even if Android is based on Linux I have yet to find out if you can even get a native C/C++ app on there. Then there is the sharp rise in Objective-C due to the iPhone.
I was happy to see ADA is hanging on recently, I just got a news release email notification from Adacore about all the new goodies in ADA. Most surprising of which is they are now seriously supporting ADA on the AVR.
Anyway when I use Java, or Python or whatever what am I really using? Aren't a lot of these high level systems implemented in C.
Still all of these devices are sitting on operating system software in C
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
N.B. This FullDuplexSerialPlus is slightly tweaked to make it easier to load and start from C++.
This is a bit brutal, after the first cogstart performed by C++ the old Spin FullDuplexSerial COG and the Spin hardware emulation of Zog are both stopped. It's just Zog and FDS in C++ after that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Can you list the unique features of C++ that will be supported?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I was wondering what to do next. All that Spin support code is damn useful for debugging when things go wrong, there is single stepping etc. Also currently the C printf ends up using the I/O support there.
Looks like a should create a separate branch of Zog with all that Spin removed and just a simple loader in place. Then C/C++ could have all the HUB RAM to itself.
ultimately all the current Spin debug and support would be reproduced in C.
"Can you list the unique features of C++ that will be supported?"
That's a tall order. C++ has so many features I'm not sure where to start. I probably don't know them all.
Ultimately the ZPU tool chain is using gcc version 3.4.2 so that defines the C++ we have available.
Except I'm not sure yet what we have in the ZPU libraries. Which are basically cut down libs to support small memory embedded systems. For example trying to use "new" results in "undefined reference to `__gxx_personality_sj0'" What ever that is. Perhaps we can plug our own allocator in there.
I was planning on just ignoring anything that needs new/delete, creates objects on the stack, uses inheritance/polymorphism, uses templates etc. Just stick to the basic statically defined objects. As Spin does.
BUT Just for fun I created a child of FullDuplexSerialPlus with one new member function. It works just fine and does not seem to have bloated the code much.
Then moving the instantiation of an FDS into function scope, on the stack, works fine.
I see no reason why templates should not work.
Etc Etc... I'll see what we can do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Straight ZOG C does have malloc/free right?
Thanks,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Perhaps you missed it but two posts back I mentioned that inheritance and polymorphism work fine. At least in the simple experiment I did quickly.
What ZPU does not have is a "new" operator due to the lack of a libstc++ as far as I can tell. So no objects on the heap. But perhaps an allocator could be plugged in there.
Objects created on the stack is working.
ZPU does not support exceptions. Which worries me not, I hate them.
Now, FullDuplexSerial, for example, in C++ could of course be done in C. With structs to hold the instance variables and pointers to the instances one could have multiple FullDuplexSerials running. No problem, but what I have found and shown here is that letting C++ take care of that in a FDS class has no overhead what so ever and makes the code look much simpler.
So there is my take on C++ in small systems, use it carefully/sparingly where it makes the code simpler/clearer. Beware of all the myriad of features that can eat memory or performance.
malloc/free seem to work OK. At least it compiled when I put them in my main() and then ran through OK. Did not try to read/write the malloced memory yet or check where it is even.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You may may laugh, but when I started Catalina I actually had Ada in my sights. I don't seriously think porting GNAT to the Prop is ever going to be possible (although originally I would have said the same about C++, and look at how far you've come already!) but I really love the Ada tasking model. My original idea was to produce a simple variant of C with the tasking model of Ada (i.e. task types, rendezvous etc) in place of all the traditional butt-ugly C hacks (setjmp/longjmp co-routines, fork/exec, pthreads etc).
I still work on it when I have time - maybe it will one day make a public debut!
Ross.
P.S. Congrats on the C++ progress!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Anyway, all this work is great news. Everyone is learning so much more it can only help in producing better objects, etc for our beloved prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
No - Ada is very much alive and well, but since losing its Defence mandate it is very much a niche player - much like the Propeller!
Ada is still used in defence projects (although nowhere near as widely as it used to be) and is also now quite often used in avaiation and other safety-critical situations where coding errors can cost many lives. The fact that it is not used more widely is a sad reflection on how cruel the "cost in lives per coding error" equations can be - in aviation it is obviously worth it. In other industries it's unfortunately cheaper to simply pay the next of kin.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Yes, classes in a stack context should work normally. Inheritance in any form is better than using hundreds of #ifdefs. I also despise exceptions, and use them only when unavoidable.
Getting a memory manager working with ZOG C++ would be a good step in the right direction.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Why should GNAT ADA not support the Prop via LMM or such. It has been compiling code for 8 bit AVR for many years now. As I said somewhere AdaCore are now seriously supporting AVR. And the Lego Mindstorm NXT !!!
This is all too big for me to think about but we have bigger brains around here...
Re: The tasking model. Rendezvous between threads on different cogs would be great. But also take a look at the XC language from, dare I say it XMOS, which adds parallelism and multi-core support to C in a nice way. www.xmos.com/support/documentation
So for example one can write something like:
par { func1(); func2(); }to get two threads going even on different cores.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Object instances on stack - Check, yep.
Inheritance - Check, yep.
Exceptions - No and never.
New/Delete - Not yet.
You know I forgot that simple use of inheritance to replace "ifdef", I would have mentioned it earlier. Strangely enough the first C++ classes I ever wrote years ago were for abstracting serial ports of different types. Seems I'm still working on it[noparse]:)[/noparse]
As far as I can tell adding New/Delete is just a case of providing some simple functions to define these operators that then use malloc and free. Must test malloc and free some more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'l have a look at the XMOS stuff if you promise not to tell Cluso!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
However I remember such parallel constructs "par" for creating processes on the same or other cores and "chan" for communication between them were also in a parallel C by Helios, I believe. They wanted to take these concepts from Occam on the Transputer and make them friendly to C programmers. David May and Xmos are now carrying on that idea twenty years later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thank you for pushing me along a bit. I learned some things about C++ never came across before and never knew I needed[noparse]:)[/noparse]
For example the existence of "placement new". This may be old to you. It basically means that when you create a new instance of a class you can specify the memory address it will live at. So I set up a simple experiment: malloc a chunk of memory the sizeof the FullDuplexSerial object. Then use placed new to create an FDS in that memory.
// Get some memory for an instance of fds char* m = (char*) malloc (sizeof (FullDuplexSerialPlus)); // Create an fds object in that memory FullDuplexSerialPlus* fds1 = new (m) FullDuplexSerialPlus (31, 30, 0, baud); ...// Use fds //explicit destructor invocation, don't use delete fds1->~FullDuplexSerialPlus(); // Return the memory. free (m);Works just fine.
One could of course override new/delete using malloc/free for any classes one wants on the heap (or all classes).
So the check list is now:
Object instances on stack - Check, yep.
Inheritance - Check, yep.
Exceptions - No and never.
New/Delete - Check, yep.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.