Shop OBEX P1 Docs P2 Docs Learn Events
Message passing on P2 — Parallax Forums

Message passing on P2

SeairthSeairth Posts: 2,474
in Propeller 2
Heater. wrote: »
I think the best idea would be to run multiple Lua instances, one per cog, and provide a library that allows for message passing between them.

This merits its own thread. Of course, you've mentioned the need for message passing elsewhere. And this is definitely something the P2 should handle well. So the question here is: what options do we have right now?


Hub
Like the P1, we can do Hub slots/mailboxes. Also like the P1, there's a penalty for random access timing. Unlike the P1, we can use SETQ to more efficiently transfer large messages. You can also have a queue, which then provides the ability to asynchronously send messages. Because the Hub is a shared resource, it is possible for multiple cogs to interact with the same message(s), either intentionally or unintentionally.

Locks
Like the P1, we can do locks as flags. Also like the P1, these are slow hub operations. Unlike the P1, there are 16 instead of 8. Also, unlike the P1, cogs can efficiently INT/WAIT/POLL them via selectable events. Unlike Hub, these are limited to flags/events (1-bit messages), and cannot be used asynchronously (for the purpose of "message passing").

Shared LUT
For paired cogs, we can do message passing using the LUT. This can be treated similarly to Hub message passing, but without the overhead cost. Further, if the messages can fit into a single LONG, you can effectively use selectable events to INT/WAIT/POLL for messages. Share LUT also has the added advantage that they are protected from being read or modified by other cogs. However, there is less overall space for messages, as compared to Hub messaging. And, you are limited to communicating with your paired cog.

ATN
The new ATN functionality also provides a simple form of messaging. Since ATN can be detected by INT/WAIT/POLL, this can be effectively used by itself, or in combination with Hub or Shared LUT messaging. On their own, ATN has similar limitations as Locks, but without the overhead cost.

Smart Pins
You can even use the smart pins! In this case, each pin can store a LONG. You can then use INT/WAIT/POLL and read them. The advantage of using these over hub is that they are fast. The advantage of using these over Shared LUT is that you can pass messages to any cog, or even multiple cogs. With 64 smart pins, it will be increasingly likely that you will have some unused smarts that could be repurposed for messaging. However, this is still a limited resource that is not available if the Smart Pin is otherwise in use.

So... is there any other way that I've missed?

Comments

  • RaymanRayman Posts: 14,641
    edited 2017-03-19 02:38
    Hey, I thought we dropped locks... Just looked them up in spreadsheet and they are there though.

    No mention in documentation though...
  • SeairthSeairth Posts: 2,474
    One of the unfortunately things about all of the above options is that you can't easily use them in shared libraries. For instance, suppose your library had a messaging scheme that worked best with smart pins. That's great, until you don't have any smart pins to spare. At that point, it's a non-trivial task to switch to a different messaging mechanism. Generally, this will cause shared libraries to tend towards the use of Hub, as it is the largest available resource (if you run out of *that*, you have bigger problems than message passing). As a result, the practical outcome is that only hub messaging will be used, except for your hand-rolled code.

    (note: One minor exception will be the Shared LUT where a shared library specifically makes use of paired cogs.)
  • RaymanRayman Posts: 14,641
    Seems you might be able to use the debug interrupt to control one cog from another one via the HUB...
  • SeairthSeairth Posts: 2,474
    Rayman wrote: »
    Hey, I thought we dropped locks... Just looked them up in spreadsheet and they are there though.

    No mention in documentation though...

    They are basically the same as on the P1, except:

    * 16 instead of 8.
    * You can used SE1-SE4 to INT/WAIT/POLL on them.
  • DavidZemonDavidZemon Posts: 2,973
    At the cost of some code space and probably performance, we ought to be able to write a wrapper around these different messaging designs and make them all interchangable. In C++, that'd be implemented via an interface. I'm sure something could be done for spin and other languages too.
  • SeairthSeairth Posts: 2,474
    I believe one of the other things that Heater has mentioned about the need for message passing is as a means to share code written in disparate languages. For instance, you could have a Spin cog messaging to a Lua cog. Or a PASM cog talking to a JS cog. Or a C++ cog talking to a Spin cog. And so on.

    In order for this to work effectively, I think you'd want a "standard" messaging scheme. Then, each language would add library support for that scheme. In all likelihood, with the current options, this can only be done using Hub messaging.

    (Like I mention above, this will likely reinforce the use of Hub as the de facto messaging resource, leaving the other options underutilized.)
  • Cluso99Cluso99 Posts: 18,069
    We have tried so many times to get a standard messaging scheme for P1.

    But what killed it was not the non-agreement of how to use it... It was scuttled by those who didn't want it!

    RossH (Catalina C for P1) eventually went alone with Catalina and interfaces quite well with both spin and pasm cogs.

    I went alone with my Prop OS. It decouples the standard input and standard output, such that the driver cogs can be substituted, even on the fly if you require although I have not done this.
  • Heater.Heater. Posts: 21,230
    edited 2017-03-19 05:32
    Getting agreement on the method of message passing is essential for it to have value. If there were such a thing it would work the same from all languages. This way "components" could be dropped into a project and "wired up" to the rest of the program easily. No matter who wrote them or in what language they are written.

    I fear that to get such agreement, and importantly to get everyone to use it, is all but impossible. As we have seen before.

    Unless that is, the message passing mechanism were baked into the actual hardware. Like channels are on XMOS devices and the old Transputer before it.

    It's far too late now to be thinking of a harware solution.

    Perhaps if the idea were baked into the Spin language for the P2 it would set a precedent and get some traction. I would not bank on it though.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    There are plenty of standards out there to choose from, some more gingerbread-laden [cough ... XML ... cough] than others:

    https://en.wikipedia.org/wiki/Remote_procedure_call

    -Phil
  • Heater.Heater. Posts: 21,230
    XML! God forbid.

    RPC mechanisms and formats like XML, JSON, etc are some levels of abstraction higher up than I was thinking.

    At some basic level the first thing we need is a common, reliable and fast way to move bytes between parallel processes.

    But, that's a good point. If we had such a channel/pipe mechanism in place very soon everybody would design their own mechanisms and formats on top of it and we would be back to chaos again.

    It's hopeless...
  • David BetzDavid Betz Posts: 14,516
    Maybe the problem is that standards are viewed as contrary to the Propeller philosophy. One big advantage that keeps being stated about the Propeller is that you can understand the entire system. When you start adding standard layers you move in the direction of a kernel or OS. You can, of course, fully understand a simple kernel, but will Propeller fans view it that way or will they want to "roll their own" everything having full access to the underlying hardware?
  • Heater.Heater. Posts: 21,230
    I think you are right.

    Unless, as I said, such channels/pipes were baked into hardware. Then that would be a standard nobody could avoid :)

Sign In or Register to comment.