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
Credit where credit is due: my ideas on protocols are heavily inspired by what I read about #GA144, applied to C/HDL & CSP.
Also: big difference between internal protocols (that can change over time and can thus be optimized for simplicity), and external APIs that cannot change.
1
2
I dread writing external APIs. They are an impossible problem: need to be future proof, but can't know everything ahead of time. So they get really ugly over time.
A lot of the Forth lore is about avoiding this altogether: get good at writing simple, special purpose code.
A message is a program that runs in another context. This is a really good way to look at things. Combine it with embracing statefulness at the receiving end, and compensate that by transactions.
Code is easy to generate, data is hard to parse.
Prefer printing over parsing.
1
2
The first time I encountered this was in the GUI protocol of Pure Data. Pd sends TCL to the GUI, and GUI sends Pd messages to Pd.
At first I thought this was really ugly. And maybe it is. But it is incredibly useful as a simplification tool in heterogeneous systems.
1
1
Show replies