Hey, to all my #forth friends out there:
Is there any prior art for "message passing" in forth in the past?
I want my runtime to be able to "send" and "receive" messages, as the primary interface for e.g. getting RPC commands and returning responses.
Conversation
I've considered introducing a one-sided FIFO primitive, perhaps with a "name" or "idx" field baked in, to determine what to do with the message.
Though reading the Hubris design docs, I'm wondering if there is merit in a more synchronous pattern instead.
1
1
The use case would be for things like building a forth-driven I2C temperature driver, where you might want to regularly send the current temp, and perhaps the "other machine" could change some kind of setting, like a polling rate.
1
Or even a servo driver, where the "other machine" would send the desired position, or perhaps even query the current position.
2
Probably not much direct help, but the GreenArrays #GA144 (144 Forth CPU nodes) does message passing (RPC) by having each node listen & execute whatever word is sent to it's port.
1
3
If you want to send data you send a "fetch from port" command that reads the next word you send. If you want to read from the port, you send a command that causes the node to write to that port. It's "always be reading & executing words". Not sending data.
1
2
Show replies