Adding at code input when variable has self assigment

[oddson]

It appears you cannot add to a code variable's input with multiple connections (as you can with every other primitive or module input) when that input is involved in a self assign of the form:

Code: Select all

in = in + c;

Is this a bug or is there a reason this should be so?

[stw]

I'm not very familiar with machine internals but i'd guess the "bug" is the version with only one float connected.
The reason seems to be that the x variable pointer is the same as the input pointer. What is wrong in the way that the input(x) is static but the x variable is incrementing. But on the other hand this is what the code expresses.
If two floats are conected the input and the x var get two different memory addresses which IMHO is the correct way of handling this. The reason for that seems to be that all affected variables are treated individually. Which means we have not only one input (x) but two inputs flota1 and float2 with different memory addresses. These are processed into a third memory address (x).
I guess the attached image expresses better what i try to point out.
(Upper box=two float inputs - lower box=one float input)
(I hope i don't talk complete bulls.. here )

code.jpg (67.32 KiB) Viewed 716 times

However the really wired thing happens if you connect the second readout in my osm to the code output...

codeBugAddingAtInput2.osm

(2.38 KiB) Downloaded 79 times

[Xtinct]

Even wierder only connect the second readout

capture.png (40.58 KiB) Viewed 706 times

[trogluddite]

Not sure I would call this a bug - but it is behaviour that really should be highlighted in the documentation.

As stw says, variables are just 'nick names' for memory addresses. When a 'streamin' is declared it doesn't create a new 'memory space' to hold that variable - it simple copies the output address of whatever is at the other end of the input link. (NB - the input link - this method implies that there can be only a single source)

In general, writing back to streamin variables is not advised. In effect you are actually writing to the output 'variable' of the input source. This can mess with the processing of the 'input' module (if it uses it's 'out' variable recursively, as in a lot of filters etc.).
Also, if you have many destinations fed by one source, all destinations will 'inherit' any changes made whenever a 'streamin' writes-back to the source - depending on the execution order of the destinations, they may even see different values depending when the 'writeback' occurs.

My guess is that it was done this way to save extra CPU overhead from generating 'proxy' code inputs to allow for 'hidden summing'. The same result can, of course, be achieved by summing explicitly , either with primitives, or within the code - but there's no excuse for OutSim not pointing out the need to do that.

[stw]

As stw says, variables are just 'nick names' for memory addresses. When a 'streamin' is declared it doesn't create a new 'memory space' to hold that variable - it simple copies the output address of whatever is at the other end of the input link. (NB - the input link - this method implies that there can be only a single source)

But this won't explain why SM devides the "double input" version into five addresses (in1,in2,const,x,y) but the "single input" version only into three addresses (in=x,const,y). Which means the single input version DOES write back to the input but the double input version does NOT?