But I find it difficult to read those documents. Partly because they're not really written for a common XC programmer who wants to know some about what's going on under the hood. So I have now compiled app_mutual_comm_example that uses module_mutual_thread_comm that has a lot of comms and :> and <: examples. I have studied the .s assembly files and made some figures (that I don't dare publish here). But here's some added comment I made that i really don't understand:
Code: Select all
// Summary by analysing main.s:
// c <: val; OUT chan ASM: outct, chkct, out, outct, chkct
// c :> x; IN chan ASM: chkct, outct, in, chkct, outct
Code: Select all
// "The XMOS XS1 Architecture" (David May), chapter "Communication" p23:
// To perform synchronised communication,
// the output message should be followed with (OUTCTI c, END; CHKCTI c, END) and
// the input with (CHKCTI c, END; OUTCTI c, END).
What's so elegant is that every assembler instruction in mutual_thread_comm.xc takes a chan as a parameter! There's no magic system state there!
I have edited some in the files, like:
Code: Select all
void mutual_comm_notified(chanend c) // select handler
{
(void) inct(c); // in control token: __builtin_inct(c)
outuchar(c, 1); // out unsigned char, different from input (:>) and output (<:) operators: __builtin_out_uchar(c, val)
outct(c, XS1_CT_END); // out control token: __builtin_outct(c, val)
chkct(c, XS1_CT_END); // in control token of value. __builtin_chkct(c, val)
}
Also, the rationale for how mutual_thread_comm.xc is built. When I designed the XCHAN [1] some years ago it was certainly necessary to make it deadlock free. I guess that the reason for making the concept asymmetrical with ReactiveMaster and NotifyingSlave is not to introduce cycles, so i'ts deadlock free?
Summary: somebody please make an MSC of all chan usage in app_mutual_comm_example and mutual_thread_comm? Or hold my hand?
[1] http://www.teigfam.net/oyvind/pub/CPA2012/paper.pdf