Shop OBEX P1 Docs P2 Docs Learn Events
Mixed memory models? — Parallax Forums

Mixed memory models?

Erik FriesenErik Friesen Posts: 1,071
edited 2012-08-13 10:38 in Propeller 1
Perhaps this is obvious, I haven't dug real deep. I haven't followed the C thing very close, but I was poking around and took a look at the propgcc site, and saw the three memory models listed. I think the possibility of cog + lmm would be quite handy. Inter cog communication could be interesting I suppose, but should work, especially with structs now available.

Perhaps something like, #pragma config COGMODEL, or #define COGMODEL ??? or LMMMODEL??

Comments

  • jazzedjazzed Posts: 11,803
    edited 2012-08-12 19:53
    Erik Friesen wrote: »
    Perhaps this is obvious, I haven't dug real deep. I haven't followed the C thing very close, but I was poking around and took a look at the propgcc site, and saw the three memory models listed. I think the possibility of cog + lmm would be quite handy. Inter cog communication could be interesting I suppose, but should work, especially with structs now available.

    Perhaps something like, #pragma config COGMODEL, or #define COGMODEL ??? or LMMMODEL??

    Hi Erik.

    Builtin defines for propeller-gcc and memory models are.

    __propeller__
    __PROPELLER__
    __PROPELLER_XMM__
    __PROPELLER_XMMC__
    __PROPELLER_LMM__
    __PROPELLER_COG__
    __PROPELLER_64BIT_DOUBLES__
    __PROPELLER_32BIT_DOUBLES__

    These macros are defined depending on the flags passed to propeller-gcc.

    __PROPELLER_XMM__ is a mode where code and global data normally live in external memory.
    __PROPELLER_XMMC__ is a mode where code normally lives in external memory and all data lives in HUB.

    The macros HUBTEXT and HUBDATA can force any code or data to live in HUB memory.

    This info is also provided here (now) https://sites.google.com/site/propellergcc/supplements/propgcc-compiler
  • Erik FriesenErik Friesen Posts: 1,071
    edited 2012-08-13 01:02
    So can those be defined per *.c ?
  • ersmithersmith Posts: 6,054
    edited 2012-08-13 06:01
    I think there's a miscommunication here. The __PROPELLER_LMM__ and similar defines are constant defines that are set based on what's given on the command line. So they are defined per .c file, and cannot be redefined.

    Erik, if you want to mix LMM and COG code you generally have to put them in separate C files and compile them with different options (-mlmm for the LMM files and -mcog for the COG files). I'm not sure that SimpleIDE supports this yet, although perhaps it does.
  • Erik FriesenErik Friesen Posts: 1,071
    edited 2012-08-13 06:34
    So it seems theoretically possible, anyway.
  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2012-08-13 09:13
    ersmith wrote: »
    Erik, if you want to mix LMM and COG code you generally have to put them in separate C files and compile them with different options (-mlmm for the LMM files and -mcog for the COG files). I'm not sure that SimpleIDE supports this yet, although perhaps it does.

    SimpleIDE supports this, fortunately. This is probably a very common setup for Propeller projects, after all. Just put the COG c code in modules with names that end in .cogc (instead of .c). The .cogc modules are compiled with -mcog (COG memory model) regardless of the memory model in the project settings. All other modules are compiled in the project's memory model. One of the Toggle sample projects demonstrates how this works.

    I'm not sure if there's a way to compile a COG module in C++ (name it .cogcpp perhaps?) but I would recommend against that anyway because C++ has the potential of adding a lot of overhead.

    ===Jac
  • photomankcphotomankc Posts: 943
    edited 2012-08-13 09:58
    jac_goudsmit wrote: »

    I'm not sure if there's a way to compile a COG module in C++ (name it .cogcpp perhaps?) but I would recommend against that anyway because C++ has the potential of adding a lot of overhead.

    Don't think it would make much sense to anyway given the very restrictive environment of the COG. Can't imagine what you can use C++ to do in there given the tiny amount of resources and restrictions on stack and calling functions.
  • Erik FriesenErik Friesen Posts: 1,071
    edited 2012-08-13 10:30
    Yeah, I'd like to see how they manage the hello world with printf in a cog. One thing that isn't clear to me, is where printf is initialized. Some of the include files aren't anywhere to be found, so that doesn't make things clear. An MplabX style navigate would be really nice, although that type of thing I am sure is a lot of work.

    I know a lot of folks like spin and prop asm, but after learning c, I find it rather liberating. It is so much easier to use bitfields, as a small example. Spin is a good springboard to learn c, I think.

    I am pleased to see that the IDE is QT based.
  • David BetzDavid Betz Posts: 14,516
    edited 2012-08-13 10:38
    Erik Friesen wrote: »
    Yeah, I'd like to see how they manage the hello world with printf in a cog. One thing that isn't clear to me, is where printf is initialized. Some of the include files aren't anywhere to be found, so that doesn't make things clear. An MplabX style navigate would be really nice, although that type of thing I am sure is a lot of work.

    I know a lot of folks like spin and prop asm, but after learning c, I find it rather liberating. It is so much easier to use bitfields, as a small example. Spin is a good springboard to learn c, I think.

    I am pleased to see that the IDE is QT based.
    For some reason I don't understand, the header files are all in /opt/parallax/propeller-elf/include rather than in /opt/parallax/include. Under Windows this would be C:\propgcc\propeller-elf\include I think.
Sign In or Register to comment.