Shop OBEX P1 Docs P2 Docs Learn Events
What are the limits of in COG with C or BASIC? — Parallax Forums

What are the limits of in COG with C or BASIC?

davidsaundersdavidsaunders Posts: 1,559
edited 2015-04-16 05:50 in Propeller 1
Ok I did not get as far on the spin as I hoped today, though:


I am looking at C as a possible. What are the limits in using GCC for code that is in cog only? That is other than the obvious size limit.

Is there a simpler C compiler for the Propeller, a integer C with no libs, that only compiles COG code??

I am asking as it seems that everyone wants C, and I would like to see my 3D printer design and firmware at least get half a chance.

I have thought about using PropBASIC as an alternative. Though I do not know the limits of PropBASIC either. I have been looking at the manual, though it seems incomplete, and does not give a good indication of the relation of BASIC statements to PASM code.

Are there any other BASIC Compilers for the Propeller that do as well as PropBASIC or better than PropBASIC, at producing COG code?

Though I do not know where to share it other than here. I got kicked off of the 3D printing forum today for talking about programming, and the limits of G-Code. It seems that they are a bit up about such things (they seem to prefer the commercial stuff over DIY, and do every thing they can to suppress DIY). They did not even tell me that they were going to do so, my username and password just became invalid.
«13

Comments

  • David BetzDavid Betz Posts: 14,516
    edited 2015-04-08 19:23
    davidsaunders wrote: »
    Is there a simpler C compiler for the Propeller, a integer C with no libs, that only compiles COG code??
    If you only use integers, then only integer support will be used by the compiler. If you don't call any library functions, no library code will be included. The only exception I can think of to this is the printf and scanf functions that support reading and writing floating point numbers even if you don't use floating point in your program. First, we have integer-only versions of those functions. Second, you are unlikely to be able to use any version of those functions in COG mode code since they won't fit in the 2k of memory that is available to code and data in COG mode.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-08 19:30
    David Betz wrote: »
    If you only use integers, then only integer support will be used by the compiler. If you don't call any library functions, no library code will be included. The only exception I can think of to this is the printf and scanf functions that support reading and writing floating point numbers even if you don't use floating point in your program. First, we have integer-only versions of those functions. Second, you are unlikely to be able to use any version of those functions in COG mode code since they won't fit in the 2k of memory that is available to code and data in COG mode.
    Any C compiler will use only integer instructions if you use only integer types, that is a given.

    I asked about a simple compiler that ONLY SUPPORTS Integer math, and does not have any of the libraries available.

    And who uses printf() or scanf()? There are much better ways in the standard library for that (getc(), gets(), putc(), puts(), etc).
  • David BetzDavid Betz Posts: 14,516
    edited 2015-04-08 19:31
    davidsaunders wrote: »
    Any C compiler will use only integer instructions if you use only integer types, that is a given.

    I asked about a simple compiler that ONLY SUPPORTS Integer math, and does not have any of the libraries available.

    And who uses printf() or scanf()? There are much better ways in the standard library for that (getc(), gets(), putc(), puts(), etc).
    What advantage would there be in a compiler that only supports integers?
  • jmgjmg Posts: 15,173
    edited 2015-04-08 19:58
    davidsaunders wrote: »
    I asked about a simple compiler that ONLY SUPPORTS Integer math, and does not have any of the libraries available.
    As David, said that is automatic/implicit and the user can control that.
    You want compact code, use only one type.

    David was a little brief in #2, and you may have missed that PropGCC has multiple code generation choices.

    The COG mode mentioned, ,means the PropGCC creates PASM that runs native in a COG. (maybe that should be renamed PASM mode ? )

    Clearly, that is very fast but has limits on just what code it can swallow, to still fit in a COG.

    If I understand this right, you can have have 7 COGS running any 7 small/fast blocks of C COG-Mode Code, and one COG can run C in the larger CMM mode, that is slower (much slower than PASM, & slower even than Spin IIRC) , but avoids the hard ceiling of COG memory.
    That is where you code the non-time critical stuff.

    For your project, I'd suggest re-code PASM in PropGCC-COG-Mode, and maybe also some of the 'faster' Spin, and the 'slower' spin code can code in PropGCC-CMM mode, in a spare COG.
  • Dave HeinDave Hein Posts: 6,347
    edited 2015-04-08 20:06
    davidsaunders wrote: »
    Any C compiler will use only integer instructions if you use only integer types, that is a given.

    I asked about a simple compiler that ONLY SUPPORTS Integer math, and does not have any of the libraries available.

    And who uses printf() or scanf()? There are much better ways in the standard library for that (getc(), gets(), putc(), puts(), etc).
    A C program will only link in the library functions that you use. So if you don't use any library functions, none will be linked in. I don't think the COG memory model supports many library function anyhow.
  • jmgjmg Posts: 15,173
    edited 2015-04-08 20:14
    Dave Hein wrote: »
    I don't think the COG memory model supports many library function anyhow.

    Is there a simple table the OP can use, of lib functions and their sizes in COG mode and CMM mode ?
    eg 16 x 16, 16 / 16, and maybe 32 divmod 16
    & in CMM for float Mul and Div and int<->Float conversions ?
  • DavidZemonDavidZemon Posts: 2,973
    edited 2015-04-08 20:55
    I'd start by leaving your driver cogs in assembly, as they currently are. Convert your Spin code to C++ running in CMM (speed & size roughly equivalent to Spin) or LMM mode (twice size & speed of CMM) which would then invoke your driver cogs - exactly the same way that it's done in Spin. The only difference is that each cog's assembly code goes into its own *.S file instead of at sitting at the bottom of a *.spin file.

    Then, later, if you choose to convert the assembly to C/C++ as cogc/cogcpp, you can do so.
  • Heater.Heater. Posts: 21,230
    edited 2015-04-08 21:07
    davidsaunders,
    I asked about a simple compiler that ONLY SUPPORTS Integer math, and does not have any of the libraries available.
    What would be the point in that?

    Just use GCC to compile code to COG native. Don't use any types in that code except int. Don't call any library functions.

    But if you have working PASM drivers just leave them as PASM.
  • jmgjmg Posts: 15,173
    edited 2015-04-08 22:09
    davidsaunders wrote: »
    I have thought about using PropBASIC as an alternative. Though I do not know the limits of PropBASIC either. I have been looking at the manual, though it seems incomplete, and does not give a good indication of the relation of BASIC statements to PASM code.

    There is a good example of PropBASIC here
    http://forums.parallax.com/showthread.php/123170

    and the PASM PropBASIC creates can go into any COG, and does not care if other COGs are running Spin. PropGCC-COG-Mode or Prop-GCC-CMM, or PASM.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-09 04:28
    Ok I guess the answer to my C question is no. There are a number of integer only C compilers for other platforms, and it would mean that the code can be compiled in less time (usualy), even with optimizations.

    Thank you for the link to PropBASIC examples. I also ask are there any other BASIC Compilers for the Propeller I should look at?
  • David BetzDavid Betz Posts: 14,516
    edited 2015-04-09 04:41
    davidsaunders wrote: »
    Ok I guess the answer to my C question is no. There are a number of integer only C compilers for other platforms, and it would mean that the code can be compiled in less time (usualy), even with optimizations.

    Thank you for the link to PropBASIC examples. I also ask are there any other BASIC Compilers for the Propeller I should look at?
    I doubt the compile time would be much less with an integer-only compiler unless it also did less optimization. I don't think supporting float data types increases the compile time and it certainly doesn't if you don't use them. I think your faster integer-only compilers on other platforms are probably non-optimizing compilers. In any case, PropGCC and Catalina are very fast for the size programs that will fit in the Propeller memory.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-09 06:17
    Thank you all.

    I just spent a little time looking at some of the PropGCC examples, and I think I will stick with PASM and SPIN. I was hoping there was a more straight forward C compiler for the Prop though I guess that to much to ask.
  • Heater.Heater. Posts: 21,230
    edited 2015-04-09 06:22
    What is not straight forward with prop-gcc?
  • DavidZemonDavidZemon Posts: 2,973
    edited 2015-04-09 06:28
    You've certainly baffled us all with this "integer only" compiler question. You want high-efficiency compilation, sure, a simplified compiler would go faster... but this is Propeller stuff we're talking about. To give you a comparison, it takes 30 seconds (single threaded) to compile PropWare, and here's the countdown of files: libpropeller=7, PropWare=~8, simple=176. Each of those files are compiled 5 times (one for each memory model) for a grand total of 955 compilations. That's an average of almost 32 files compiled every second. And PropWare uses CMake, which takes significantly longer than Make or bare-bones command line. I can't imagine for the life of me why you're worried about compiler speed.

    A limited compiler such as what you're talking about could help you enforce some nice standards, but I think you can achieve the same thing with PropGCC or Catalina. For instance, here's a flag that tells GCC not to link with libc.

    None of us are trying to belittle your inquiry, but we're very curious as to what other features you're trying to access.
  • Dave HeinDave Hein Posts: 6,347
    edited 2015-04-09 07:06
    Here's a couple of links that provide information on COGC.

    https://code.google.com/p/propgcc/wiki/COGModeExperiences
    http://propgcc.googlecode.com/hg/doc/Library.html#RunningNative

    There are also three examples of using COGC in SimpleIDE.

    Learn/Simple Libraries/Convert/libadcACpropab
    Propeller GCC Demos/C-VGA
    Propeller GCC Demos/toggle/cog_c_toggle
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-09 07:08
    Heater. wrote: »
    What is not straight forward with prop-gcc?
    It may just be the examples that I looked at, though it appears to use some unclear macros to access the COG control registers.

    Once I get everything done in SPIN, PASM, and PropBASIC I will take more time to look at GCC. It is something I want to know, so it will be worth my time. At the moment I am more focused on finishing the first usable version for others. And making that comment are understandable to others takes 4 times as long as writing the code.
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-09 07:10
    SwimDude0614 wrote: »
    You've certainly baffled us all with this "integer only" compiler question. You want high-efficiency compilation, sure, a simplified compiler would go faster... but this is Propeller stuff we're talking about. To give you a comparison, it takes 30 seconds (single threaded) to compile PropWare, and here's the countdown of files: libpropeller=7, PropWare=~8, simple=176. Each of those files are compiled 5 times (one for each memory model) for a grand total of 955 compilations. That's an average of almost 32 files compiled every second. And PropWare uses CMake, which takes significantly longer than Make or bare-bones command line. I can't imagine for the life of me why you're worried about compiler speed.

    A limited compiler such as what you're talking about could help you enforce some nice standards, but I think you can achieve the same thing with PropGCC or Catalina. For instance, here's a flag that tells GCC not to link with libc.

    None of us are trying to belittle your inquiry, but we're very curious as to what other features you're trying to access.

    I do thank you for the input. though it takes 30 seconds on what machine?? On a 486DX 33MHz with 128MB RAM?
  • davidsaundersdavidsaunders Posts: 1,559
    edited 2015-04-09 07:11
    Dave Hein wrote: »
    Here's a couple of links that provide information on COGC.

    https://code.google.com/p/propgcc/wiki/COGModeExperiences
    http://propgcc.googlecode.com/hg/doc/Library.html#RunningNative

    There are also three examples of using COGC in SimpleIDE.

    Learn/Simple Libraries/Convert/libadcACpropab
    Propeller GCC Demos/C-VGA
    Propeller GCC Demos/toggle/cog_c_toggle
    Thank you for that. I will bookmark those links to look at in more detail as I have time. thank you very much.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2015-04-09 07:32
    davidsaunders wrote: »
    I do thank you for the input. though it takes 30 seconds on what machine?? On a 486DX 33MHz with 128MB RAM?

    On an 8051 simulating x86 running VirtualBox with Windows (Vista) :)

    It was a 2.5 GHz 8-core Intel-based Linux cloud server and 8 GB RAM. Since I ran it single threaded, I would assume similar performance on any 2.5 GHz single-core x86 Linux machine with a little bit of RAM.
  • GenetixGenetix Posts: 1,754
    edited 2015-04-09 10:32
    I think David just wants to know how to get the smallest possible Propeller C code without sacrificing performance too much.

    Does Propeller C support code that resides above 32K of an EEPROM?
    In other words, can there be code blocks in the upper area an EEPROM that can be loaded if needed?
    I would imagine this would use 1 Cog but would allow the Propeller to run a larger program, especially if a function is only used occasionally.
  • David BetzDavid Betz Posts: 14,516
    edited 2015-04-09 10:51
    Genetix wrote: »
    I think David just wants to know how to get the smallest possible Propeller C code without sacrificing performance too much.

    Does Propeller C support code that resides above 32K of an EEPROM?
    In other words, can there be code blocks in the upper area an EEPROM that can be loaded if needed?
    I would imagine this would use 1 Cog but would allow the Propeller to run a larger program, especially if a function is only used occasionally.
    You can use the EEPROM as external memory for the XMM memory model but there is no facility for swapping code from EEPROM.
  • GenetixGenetix Posts: 1,754
    edited 2015-04-09 12:35
    David Betz wrote: »
    You can use the EEPROM as external memory for the XMM memory model but there is no facility for swapping code from EEPROM.

    So code runs from EEPROM or are just variables stored there?
    Ewwwww, EEPROM is S L O W !
  • David BetzDavid Betz Posts: 14,516
    edited 2015-04-09 12:40
    Genetix wrote: »
    So code runs from EEPROM or are just variables stored there?
    Ewwwww, EEPROM is S L O W !
    Code runs through a hub cache from EEPROM.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2015-04-09 12:49
    Genetix wrote: »
    Ewwwww, EEPROM is S L O W !

    Ha! yep! But, other options, like SPI flash chips, are available if you have the hardware.
  • David BetzDavid Betz Posts: 14,516
    edited 2015-04-09 13:33
    SwimDude0614 wrote: »
    Ha! yep! But, other options, like SPI flash chips, are available if you have the hardware.
    For outer loop stuff, EEPROM isn't that bad through a cache. I built my embedded basic interpreter for XMM and ran it on a Quickstart from EEPROM and the command interpreter and compiler were fast enough. The generated code runs fast because it is byte code run by a PASM VM just like Spin.
  • jmgjmg Posts: 15,173
    edited 2015-04-09 13:51
    Dave Hein wrote: »
    Here's a couple of links that provide information on COGC.

    https://code.google.com/p/propgcc/wiki/COGModeExperiences
    http://propgcc.googlecode.com/hg/doc/Library.html#RunningNative

    Are those topics up to date ?

    Having to manually dis-asm to visually check Stack spawnings sounds a little clunky ?
    Does the -mcog not have more complete control ?

    Here is a (very) good PropBasic example
    http://forums.parallax.com/showthread.php/123170
    - a clone of that, in -mcog mode would be worth 1000 words...
  • David BetzDavid Betz Posts: 14,516
    edited 2015-04-09 14:04
    jmg wrote: »
    Are those topics up to date ?

    Having to manually dis-asm to visually check Stack spawnings sounds a little clunky ?
    Does the -mcog not have more complete control ?

    Here is a (very) good PropBasic example
    http://forums.parallax.com/showthread.php/123170
    - a clone of that, in -mcog mode would be worth 1000 words...
    If you give the COGC program a chunk of hub memory to use as a stack you don't have to worry about this. It is only necessary if you want to operate without a stack which is kind of unnatural for C anyway.
  • Dave HeinDave Hein Posts: 6,347
    edited 2015-04-09 14:05
    You can use the -S option to generate the assembly file. The nice thing about the cog mode is that you can use the stack and hub variables if you want to, just like any of the other memory models. Or if you want to avoid using the stack and hub variables you can use the _NAKED, _NATIVE and _COGMEM attributes. It is good to check the generated assembly code to ensure that the stack and hub RAM aren't being used.
  • GenetixGenetix Posts: 1,754
    edited 2015-04-09 14:26
    David Betz wrote: »
    Code runs through a hub cache from EEPROM.

    That's good to hear because the BS2 is super slow because everything is read from EEPROM.
    SwimDude0614 wrote: »
    Ha! yep! But, other options, like SPI flash chips, are available if you have the hardware.

    The Propeller Memory Card has a 128KB SPI SRAM on it - Nice! :)
  • jmgjmg Posts: 15,173
    edited 2015-04-09 14:26
    David Betz wrote: »
    For outer loop stuff, EEPROM isn't that bad through a cache. I built my embedded basic interpreter for XMM and ran it on a Quickstart from EEPROM and the command interpreter and compiler were fast enough. The generated code runs fast because it is byte code run by a PASM VM just like Spin.

    What CLK speeds does that use ?
    I see 1MHz is widespread, and 3.4MHz is mentioned on some parts (eg Cypress FM24V10) not cheap, but could test 3.4MHz code.
    1MHz parts can likely be over-clocked with tuning of pullup ressitors and code.
Sign In or Register to comment.