Shop OBEX P1 Docs P2 Docs Learn Events
Getting started with P1 and how to code — Parallax Forums

Getting started with P1 and how to code

cybersackcybersack Posts: 10
in Propeller 1
This post by me was originally posted in the wrong place ... Propeller 2 Specs ... moving it to a better place.
Some very kind people already replied to the original posting, so you may have some related material there

Thanks for some really informative replies.
Please let me know if I am posting in the wrong place and I will move the topic accordingly.

So, in a nutshell, it sounds like:
* C libraries consume excessive RAM on a P1
* on a P1, Spin + Propeller Assembler is generally advised/preferred
* there are, however, optimized C libraries provided by Parallax which reduce the overhead (are they pre-loaded in the firmware ?)
* Spin byte-codes are especially compact (I assume like in java byte-code ops, there is a seek nature to the instruction set allowing smaller chunks to be loaded)

I have read this document:
https://propgcc.googlecode.com/hg/doc/Memory.html

About me:
* I am less comfortable playing with registers than I am with traditional object modelling and encapsulation (C++/Java where the metal is far far away)
* I have only rudimentary Assembler experience and would be significantly less productive there ... BUT if the potential win is significantly greater than choosing alternative paths, I would still adopt it
* C is fine (if I have good debugging tools with which I am proficient)

Spin sounds excellent from the perspectives of lower entry barriers and thinking-in-object-land.

Questions I have:
* Is Spin a language that you people feel has led you to obtain better results (quality/productivity) ?
* Is Spin a language that will be offered on the P2 ?

Otherwise, I am off to try and learn how to put my first project together .... and I am happy to hear anything you guys have to say :)

Once again, thanks for reading !
«1

