Shop OBEX P1 Docs P2 Docs Learn Events
Any documentation on Propeller LMM ? — Parallax Forums

Any documentation on Propeller LMM ?

BeanBean Posts: 8,129
edited 2009-03-21 14:57 in Propeller 1
I've been away from the propeller for awhile, but I seen various topics about code that uses a "Large Memory Model". I'm interested in writing some code that uses LMM.

Is there any good documentation on how it works ?

Thanks, Bean.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...

·

Comments

  • Mike HuseltonMike Huselton Posts: 746
    edited 2009-03-19 01:59
    Bean,

    These are the Wiki summaries:

    propeller.wikispaces.com/Large+Memory+Model
    propeller.wikispaces.com/LMM+Phil+Pilgrim+(PhiPi)
    propeller.wikispaces.com/LMM+Pacito
    propeller.wikispaces.com/LMM+AiChip+Industries

    Are these adequate?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    JMH

    Post Edited (James Michael Huselton) : 3/19/2009 2:23:08 AM GMT
  • Bill HenningBill Henning Posts: 6,445
    edited 2009-03-19 03:38
    Hi Bean,

    Unfortunately right after I came up with LMM I got too busy; however my schedule is much better now, so I've resumed spending a lot of hours on the Propeller and LMM.

    If you follow the original thread, there is some documentation there, and I am writing "proper" docs; they will be needed for my LMM macro assembler. Status of macro assembler: all op codes assemble properly, and have been verified, I just need to finish fixing up forward references and finish implementing macro's. I expect an "alpha" version roughly at the end of this month.
    Bean (Hitt Consulting) said...
    I've been away from the propeller for awhile, but I seen various topics about code that uses a "Large Memory Model". I'm interested in writing some code that uses LMM.


    Is there any good documentation on how it works ?



    Thanks, Bean.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.mikronauts.com - a new blog about microcontrollers
  • BeanBean Posts: 8,129
    edited 2009-03-19 10:48
    Bill,
    Thanks. That is great news. I can't wait. I'll just muddle through with what is on the threads for now.

    Bean.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    There is a fine line between arrogance and confidence. Make sure you don't cross it...

    ·
  • heaterheater Posts: 3,370
    edited 2009-03-19 11:09
    You could download the trial ImageCraft C compiler for the Propeller and check out it's LMM kernel and how it generates it's LMM code.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • hippyhippy Posts: 1,981
    edited 2009-03-19 17:49
    All credit goes to Bill for his innovation and realisability of LMM on the Prop which inspired a number of us to go in that direction, and I'm sure we are all glad we did.

    It's a very simple but extremely powerful concept / tool which busts open many of the perceived restrictions of a 496 instruction Cog with only a reasonable reduction in processing power. I'd say it's one of the key technologies one needs to know to push the Prop to the boundaries. It crops up in a few places but I don't see much mainstream take-up or a growing LMM evangelism choir - ImageCraft perhaps being the notable user of the technique.

    There's no real definitive use of LMM so it's quite flexible and can be used / twisted in a number of ways. It's an advantage but also a disadvantage, because it's hard to define beyond the basic concepts, after that it's go-your-own-way. I believe that its uptake has been held back by not having the tools or a standard reference design so Bill's return to the scene and renewed interest is very welcome.

    If ( hint, hint ) Chip does add enhancements to the Prop II which makes running 16-bit LMM thumb-style PASM fast and easy, that will IMO create a zinger of a microcontroller. PASM overheads of multiple bit-field extractions and shiftings is currently a big overhead which stands in the way of that being high-speed.
  • Bill HenningBill Henning Posts: 6,445
    edited 2009-03-19 18:34
    Thanks Hippy!

    I am currently working on a "definitive" LMM kernel, detailed documentation, and a proper LMM macro assembler so that LMM can really take off.

    Chip has already said he will be adding an auto-increment RDLONG/WRLONG to PropII, which along with the REP instruction will allow 8 cycle execution of all but hub instructions in a modified LMM on PropII (and if he implements the double or quad long reads, even lower cycle counts are possible) - so that means LMM will run at 20Mips (same as current pasm) on Prop2! The other additions of Prop2 will also allow me to create far better FCACHE and relatives. I'm working on other related goodies that I am not ready to announce yet - I've been bitten too many times with coming up with something neat only to have to shelve it due to consulting gigs so I won't announce early any more.
    hippy said...
    All credit goes to Bill for his innovation and realisability of LMM on the Prop which inspired a number of us to go in that direction, and I'm sure we are all glad we did.

    It's a very simple but extremely powerful concept / tool which busts open many of the perceived restrictions of a 496 instruction Cog with only a reasonable reduction in processing power. I'd say it's one of the key technologies one needs to know to push the Prop to the boundaries. It crops up in a few places but I don't see much mainstream take-up or a growing LMM evangelism choir - ImageCraft perhaps being the notable user of the technique.

    There's no real definitive use of LMM so it's quite flexible and can be used / twisted in a number of ways. It's an advantage but also a disadvantage, because it's hard to define beyond the basic concepts, after that it's go-your-own-way. I believe that its uptake has been held back by not having the tools or a standard reference design so Bill's return to the scene and renewed interest is very welcome.

    If ( hint, hint ) Chip does add enhancements to the Prop II which makes running 16-bit LMM thumb-style PASM fast and easy, that will IMO create a zinger of a microcontroller. PASM overheads of multiple bit-field extractions and shiftings is currently a big overhead which stands in the way of that being high-speed.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.mikronauts.com - a new blog about microcontrollers
  • ImageCraftImageCraft Posts: 348
    edited 2009-03-19 19:06
    Search for "Propeller C" in the imagecraft blog: http://imagecraft.wordpress.com, someone commented that it's the most concise explanation of LMM they have read...

    // richard
  • jazzedjazzed Posts: 11,803
    edited 2009-03-19 19:54
    Richard,·you have·a nice explanation of the basic idea and a neat reference to Bill's initial observation. Unfortunately, I could not find anything there on the usage of the "primitives" defined in kernel.s. I know most of them, but nothing beats a clear enumerated reference for all to quickly understand (except possibly getting our latest project fully working [noparse];)[/noparse]. The ICCPROP community would benefit greatly from a good ICC specific LMM reference with usage examples.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    --Steve


    Propalyzer: Propeller PC Logic Analyzer
    http://forums.parallax.com/showthread.php?p=788230
  • JetfireJetfire Posts: 34
    edited 2009-03-19 19:57
    I think this is the link: Parallax Propeller and the Propeller C Compiler

    I recently started looking at making a converter so that it is easy to build LMM code. One thing I noticed right away is that self modifying code or using the movi, movs, and movd become very difficult to use with the hub. Using a style based on hippy's LMM you are practically switching from von Neumann to Harvard architecture. A mov of a variable in cog ram is basically the same, but in PASM you could mov in a whole new instruction. With the code in the hub, some commands require jumping out the LMM load-increment-execute to run more complex commands involving a jump out, then hub addresses; you can't really modify a command. So is self modification out entirely or what is available?

    Post Edited (Jetfire) : 3/19/2009 8:02:34 PM GMT
  • Bill HenningBill Henning Posts: 6,445
    edited 2009-03-19 20:05
    Self modifying code is available in FCACHE'd blocks [noparse]:)[/noparse] generally my intention was to use hub based code to "glue" togeather FCACHE'd blocks of looping code, thus approaching the speed of raw pasm very closely.
    Jetfire said...
    I think this is the link: Parallax Propeller and the Propeller C Compiler

    I recently started looking at making a converter so that it is easy to build LMM code. One thing I noticed right away is that self modifying code or using the movi, movs, and movd become very difficult to use with the hub. Using a style based on hippy's LMM you are practically switching from von Neumann to Harvard architecture. A mov of a variable in cog ram is basically the same, but in PASM you could mov in a whole new instruction. With the code in the hub, some commands require jumping out the LMM load-increment-execute to run more complex commands involving a jump out, then hub addresses; you can't really modify a command. So is self modification out entirely or what is available?
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.mikronauts.com - a new blog about microcontrollers
  • Timothy D. SwieterTimothy D. Swieter Posts: 1,613
    edited 2009-03-19 23:05
    Bill -

    On the recent webinar with Chip, there was mention of being able to read four longs at a time out of HUB RAM. We can confirm this when the videos are posted. Overall it makes it very exciting for LMM constructions and execution.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Timothy D. Swieter, E.I.
    www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
    www.tdswieter.com
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-03-20 02:25
    I did 2 things that may help. Both are in the prop tools thread pointed to in my signature.

    1. Fast overlay loader (for executing code within the cog). Heater is using this in his ZiCog.
    2. Zero footprint Spin & Pasm debugger - uses an LMM style debugger located in shaddow ram $1F0-$1F3. It takes into account the self-modifying jmp/call/jmpret/ret instructions.

    The problems with LMM I see are the self-modifying instructions and jmp/jmpret/call/ret instruction.

    I have acknowledgements in the code to those who helped paved the way, Hippy in particular.

    Currently I have heaters z80 code (the actual z80 cpm code, not prop pasm) running from external SRAM on my TriBladeProp design. BUT, this takes almost ALL I/O pins, and is limited to only 1 cog at a time, so a locking mechanism is required for multiple cog access. This SRAM is only byte wide access only.

    By the time we get PropII, 256KB of hub memory is not going to be enough for what some of us are doing, but we will have more I/O pins to attach SRAM.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
    · Single Board Computer·using the TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators (Micros eg Altair, and Terminals eg VT100) - index
    · Search the Propeller forums (via Google)

    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • ImageCraftImageCraft Posts: 348
    edited 2009-03-20 19:54
    jazzed said...
    Richard, you have a nice explanation of the basic idea and a neat reference to Bill's initial observation. Unfortunately, I could not find anything there on the usage of the "primitives" defined in kernel.s. I know most of them, but nothing beats a clear enumerated reference for all to quickly understand (except possibly getting our latest project fully working [noparse];)[/noparse]. The ICCPROP community would benefit greatly from a good ICC specific LMM reference with usage examples.

    The reason I haven't done it is because I wasn't sure the LMM routines will not be changing. Now that we are almost a year since release, I guess it should be pretty solid. I will add it to the list of things to do...
  • ImageCraftImageCraft Posts: 348
    edited 2009-03-20 20:01
    BTW, a number of the forumers are working on XMM-Propeller boards. My intention is to make Propeller C generic enough so that it can work on different memory expansion schemes without too many changes to the compiler, but just to the XMM aware kernel. With 512K to a few megabytes to play with, this really would open up the possibility of porting large programs to the Propeller based design. The runtime perofrmance would not be pretty but hey we did so much with a 7.18 MHz 68K on the Amiga smile.gif

    I should be getting a prototype XMM board in a few days and hopefully I can report something soon.
  • Mike HuseltonMike Huselton Posts: 746
    edited 2009-03-21 03:27
    Imagecraft,

    My feeling of developers' guilt over Imagecraft has been brought to a broil recently.
    As a pro, I feel a need to give back to the Parallax and Imagecraft arenas that have given me so much.

    If you can reveal the vendor of the XMM eapansion, can you do so?
    Just a link, any link. I want to replicate the direction of your thinking.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    JMH
  • AleAle Posts: 2,363
    edited 2009-03-21 10:19
    I'm sure a custom kernel can be ported to use Cluso's boards, but as Richard (imageCraft) said they want to make it general enough. Cluso's board supports some 2 to 4 MB if you get the right SRAMs.
  • kwinnkwinn Posts: 8,697
    edited 2009-03-21 14:57
    My apologies for somewhat hijacking this thread, but after reading it to this point I have to point out that having the 64 I/O prop would be a great boost to this effort. Even better would be having 3 or 4 registers that could be pre/post auto incremented added with the extra I/O pins. Changing the core instructions or design of the prop would not even be necessary.
Sign In or Register to comment.