Any commen term for combinable and distributable?

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Any commen term for combinable and distributable?

Post by aclassifier »

In [1] there is this chapter structure:

Code: Select all

2 Parallel tasks and communication
  2.3 Creating tasks for flexible placement
    2.3.1 Combinable functions
    2.3.2 Distributable functions
Is there a common denominator term for these two traits: combinable and distributable?

1. Flexibleness?
2. Placementness?
3. Flexibilityofplacementness?
4. ..?

[1] XMOS Programming Guide


--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

Any distributable task is automatically combinable..
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

Yeah, but what might both be called as a common term?

It might enhance the understanding to have a name on the set that combinable and distributable are (the only, so far?) members of?
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

combibutable ... distribinable? ;-)

It's an interesting point. Either of these cause the compiler to emit different versions of the same task which may be:

- Suitable for select combining/flattening
- Inlined as a function
- Forked and run as an stand alone task

In each case the functionality/logic is the same, however the implementation (and timing) may be significantly different. Whatever the Computer Science term for that is?
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

combibutable ... distribinable? ;-)
...

I may try to do a short (5-15 minute) informal fringe presentation about this whatever it's called at [1].

This whatever it's called might have been a good title and a help to try to grasp the ideas already by reading the title.

If there is no such common term then maybe that need to be the (not so good) title...
Off Topic
Feed me with more info about this if you have any, and I'd be thrilled. I don't plan to tell about the object code generated, as I wouldn't know. However, the main ideas, for the people there who probably would be highly qualified and teach me a lesson or two about these general concepts. If anybody from XMOS would go (I think its years since I saw any of them there (but I haven't been to all)) then I'll leave all talking to them
[1] - COMMUNICATING PROCESS ARCHITECTURES 2018 (CPA 2018)
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
robertxmos
XCore Addict
Posts: 169
Joined: Fri Oct 23, 2015 10:23 am

Post by robertxmos »

I am not sure if you are trying to tie two quite different attributes and intentions together that just happen to have similar (subset) coding requirements.
Indeed, the 'ability' does not necessarily mean they will be used in this way - they just have the necessary characteristics should you wish to.
If they are 'distributed' or 'combined' then the code runs in quite different ways viz: on the caller's stack/core or on a another core co-operatively multitasking with other tasks.
Thus, their eventual implementation are discrete - even if there declarations leave things fluid for the implementer to decide the final usage.

If you wish to talk about the implementation details and how the abilities can be ignored with implicit 'decay' to weaker attributes viz: distributed->combined->single-core, then the words to use are 'decay' 'conversion' & 'substitution'.... assuming the user has not explicitly marked the task accordingly.
Indeed the compiler emits all the code necessary for the linker to chose the eventual usage - throwing the rest away!

I hope that is of some help.
Best wishes for the presentation.
robert
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

This is great input for me, Robert! The fringe note will be published (even in the proceedings with ISBN numbers!) and with a url, so you can enjoy my attempt! I will of course have to quote you!-)
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

I think "packing" may be a rather ok word.

I did a fringe presentation at CPA 2018 (available at [1]) and it seemed like this may be a term? We were quite a few rather experienced people there trying to grasp what is going on.

Packing decorations combinable, combine, distribute, distributable and distributed
It that some heading? To me that single word clarifies a lot and would inspire me to read on.

(Please give resistance if you don't think this is a good term!)

[1] CPA 2018 fringe
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
robertxmos
XCore Addict
Posts: 169
Joined: Fri Oct 23, 2015 10:23 am

Post by robertxmos »

100 kΩ
'packaging' would be nearer the 'implementation truth' - packing suggest more effort and efficiency of density (e.g. packed structs in C).
Perhaps a better word is 'placement' viz: can/will/must the implementation be 'placed' on its-own/a-shared/another's logical-core.
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

'packaging' would be nearer the 'implementation truth' - packing suggest more effort and efficiency of density (e.g. packed structs in C).
Perhaps a better word is 'placement' viz: can/will/must the implementation be 'placed' on its-own/a-shared/another's logical-core
I like 'packaging' better than 'placement' (disclaimer: being a Norwegian native speaker). The reason partly is because I remember the config language of occam on the transputer that used 'placed' as something specific and a predefiend term, like also the the "on tile[x].core[y]" in xC. So maybe
  • Placement: anything that starts with an 'on', something in control by the coder. This term is already used in the XMOS Programming Guide: "2.1 Parallelism and task placement"
  • Packaging: Anything with combinable and distributable. The coder uses the three task types explicity, and is in charge in a way. The tool packages the code in the best way possible. XMOS Programming Guide would call this "2.3 Creating tasks for flexible placement"
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
Post Reply