Shop OBEX P1 Docs P2 Docs Learn Events
Mixing memory models CMM, LMM and possibly cog? — Parallax Forums

Mixing memory models CMM, LMM and possibly cog?

pmrobertpmrobert Posts: 673
edited 2014-08-11 23:34 in Propeller 1
My application has one large supervisory loop running in the startup cog that is not as time sensitive as other cogs and runs properly and acceptably in CMM mode. I have other tasks in other cogs that require at least LMM speed. They also run properly in CMM mode but at an unacceptably degraded speed. Is it possible to mix these two models with the added caveat that it would be very nice if fcache would still be available for the LMM cogs? Is it possible to mix LMM, CMM and cog models? The time sensitive/intensive tasks run well when in fcache but are small enough to fit in cog mode. I suspect it's a matter of providing proper compilation and linking commands.

-Mike

Comments

  • jazzedjazzed Posts: 11,803
    edited 2014-08-07 12:58
    Hi,

    If your functions are small enough, they can run entirely at fcache speed regardless of memory model.

    For example the function below is used in the SimpleLibraries simpletext.h library. It mixes C and ASM, but your code does not need to do that.

    The __attribute_((fcache)) is a GCC thing that tags the function to run in fcache if possible. CMM fcached code is limited to 64 longs.

    __attribute__((fcache)) static void _outbyte(int bitcycles, int txmask, int value)
    {
      int j = 10;
      int waitcycles;
    
    
      waitcycles = CNT + bitcycles;
      while(j-- > 0) {
        /* C code is too big and not fast enough for all memory models.
        // waitcycles = waitcnt2(waitcycles, bitcycles); */
        __asm__ volatile("waitcnt %[_waitcycles], %[_bitcycles]"
                         : [_waitcycles] "+r" (waitcycles)
                         : [_bitcycles] "r" (bitcycles));
    
    
        /* if (value & 1) OUTA |= txmask else OUTA &= ~txmask; value = value >> 1; */
        __asm__ volatile("shr %[_value],#1 wc \n\t"
                         "muxc outa, %[_mask]"
                         : [_value] "+r" (value)
                         : [_mask] "r" (txmask));
      }
    }
    
  • pmrobertpmrobert Posts: 673
    edited 2014-08-07 13:01
    Thanks, Steve. I have a function that is much too large to fit into fcache, works very nicely under LMM but is too slow under CMM. I should have been clearer on this - my apologies. Does anyone have any insight on this issue?

    -Mike
  • David BetzDavid Betz Posts: 14,516
    edited 2014-08-07 14:07
    pmrobert wrote: »
    My application has one large supervisory loop running in the startup cog that is not as time sensitive as other cogs and runs properly and acceptably in CMM mode. I have other tasks in other cogs that require at least LMM speed. They also run properly in CMM mode but at an unacceptably degraded speed. Is it possible to mix these two models with the added caveat that it would be very nice if fcache would still be available for the LMM cogs? Is it possible to mix LMM, CMM and cog models? The time sensitive/intensive tasks run well when in fcache but are small enough to fit in cog mode. I suspect it's a matter of providing proper compilation and linking commands.

    -Mike
    Unfortunately, it isn't possible to directly use multiple memory models in the same program. A program is linked with a particular version of the C runtime library that is compiled for that memory model. If you wanted to use more than one memory model in a single program you'd have to have copies of each function compiled with each memory model. You can, however, compile small programs using the COG memory model and link them with your LMM or CMM program to be launched in other COGs. You can find an example of this in the PropGCC repository under demos/toggle/cog_c_toggle.
  • pmrobertpmrobert Posts: 673
    edited 2014-08-07 14:58
    David, thank you, it's appreciated. I was on the edge of using a dual Prop solution and now that's where I'm headed. One for high speed, high resolution functions and the other for CMM lower speed human interface stuff. It's all good!

    -Mike
  • abecedarianabecedarian Posts: 312
    edited 2014-08-07 20:56
    pmrobert wrote: »
    David, thank you, it's appreciated. I was on the edge of using a dual Prop solution and now that's where I'm headed. One for high speed, high resolution functions and the other for CMM lower speed human interface stuff. It's all good!

    -Mike

    It all makes more sense now. But I'm still confused.
  • SRLMSRLM Posts: 5,045
    edited 2014-08-08 06:13
    It all makes more sense now. But I'm still confused.

    What you confused about?
  • abecedarianabecedarian Posts: 312
    edited 2014-08-11 13:51
    SRLM wrote: »
    What you confused about?
    pmrobert floated an email to me about using two prop's on the EFI thing I've been planning with him. I wasn't sure of the intention of it at the time but now it makes a little more sense- but it's still a bit over my head.
  • pmrobertpmrobert Posts: 673
    edited 2014-08-11 16:13
    Apologies! We are running out of cogs and memory if we wish to implement all the things we discussed. An additional Prop would add a total of 6 cogs, etc., to the available resources. One cog per chip would be needed to facilitate interchip comms. I'll shoot you some email after I get back home tomorrow. I'm currently in a 3rd floor condo across the street from NAS Key West (Boca Chica) watching F18s take off, land and maneuver about 300 feet overhead so a bit preoccupied right now.... :-)
  • abecedarianabecedarian Posts: 312
    edited 2014-08-11 23:34
    I hope you have a plan, 'cause I know next to nothing, and even less about interfacing two Prop's together, much less synchronizing said Props, signals and such.
    So, my already precarious position causing second-guessing and commitment issues is about to grow exponentially. :D
Sign In or Register to comment.