Comments

  • jmgjmg Posts: 15,173
    Just to confuse you some more...
    I would include PropBASIC in that 'language list'
    one starting thread, is an example in use...
    http://forums.parallax.com/discussion/123170/propbasic-reciprocal-frequency-counter-0-5hz-to-40mhz-40mhz-now
  • DavidZemonDavidZemon Posts: 2,973
    cybersack wrote: »
    C libraries consume excessive RAM on a P1

    Nope. If RAM is your main concern, use the "CMM" memory model which my benchmarks have shown to be roughly equivalent in speed and size to Spin (others have seen better and worse performance though).
    cybersack wrote: »
    on a P1, Spin + Propeller Assembler is generally advised/preferred

    This might be true, but I think that's pretty well expected. PropGCC has only been around for three years I think but Spin and the PropTool have been around since the chip was released some (15???) years ago. I'm ignoring all other languages and compilers (like Catalina) because these are the only two "Parallax supported" options which I think therefore gain the most popularity.
    cybersack wrote: »
    there are, however, optimized C libraries provided by Parallax which reduce the overhead (are they pre-loaded in the firmware ?)

    Ha :) the ones provided by Parallax in C are not optimized, and were not intended to be. They're meant to be easy and in C, not fast or small. libpropeller, PropWare and objects converted using spin2cpp are fast. Most objects in the Learn folder (Simple libraries) are not.
    cybersack wrote: »
    Spin byte-codes are especially compact

    As mentioned in my above point, they're roughly equivalent to CMM instructions.
    cybersack wrote: »
    I am less comfortable playing with registers than I am with traditional object modelling and encapsulation (C++/Java where the metal is far far away)

    You're gonna love PropWare.
    cybersack wrote: »
    I have only rudimentary Assembler experience and would be significantly less productive there ... BUT if the potential win is significantly greater than choosing alternative paths, I would still adopt it

    As Cluso mentioned in the other thread, the Propeller's assembly instructions are quite easy. On par with Intel 8051 - they're great! Definitely give it a shot sometime. You don't have to be an expert in every single instruction - just post your code once it's working and the PASM experts around here (not me) will tell you how to improve it with some of the less common opcodes.
    cybersack wrote: »
    Is Spin a language that you people feel has led you to obtain better results (quality/productivity) ?

    This is obviously very personal and will differ for everyone. I'm sure others will reply to this question with an enthusiastic "YES!"
    But, for me, no. I love C++ in embedded systems. It's been very hard to create PropWare and I've had to learn way more than I ever expected to, but I've been able to do things that just aren't possible with Spin. Certainly Spin can do things that C++ and PropGCC can't, but for me, the tradeoff is well worth it. I'm a very happy camper in C++/PropGCC land. I'm also a huge fanatic of fcache and inline assembly - the combination of which have allowed me to read/write files on an SD card with a single cog and a speed that is much faster than the Simple libraries.
  • MJBMJB Posts: 1,235
    and just to mention it in the list of languages:
    There is this wonderful and fast
    TACHYON Forth by Peter
    forums.parallax.com/discussion/141061/tachyon-o-s-furiously-fast-forth-compact-bytecode-interactive-fat32-lan-vga-more#latest
  • David BetzDavid Betz Posts: 14,516
    DavidZemon wrote: »
    Certainly Spin can do things that C++ and PropGCC can't, but for me, the tradeoff is well worth it.
    What can Spin do that C/C++ cannot?

  • Cluso99Cluso99 Posts: 18,069
    Most of the objects have a PASM module that runs in its own cog. Some of these pasm routines are quite complex because we have pushed the prop to its limits to make the code run fast, or to squeeze the program into cog ram. You can treat these as black boxes.

    With the prop P1 there are NO INTERRUPTS. So you don't have to worry about them. You just program a separate little module to run in its own cog (core).

    So you mix spin and pasm programs. Where you don't need to have the speed just use spin. Its easy to use providing you don't try to squeeze everything out of it. ie avoid using the +=, ~, ~~, and other hard to read heiroglifics (wrong spelling :( ). use x := x+1 rather than x++, x := x + 2 rather than x += 2, x := 0 rather than x~, etc. Easier to read until you get used to spin. The same applies to C.

    Spin can be thought of a simpler language but it REQUIRES indentation. PropTool has a switch to show how indentation is being applied. Not sure about the other IDE's.

    If you are more familiar with C then by all means use it.

    And if you want to learn a type of forth, then you cannot go past Peter's TACHYON. It's a realtime development language right on the prop and its running on the P2 FPGA too.
  • DavidZemonDavidZemon Posts: 2,973
    David Betz wrote: »
    DavidZemon wrote: »
    Certainly Spin can do things that C++ and PropGCC can't, but for me, the tradeoff is well worth it.
    What can Spin do that C/C++ cannot?

    Two things come to mind. No need to worry about types in spin. And spin has less overhead for calling methods, so tight loops that invoke a function are much slower in C or C++ (I remember this was one of the big takeaways when benchmarking the TFT drivers a while ago)
  • David BetzDavid Betz Posts: 14,516
    DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    Certainly Spin can do things that C++ and PropGCC can't, but for me, the tradeoff is well worth it.
    What can Spin do that C/C++ cannot?

    Two things come to mind. No need to worry about types in spin. And spin has less overhead for calling methods, so tight loops that invoke a function are much slower in C or C++ (I remember this was one of the big takeaways when benchmarking the TFT drivers a while ago)
    I didn't know about the function call overhead. That's unfortunate. Is this really because Spin method calls are faster or is it that these inner loops use built-in functions in Spin that are compiled inline where C/C++ uses actual function calls?

  • DavidZemonDavidZemon Posts: 2,973
    This post from this thread is where I got my info.
  • ElectrodudeElectrodude Posts: 1,657
    edited 2016-01-05 23:58
    DavidZemon wrote: »
    And spin has less overhead for calling methods, so tight loops that invoke a function are much slower in C or C++.

    Really? Why? I thought Spin function calls were expensive compared to PASM ones! Does the CMM kernel not have bytecodes (or whatever) for calls and returns or something? If not, why doesn't someone fix that?
  • David BetzDavid Betz Posts: 14,516
    DavidZemon wrote: »
    This post from this thread is where I got my info.
    Okay, now I remember that discussion. Did Eric Smith ever comment on why the C code was so much slower?

  • Dave HeinDave Hein Posts: 6,347
    I suspect the issue with the C calling overhead is due to the fact that all the registers need to be save on the stack before calling a function. And then they need to be restored after returning from the function. The Spin VM does everything on the stack, so there is no extra overhead of calling methods except for the stack frame that is created.

    However, I seem to recall that the fibo program runs significantly faster in LMM C than it does in Spin. Maybe CMM C is slower than Spin. It should be pretty easy to verify.
  • DavidZemonDavidZemon Posts: 2,973
    Electrodude wrote: »
    DavidZemon wrote: »
    And spin has less overhead for calling methods, so tight loops that invoke a function are much slower in C or C++.

    Really? Why? I thought Spin function calls were expensive compared to PASM ones! Does the CMM kernel not have bytecodes (or whatever) for calls and returns or something? If not, why doesn't someone fix that?

    GCC pushes local variables to the stack before invoking a function and then, upon returning, pops them back off the stack. As I understand it, Spin doesn't. So if you have to call a function a lot and in different places (if you only call it one place, GCC will inline it for you), then it starts to slow down compared with Spin.
    David Betz wrote: »
    DavidZemon wrote: »
    This post from this thread is where I got my info.
    Okay, now I remember that discussion. Did Eric Smith ever comment on why the C code was so much slower?

    Not in that thread. I haven't seem him comment on the TFT code anywhere else either.
  • Dave HeinDave Hein Posts: 6,347
    I ran the fibo program under LMM, CMM and Spin with the following results for fibo(26): 
    LMM  0.93 seconds
CMM  4.8  seconds
Spin 10   seconds
    So it seems like LMM C is 10 times faster than Spin, and CMM C is twice as fast. Pretty much all the fibo program does is recursive function calls. Here are the Spin and C fibo functions: 
    pub fibo (n)
    if (n < 2)
        return (n)
    else
        return fibo(n - 1) + fibo(n - 2)

    unsigned int fibo (unsigned int n)
{
    if (n < 2)
        return (n);
    else
        return fibo(n - 1) + fibo(n - 2);
}
  • DavidZemonDavidZemon Posts: 2,973
    Cool! Can you provide binary sizes for each of this as well?
  • Dave HeinDave Hein Posts: 6,347
    The binary sizes are: 
    LMM  24,432
CMM  13,636
Spin    892
    The C versions use the full printf from the C library. The Spin version just uses FullDuplexSerial. The code size is the biggest issue with using C on the P1. We have to jump through hoops to get a reasonably complex C file to fit in P1's 32K RAM. Writing C code for the P2 is going to be much easier since it will have 512K of RAM. We'll be able to generate code sizes of 64K or even 128K and still have a lot of room left over for data.
  • gis667en11gis667en11 Posts: 73
    I just started on the prop about three weeks ago. This has been my experience:

    C: Can't comment, didn't try it.

    Spin: It's so much like C. It has iterative loops, it has if than and while loops. As a guy pretty experienced in c it took like two weeks and one of two projects to be preeetty comfortable with Spin. It's really not that different. I don't see what the big whoop I'd about Spin vs C. Just learn Spin, really.

    PASM: It's the only way to run a program FROM a Cog. It's significantly, absurdly faster than any other option. High speed communication? Shift in/ out, bit banging high speed signals, PASM is the only option. Honestly, as a guy that started ASM with PIC assembly in Atrium and was really confused by it, PASM has been a pleasure. The functions are powerful, foreseeable, and many mimic Spin functions.

    Forth and Tachyon: It's the general consensus that Forths are king in productivity. But, they have the steepest learning curve. The language format is cryptic and backward. And it ends up being ALMOST as fast as PASM. Which really you're going to need to learn to master any forth.
  • DavidZemonDavidZemon Posts: 2,973
    Ah, that's not a fair comparison then if you're using printf in C and FDS in Spin :)
    #include <fdserial.h>

