Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 - More Cog memory — Parallax Forums

Prop2 - More Cog memory

hippyhippy Posts: 1,981
edited 2007-08-26 05:31 in Propeller 1
Distinct from the "More Cogs versus More Memory" debate, so I thought I'd open a new debate / flame war ...

In the Propeller MkII, would it be possible to increase the size of Cog memory to 1K or 2K longs, maybe more ?

That can be done without breaking the existing scheme and Cog instruction set by loading 1K/2K longs on COGNEW (*) but only giving execution access to the first 512 Longs, $000-$1FF. The 1K/2K would be split into 256 long pages, on initial loading the first mapped to $000-$0FF, the second to $100-$1EF ( control registers still at $1Fx ). Without any further intervention, Cogs in MkII would look and behave just as they do now.

With suitable Paging Bits, the top and bottom halves of the 512 Cog memory could be dynamically mapped to any one of the 4/8 256 long pages. There are instructions which are 'meaningless' which could be subverted to provide the means to control the page bits; "SHL d,#33", unused HUBOP's etc. It would be nice to be able page both top and bottom halves, but just paging the top half would still be useful.

(*) COGNEW could still load 512 (496) longs as it does now, filling Page 0 and 1, and the Cog Programmer could be left to fill the rest. This would actually be more sensible as the additional pages may only be sparsely populated with code.

There are issues as to how to write and implement code for a Paged Cog scheme but they can be overcome. Even if the Propeller Tool did not initially support anything other than what there is now, enterprising Assembler Programmers would still be able to take advantage of a larger, paged cog memory scheme.

I think it would be useful expansion to have.

Comments

  • SkogsgurraSkogsgurra Posts: 231
    edited 2007-08-23 15:28
    I never liked bankswithing and paging. But, for the Prop, I am prepared to make an exception. I'm afraid I didn't quite follow you, but it sounds doable.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • AleAle Posts: 2,363
    edited 2007-08-23 17:12
    Hippy, the sweet spot could be around 2 K longs... that would rock. Sadly, I think Paul or Chip said that the 512 longs limit, and so the user model would not change. We should see anyways some new opcodes, besides mul, enc, ones and .. I don't remember.
  • Paul BakerPaul Baker Posts: 6,351
    edited 2007-08-23 17:24
    No the Prop2 will not have more cog memory, this has been discussed to great lengths in the original Mem vs Cogs thread.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Paul Baker
    Propeller Applications Engineer

    Parallax, Inc.
  • hippyhippy Posts: 1,981
    edited 2007-08-24 00:22
    Paul Baker (Parallax) said...
    No the Prop2 will not have more cog memory, this has been discussed to great lengths in the original Mem vs Cogs thread.
    Thanks for the definitive answer, and apologies for missing the details in that previous thread. I did see, "Chip mentioned it is possible to use a banking scheme, but it is an unappealing avenue", so wasn't sure if that was a yes, no, or maybe; 550+ posts is a lot to trawl through and not miss something.

    Maybe for the MkIII smile.gif
  • Paul BakerPaul Baker Posts: 6,351
    edited 2007-08-24 17:15
    Yeah, it's a lot of posts to trudge through, it immediately became a wish list for everyone to voice thier opinion on what the next chip should be. It may be in the cards at some future point, but I'm not going to discuss anything beyond the next chip (and I try not to discuss that either since it only seems to stir things up again).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Paul Baker
    Propeller Applications Engineer

    Parallax, Inc.
  • Bob the Builder on a C64Bob the Builder on a C64 Posts: 112
    edited 2007-08-25 02:01
    Hey, Paul, will there be a prop 3 ever? [noparse]:o[/noparse] But still, this prop 2 seems to be great, only more cog memory as he asked, would be quite nice. Still, the idea of using this for rather complex things just gnaws at me like the night.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Realize that I am really a mad scientist··· and


    Don't forget it!

    http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg

    ·
  • evanhevanh Posts: 16,075
    edited 2007-08-25 04:57
    Heh, an architectural change might be to lose the conditional execution and gain 2 more bits for both source and destination fields.

    But hey, more cogs equals more total cog memory also ... :P
  • Mike GreenMike Green Posts: 23,101
    edited 2007-08-25 05:24
    evanh,
    Have you looked at the Large Memory Model stuff? It adds partial interpretation to the machine with most instructions executed directly and a few (mostly jumps) semi-interpreted. It adds roughly 200% overhead to what is a very fast machine (instructions execute on average about 30% of the actual instruction execution rate). With careful use of caching and some other optimizations, this can be brought down for "real code". The C compiler due later this year will use this model. It makes the 496 long word cog memory size much less of a "limitation". Particularly with the larger hub memory of the PropV2 and the increased speed (and built-in multiply), this should be quite a chip regardless of the cog memory size. The cog memory will be used as I think it should be for special, very time sensitive routines. The LMM stuff will be used for moderate speed routines and Spin can be used for large complex routines where the overhead for interpretation is pretty much irrelevant.
  • hippyhippy Posts: 1,981
    edited 2007-08-25 16:14
    Mike Green said...
    The cog memory will be used as I think it should be for special, very time sensitive routines. The LMM stuff will be used for moderate speed routines and Spin can be used for large complex routines where the overhead for interpretation is pretty much irrelevant.
    From a Spin Programmer's perspective I would probably agree. What should be in Cog memory and how Cogs are used is really up to the developer who doesn't have to be constrained by any notion of the Propeller being primarily a Spin Interpreter. From the perspective of an Assembler Programmer / Compiler Writer seeing the Propeller as nothing more than a multi-core processor, the Cog memory size is a potential limitation, albeit far from a crippling one, and one which can be overcome. As always, it's nice though to "have it all" smile.gif
  • evanhevanh Posts: 16,075
    edited 2007-08-26 05:31
    Mike Green said...
    evanh,
    Have you looked at the Large Memory Model stuff?
    Not at all. Though I do appreciate the sub-function-parallel-execution of Spin which can be viewed as "devices" at times.

    [noparse][[/noparse]quote]It adds partial interpretation to the machine with most instructions executed directly and a few (mostly jumps) semi-interpreted. It adds roughly 200% overhead to what is a very fast machine (instructions execute on average about 30% of the actual instruction execution rate).
    Sounds quite cool really. A practical way of dealing with the situation. WIll be interesting to compare with Spin.

    On the real estate side of things, keeping the cog ram size small means we also get more cogs and hub ram to play with. [noparse]:)[/noparse]
Sign In or Register to comment.