Is Par redundant?

[Folknology]

Good point Changed it to 15 it ran the same.

Having said that it doesn't run every time, but that may just be an issue with the Xtag2 + XK-1 its not consistent ?

But the first time I run it after re-plugging the XK-1 it runs fine, so that's the one I count ;-)

[Heater]

Which raises an interesting question. Given that XC has bounds checking going on for arrays how come printf of a non null terminated string works?

Mostly when I have done that in the past it shows up immediately as gibberish in the output or a crash.

[Folknology]

Rowan It might be worth another thread, you can build the experiment to test it thisi time!!

Maybe the compiler is adding a null termination to char arrays of enumerated sizes?,

Or is there some real magic in Par{}? ;-)

[Heater]

Folknology: "...you can build the experiment to test it this time!!"

Love to but it might take a while. I still don't have any XMOS hardware:)

Perhaps a week or two when my next pay check comes in.

Perhaps they have written printf such that it stops cleanly when a string runs off the end of an array rather than raising some exception. Interesting.

[richard]

Which raises an interesting question. Given that XC has bounds checking going on for arrays how come printf of a non null terminated string works?

Mostly when I have done that in the past it shows up immediately as gibberish in the output or a crash.

XC has bound checking but C doesn't. printf() is implemented in C but is callable from XC. The array bound is discarded when printf() is called and out of bound accesses will result in undefined behaviour.

Often this would mean gibberish being printed / a crash but in this case I assume the first byte after the array happens to be zero and so it just happens to work. If you recompile with different options or make slight changes to the code then this may no longer be the case.

[Folknology]

Thanks Richard so we were lucky!

Can you confirm that channels can be recycled between par{}s as shown here without issues?

I am also curious as to what happens underneath with the channels and ends, a short description wouldn't go amiss if you can enlighten us.

regards
Al

[richard]

Can you confirm that channels can be recycled between par{}s as shown here without issues?

Yes, this is correct.

I am also curious as to what happens underneath with the channels and ends, a short description wouldn't go amiss if you can enlighten us.

When a chan is declared the compiler allocates two channel ends with getr and connects each end together with setd. When a channel is used in two threads of a par each thread is passed a different channel end out of this channel end pair. If there are multiple pars in a sequence then the same two channel ends are passed each time. When the chan variable goes out of scope the two channel ends are freed with freer.

[Folknology]

Perfect Richard thank you

[Jamie]

When a chan is declared the compiler allocates two channel ends with getr and connects each end together with setd.

Slightly off-topic but I just wanted to clarify...

A channel end identifier is comprised of the node id, code id, resource counter and resource type (2 for a chanend). The destination registers of a pair of chanends are initialised (with setd) by the transmission of the respective channel end identifiers, which can be done with a existing channel. When there is no other initialised channel, the destination identifiers are constructed manually which is straight forward to do - except for the resource counter.

Presumably, the resource counter specifies to which chanend a message should be delivered. So as long the resource counters for a pair of remote channel ends are the same, say 0 and the node and core ids set properly, then that constitutes a valid pairing on which a connection can be established? It seems this could be achieved by ensuring the channels are both obtained after the first, second or third etc. getr call, or perhaps by changing the returned resource identifier manually?

[richard]

getr returns the lowest numbered resource of the specified type which isn't already in use. Therefore the first channel end you allocate on a core will be chanend 0, the second will be chanend 1, etc. So long as you know the order in which channel ends are allocated on other cores you can build the correct resource ID of the remote channels ends.