int _cfg_rxpin    = -1;
int _cfg_txpin    = -1;
int _cfg_baudrate = -1;

void main () {
  fdserial *serial = fdserial_open(_cfg_rxpin, _cfg_txpin, 0, _cfg_baudrate);
  dprinti(serial, "Hello, world! %i\n", 5);
}

    This template should compile in SimpleIDE and help to even out the playing field.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-01-06 02:22
    I remember the time we were doing these benchmarks and I did some using the iterative Fibonacci algorithm and even the slow one came in at 88us for fibo(26), but ten times faster if I used a little trick. The code size for the routine itself was 10 bytes and I just ran it now and it took 81.8us on a standard unexpanded 80MHz Prop which also happens to be running the FAT32 filesystem and network servers.
    fibo(26) =  81.800us result =121393 ok

    MODULES LOADED:                                                                 
5ED6: LIFE.fth            Conway's Game of Life for the Propeller  V1.1 150604. 
51BD: EASYNET.fth         WIZNET NETWORK SERVERS 150101.0800                    
4896: W5200.fth           WIZNET W5200 driver 140928.0000                       
                                                                                
37DB: EASYFILE.fth        FAT32 Virtual Memory Access File System Layer V1.1 15 
31A4: SDCARD.fth          SD CARD Toolkit - 141209.0000                         
2E94: CE1372.fth          CE1372 WIDGET HARDWARE DEFINITIONS 140918.2200        
1A46: EXTEND.fth          Primary extensions to TACHYON kernel - 150527-0000    
45AA: EEWORDS.fth         TACHYON DICTIONARY WORDS in EEPROM 150323.1400
  • DavidZemonDavidZemon Posts: 2,973
    Wow... 892 bytes and that includes FDS????
  • Dave HeinDave Hein Posts: 6,347
    edited 2016-01-06 02:44
    Peter, we know there is a quicker way to compute the Fibonacci series, but the point of the fibo exercise is to test out recursive calling and not just to see how fast one can implement a loop. I doubt that Tachyon performed all 392,835 recursive calls to calculate fibo(26), unless you found some way to add two numbers and return the value in 0.2 nano-seconds on the P1. :) I believe your implementation just implements it using loops.
  • potatoheadpotatohead Posts: 10,261
    :) it was made for P1 and in tandem with PASM.

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-01-06 02:58
    Dave Hein wrote: »
    Peter, we know there is a quicker way to compute the Fibonacci series, but the point of the fibo exercise is to test out recursive calling and not just to see how fast one can implement a loop. I doubt that Tachyon performed all 392,835 recursive calls to calculate fibo(26), unless you found some way to add two numbers and return the value in 0.2 nano-seconds on the P1. :) I believe your implementation just implements it using loops.

    I mentioned it was the iterative version but is the fibonacci algorithm chosen for benchmarking speed of processing or simply recursion? Are we *that* interested in recursion? How fast does C run the iterative benchmark etc?

    BTW, I'm not trying to ruffle anyone's feathers but it seems artificial limits are being placed on performance because C is being used and as acknowledged it's not a good fit for the Propeller. No use talking about how good P2 will be as many other chips will be a better fit for C as well.

  • potatoheadpotatohead Posts: 10,261
    edited 2016-01-06 03:03
    Well maybe... C, with some nice COG code is going to do well. Plenty of people would enjoy the higher level, or general logic ease and performance.

    It's a lot more roomy, and I see P1 as just a bit tiny for it to all work, unless things get packed in real tight. PASM, Tachyon and SPIN all do that.

    But, given just a little more room to work, a lot of this should balance out, particularly if a tight runtime set is developed for C.
  • DavidZemonDavidZemon Posts: 2,973
    The benchmark is simply to type two similar snippets of code and see how the compilers and interpreters differ. If the code written by the user isn't similar, then it's not a fair benchmark. This is why the binary sizes given above can't be compared - they might produce the same output, but they're using VERY different code.
    Peter Jakacki wrote: »
    C is being used and as acknowledged it's not a good fit for the Propeller

    I think there's a big difference between "not a good fit" and "not the best fit for every application."
  • potatoheadpotatohead Posts: 10,261
    Well, the question is what does a C program look like when it compiles to a comperable output?

  • gis667en11gis667en11 Posts: 73
    More like, for what applications is C the best fit for?
  • Dave HeinDave Hein Posts: 6,347
    I brought up the fibo example because we were discussing calling overhead. The recursive part is somewhat irrelevant. I was mostly interested in comparing the calling overhead of C versus Spin. Yes I know the P2 is not relevant to this conversation, but I've been playing around with C on the P2 and it soooo nice not having to worry about memory constraints.
  • DavidZemonDavidZemon Posts: 2,973
    gis667en11 wrote: »
    More like, for what applications is C the best fit for?

    First, let's all accept that "best" is an opinion.

    Here's a few easy ones:

    1) Education. Parallax believe that C is a better fit for their educational customers.

    2) A developer who knows how to fully utilize the power available in today's IDEs (and therefore uses PropWare :) )

    3) Any application where significant parts of the source code are readily available in C/C++ and easily adaptable for the Propeller (think: Arduino libraries)

    4) Applications where cogs are the limiting factor. PropGCC's inline-assembler allows a better compromise of performance and code legibility when you have to run in a single cog
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2016-01-06 04:25
    DavidZemon wrote:
    1) Education. Parallax believe that C is a better fit for their educational customers.
    I'm not sure that's entirely true. I think the real situation is that Parallax's educational customers believe that C is a better fit, and Parallax provides C to accommodate that belief and the demand that accompanies it. I've taught both C and Spin for the Prop in the classroom. Spin has provided by far the more productive learning experience for my students. It's meant more work for me, though, since I can't take advantage of Parallax's Learn curriculum.

    -Phil
  • cybersackcybersack Posts: 10
    edited 2016-01-06 07:02
    DavidZemon wrote: »
    You're gonna love PropWare
    PropWare sounds like a library I would be very comfortable with since I tend to think in Types (Data and Function) and generally appreciate being able to compile them with a discrete API.

    But, the reason I am here is to try and build some hardware to do some things in the real world with the Parallax, and so I have the obvious thought that the manufacturer's Spin/C is a more natural approach ?

    I am guessing that PropWare, in addition to encapsulating meaningful APIs, also takes care to the data I/O (i.e. aggregating the data and function features for a component), and also persistence across power on/off ?
    Does it do that ?

    David, I have 4 further questions:
    [1] Can I easily mix and match C/Spin/PropWare ?
    I ask this because I may develop a module in one language and then, learning a more facile approach, swap to another language.
    Does PropWare support C/Spin, and can C/Spin understand a PropWare library interface ?

    [2] Does the PropWare library give me the API to
    * perform AWG and push said (sine or compound) signal to an output pin (waveform generation in the 1 Hz -> 2 KHz range
    * perform Singnal Analysis and subsequent Spectrum Analysis ?
    such items would allow me to get past writing primitives-based code, and those classes tend to have specific APIs

    [3] Does PropWare give me some advantage with programming peripherals ?

    [4] Do I need to care about interrupts at all with PropWare (of course, I definitely do not want to go there)

    Thanks to all of you guys with loads of experience and have made the time to share your opinions and thoughts.
Sign In or Register to comment.