Shop OBEX P1 Docs P2 Docs Learn Events
What about C++? — Parallax Forums

What about C++?

RsadeikaRsadeika Posts: 3,837
edited 2012-09-12 11:42 in Propeller 1
I was using a C++ tutorial to work PropGCC, and failure right from the start.
-> Error on iostream.h
-> Error on Using namespace std
-> Error on cout

It seems like the code below is the standard example for working with C++, so I guess some people might be a little disappointed to see the errors. Now, the question is, what exactly can you do in PropGCC C++? This is not a criticism, just trying to find out what exactly can be done in C++, that would look like C++? I looked in the wiki but did not find anything for the use of C++.

I have seen talk about using objects in C++, so I thought I would look into that to see how it would be of any benefit with the use of the Propeller. The concept of C++ Objects sounds interesting, just might be a good tool to manipulate the Propeller. Anybody have any ideas on this?

Ray
/**
 * @file test1.cpp
 * This is the main test1 program start point.
 */
//#include <iostream.h>  // This shows up as an error
//using namespace std;  // This shows up as an error

/**
 * Main program function.
 */
int main(void)
{
    cout << "Hello, World!";   // Does not know what cout is
    return 0;
}

«13

Comments

  • Heater.Heater. Posts: 21,230
    edited 2012-09-02 05:28
    C++ is the language of Arduino. There it works very well on those tiny AVRs. No reason it cant be used in a similar way on the Prop.
    Consider the objects of Spin. You can create similar object based prgrams in C++. In fact there is Spin to C++ translator, discussed on this forum that does exactly that.
    Now, be aware that some common C++ usage may not be suitable for a memory constrained MCU. For example that hello world program uses stream I/O to output the message.
    Streams require big string libraries and dynamic memory allocation. Perhaps too big to fit in memory. So I would not be surprised if the library support for streams was not included in the package at all. Hence the error.
  • jazzedjazzed Posts: 11,803
    edited 2012-09-02 11:10
    Rsadeika wrote: »
    I was using a C++ tutorial to work PropGCC, and failure right from the start.
    ....

    Your example is not valid. It should be:
    #include <iostream>
    using namespace std;
    
    
    int main(void)
    {
        cout << "hello";
        return 0;
    }
    
    

    C++ objects like iostream are not included as .h files.

    While it is possible to use standard name space libraries on Propeller, it is not practical.
    Many other C++ features are practical and beneficial.
  • RsadeikaRsadeika Posts: 3,837
    edited 2012-09-02 11:31
    Thanks jazzed, it was not the tutorials mistake, I added the .h. When working in PropGCC C++, what other include items do not need a .h added?

    Ray
  • jazzedjazzed Posts: 11,803
    edited 2012-09-02 12:00
    Any C++ standard library will not use .h
  • RsadeikaRsadeika Posts: 3,837
    edited 2012-09-02 12:36
    I got the below code to compile, but nothing shows up on the screen. I am using a QuickStart board, Memory Model XMMC, when it loads, man is this a slow process. It guess it highlights the slowness of the EEPROM chip. I cannot tell how big the actual program is, but one of the numbers are, 9528 bytes sent.

    The other thing that I tried was to comment out: using namespace std;, this has a direct effect on the cout command, meaning it was not available. Now I have to figure out how to get something to appear on the console screen.

    Ray
    /**
     * @file test1.cpp
     * This is the main test1 program start point.
     */
    #include <iostream>
    #include <propeller.h>
    
    #define NEWLINE '\n'
    
    using namespace std;
    
    /**
     * Main program function.
     */
    int main(void)
    {
        waitcnt(CLKFREQ/10+CNT);
    //    cout << NEWLINE << "Hello, World!" << NEWLINE << NEWLINE;
        cout << "hello\n";
        return 0;
    }
    
  • jazzedjazzed Posts: 11,803
    edited 2012-09-02 12:53
    jazzed wrote: »
    While it is possible to use standard name space libraries on Propeller, it is not practical.
    Many other C++ features are practical and beneficial.

    Using cout will bring in a 520KB library. Don't bother.
  • RsadeikaRsadeika Posts: 3,837
    edited 2012-09-02 13:12
    So, your suggestion is to forget about cout, and just stick with the good old printf(). OK, on to some more stuff using C++.

    I believe you mentioned that Tues you will have some kind of preview? I take it this concerns SimpleIDE? Any advance info that you can present at this time, especially as it concerns C++, or PopGCC for that matter?

    Ray
  • jazzedjazzed Posts: 11,803
    edited 2012-09-02 15:00
    Rsadeika wrote: »
    So, your suggestion is to forget about cout, and just stick with the good old printf().
    Exactly. You can still use other C++ features. I recommend reviewing this Wiki page.

    Rsadeika wrote: »
    Any advance info that you can present at this time, especially as it concerns C++, or PopGCC for that matter?
    It's mainly about compressed memory. The new CMM type produces code that will be about 42% smaller than comparable LMM type programs. Ted's tiny library will also be added.

    There are very few changes in SimpleIDE - the wish-list for that is being considered separately.
  • David BetzDavid Betz Posts: 14,516
    edited 2012-09-02 19:54
    jazzed wrote: »
    Exactly. You can still use other C++ features. I recommend reviewing this Wiki page.


    It's mainly about compressed memory. The new CMM type produces code that will be about 42% smaller than comparable LMM type programs. Ted's tiny library will also be added.

    There are very few changes in SimpleIDE - the wish-list for that is being considered separately.
    By the way, Ted's tiny library also includes a really simple C++ stream implementation that will allow your cout example to work. This should let you do console output using normal C++ syntax.
  • RaymanRayman Posts: 14,826
    edited 2012-09-03 04:39
    Will the tiny library let you use cin and cout in plain LMM mode?

    Seems like a big problem for C++ if the library that allows cin and cout >32kB...
  • RsadeikaRsadeika Posts: 3,837
    edited 2012-09-03 04:54
    I know jazzed does not recommend this, but..

    I still want to pursue the use of cout command. I have switched over to the DNA board, so I can use the flash ram more, and to see how much faster the loading goes. Much faster, are my first indications. The program below compiles, but I get an "error: Loading program image failed". I also see:
    9528 bytes sent
    Verifying RAM ... Loading cache driver 'winbond_sqi_flash_cache.dat'
    1732 bytes sent
    error: Loading program image failed

    My board settings:
    DNA:SQI
    C++
    XMMC
    -Os Size

    I tried both the XMMC, and XMM-Single Memory Model, both came up with - "error: Loading program image failed". I also get the same error with the QuickStart board. So, I am not sure where the problem is on this one. Sure would like to see something appear on the console screen.

    Ray
    /**
     * @file test2.cpp
     * This is the main test2 program start point.
     */
    #include <iostream>
    #include <propeller.h>
    
    using namespace std;
    
    /**
     * Main program function.
     */
    int main(void)
    {
        int n = 1;
        while(1)
        {
        waitcnt(CLKFREQ/10+CNT);
        cout << "Hello" << n;
        n++;
        }
        return 0;    
    }
    
  • Heater.Heater. Posts: 21,230
    edited 2012-09-03 04:58
    Rayman,
    Seems like a big problem for C++ if the library that allows cin and cout >32K

    Not really, you don't have to be using all the features of a language and it's standard libraries. People use C on MCU's (PIC's, AVR's etc) with tiny memory spaces, they just don't expect to be using printf or whatever else does not fit. We can use C to good effect to create in COG code where such thing for sure do not fit. The Arduino uses C++ with similar limitations to those Jazzed has described.
  • Heater.Heater. Posts: 21,230
    edited 2012-09-03 05:00
    Jazzed,
    The new CMM type produces code that will be about 42% smaller than comparable LMM type programs.

    What? Have I missed something? Are you saying someone is working on a CMM target for GCC similar to Catalina's?
  • David BetzDavid Betz Posts: 14,516
    edited 2012-09-03 05:16
    Heater. wrote: »
    Jazzed,



    What? Have I missed something? Are you saying someone is working on a CMM target for GCC similar to Catalina's?
    Yes, Eric Smith is working on a bytecode instruction set for PropGCC. If you're comfortable with using Google Code you can download it from the "compressedcode" branch of the PropGCC repository. I think Steve is going to make a preview release this week.
  • RossHRossH Posts: 5,510
    edited 2012-09-03 05:20
    David Betz wrote: »
    Yes, Eric Smith is working on a bytecode instruction set for PropGCC. If you're comfortable with using Google Code you can download it from the "compressedcode" branch of the PropGCC repository. I think Steve is going to make a preview release this week.

    Gosh - where have you guys been? CMM is sooo yesterday! :lol:
  • RsadeikaRsadeika Posts: 3,837
    edited 2012-09-03 05:21
    Some thoughts. I just looked in the dir where test2.cpp is, and I noticed a.out (test2.cpp) is 3,706KB. I guess my question is, if a 3,706KB file is trying to be loaded into a 32KB space? Then of course the image load would fail, but I thought that is where the LMM/XMM comes in to play?

    Ray
  • Heater.Heater. Posts: 21,230
    edited 2012-09-03 06:42
    David,

    Wow, that Eric is a dynamo, amazing. I'll try and find time to check it out.
    Sounds like it might get interesting mixing C compiled into native COG PASM with a project in CMM.

    RossH,
    CMM is sooo yesterday!

    He he, All good ideas are worth, err.. borrowing, and you have some of the best:)
  • David BetzDavid Betz Posts: 14,516
    edited 2012-09-03 08:30
    Rsadeika wrote: »
    Some thoughts. I just looked in the dir where test2.cpp is, and I noticed a.out (test2.cpp) is 3,706KB. I guess my question is, if a 3,706KB file is trying to be loaded into a 32KB space? Then of course the image load would fail, but I thought that is where the LMM/XMM comes in to play?

    Ray
    If the image really is 3.7mb then that is bigger than the flash chip so even XMM won't help. Of course, a.out is an ELF file and probably contains lots of symbol table and maybe debugging information depending on the options used to generate it. It could be that the loadable image itself isn't nearly that big. You can use propeller-elf-objdump to find out if you're curious.
  • jazzedjazzed Posts: 11,803
    edited 2012-09-03 10:35
    RossH wrote: »
    Gosh - where have you guys been? CMM is sooo yesterday! :lol:

    The post picture below from the private forum references a post from Eric on Jan 24, 2012.
    attachment.php?attachmentid=95295&d=1346693073
    Which was followed by this: http://forums.parallax.com/showthread.php?139597-Question-about-C-feature-(cout)&p=1093117&viewfull=1#post1093117

    Which was followed by this: http://forums.parallax.com/showthread.php?140896-C-Spin-benchmarks&p=1106669&viewfull=1#post1106669

    You get credit for making it a higher priority and showing the value of it. Thanks for your service.

    --Steve
    1024 x 193 - 28K
  • RaymanRayman Posts: 14,826
    edited 2012-09-03 12:59
    Ross also demonstrated that the concept can work. It's a lot easier to do something once you've seen it work...
    The CMM really is a game changer for C on Prop 1. Probably irrelevant for Prop 2, I imagine.

    BTW: I wonder if Parallax would ever consider a special run of Prop 1 chips with the spin interpreter replaced by CMM C interpreter...
    Would it work?
  • jazzedjazzed Posts: 11,803
    edited 2012-09-03 13:12
    Rayman wrote: »
    Ross also demonstrated that the concept can work.

    Indeed.

    That's part of what I meant by "and showing the value of it." That was my edit after giving the post more thought.
  • Heater.Heater. Posts: 21,230
    edited 2012-09-03 14:05
    Rayman,
    Probably irrelevant for Prop 2, I imagine.

    Why? The Prop II RAM is bigger but it's still tiny.

    A Prop I with a CMM interpretter sounds briliant. Can such an interpreter fit in a COG like the Spin interpretter does?
  • David BetzDavid Betz Posts: 14,516
    edited 2012-09-03 15:18
    Rayman wrote: »
    Ross also demonstrated that the concept can work. It's a lot easier to do something once you've seen it work...
    The CMM really is a game changer for C on Prop 1. Probably irrelevant for Prop 2, I imagine.

    BTW: I wonder if Parallax would ever consider a special run of Prop 1 chips with the spin interpreter replaced by CMM C interpreter...
    Would it work?
    The two CMM interpreters are probably not at all alike although I guess I can't be certain of that because I haven't seen a detailed description of either. They were certainly developed independently other than a few exchanges in these forums. I don't want to take anything away from either programmer but it is obvious that you can increase code densiity by adopting a more compact instruction set. Spin demonstrated that to all of us a long time as did ZOG. The trick was to come up with an encoding that gave good performance as well as good code density. I think Ross and Eric both succeeded in doing that independently.
  • David BetzDavid Betz Posts: 14,516
    edited 2012-09-03 15:19
    Heater. wrote: »
    Rayman,



    Why? The Prop II RAM is bigger but it's still tiny.

    A Prop I with a CMM interpretter sounds briliant. Can such an interpreter fit in a COG like the Spin interpretter does?
    It does fit in a COG for PropGCC and I'm sure also for Catalina.
  • Heater.Heater. Posts: 21,230
    edited 2012-09-03 15:25
    That's interesting becaus a while back there was this brain dead idea to create a "not-quite-C" C compiler that targetted the spin byte code interpreter. With the good intention of bringing C to the Prop fro educational purposes. CMM seems to forefill that requirement whilst also being "proper C". Excellent.
  • RossHRossH Posts: 5,510
    edited 2012-09-03 16:31
    jazzed wrote: »
    The post picture below from the private forum references a post from Eric on Jan 24, 2012.
    attachment.php?attachmentid=95295&d=1346693073
    Which was followed by this: http://forums.parallax.com/showthread.php?139597-Question-about-C-feature-(cout)&p=1093117&viewfull=1#post1093117

    Which was followed by this: http://forums.parallax.com/showthread.php?140896-C-Spin-benchmarks&p=1106669&viewfull=1#post1106669

    You get credit for making it a higher priority and showing the value of it. Thanks for your service.

    --Steve

    Words fail me ...
  • Heater.Heater. Posts: 21,230
    edited 2012-09-03 22:29
    Jazzed and RossH,

    Now now, the pair of you. You should be ashamed. The idea of a compressed code as a target for C compilation on the Prop dates from early 2010. Ever heard of Zog:)http://forums.parallax.com/showthread.php?119711-Zog-A-ZPU-processor-core-for-the-Prop-GNU-C-C-and-FORTRAN.Now-replaces-S


    Anyway, my hat off to Ross, Jazzed, Eric and all involved in bringings C to the Propeller world, especially in such inovative ways. You guys have been moving mountains to get C to play well on the Prop, where others may have dismissed it as "not a suitable architecture for C", myself included.
  • RsadeikaRsadeika Posts: 3,837
    edited 2012-09-07 05:25
    I am now using the new preview edition SimpleIDE 0-8-5, below is a simple "Hello world" C++ style program. For whatever reason it cannot find tinyiostream. The properties window show:
    C:/propgcc/bin/propeller-elf-gcc.exe
    C:/propgcc/propeller-load/
    E:/PropGCC_SimpleIDE/PropGCC/test1/test3/

    Ray

    Project Directory: E:/PropGCC_SimpleIDE/PropGCC/test1/test3/

    propeller-elf-c++ -o a.out -Os -mlmm -I . -fno-exceptions -fno-rtti test3.cpp
    test3.cpp:5:24: fatal error: tinyiostream: No such file or directory

    compilation terminated.

    Done. Build Failed!

    Click error or warning messages above to debug.
    /**
     * @file test3.cpp
     * This is the main test3 program start point.
     */
    #include <tinyiostream>
    #include <propeller.h>
    
    using namespace std;
    
    /**
     * Main program function.
     */
    int main(void)
    {
        waitcnt(CLKFREQ/6+CNT);
        cout << "Hello World!";
        return 0;
    }
    
  • RsadeikaRsadeika Posts: 3,837
    edited 2012-09-07 07:28
    I found the problem(s), you need <tinystream>, and in the linker selections you have to have Tiny Lib checked. Now it seems to run correctly in all memory models except for COG, of course. Will there be a way of getting around the FILE * pointer, and etc limitations?

    Ray
    /**
     * @file test3.cpp
     * This is the main test3 program start point.
     */
    #include <tinystream>
    #include <propeller.h>
    
    using namespace std;
    
    /**
     * Main program function.
     */
    int main(void)
    {
        waitcnt(CLKFREQ/6+CNT);
        cout << "Hello World!"; 
        return 0;
    }
    
  • David BetzDavid Betz Posts: 14,516
    edited 2012-09-07 07:40
    Rsadeika wrote: »
    Will there be a way of getting around the FILE * pointer, and etc limitations?
    I'm not sure what you mean by the FILE * pointer limitiation but limitations are what libtiny is all about. The way it manages to be smaller is by providing fewer features. If you need filesystem support then you will need to use the full library and possibly external memory.
Sign In or Register to comment.