Implement boolean types support

[JulianKemmerer]

&& 'logical and' should be defined as l!=0 & r!=0 - it is not

if(x) should evaluate if(x!=0) - it does not
x ? ternary operator has similar problems

[suarezvictor]

Does it consider short circuit functionality? Thas isz for example in case of &&, the second should be skipped (i.e. if has side effects such as chamging variables, that should't ocurr) basic implementation is with nested ifs:
If(a && b) stmt; => if(a) { if(b) stmt; }

[JulianKemmerer]

Good question @suarezvictor

These types of functions we have been writing in PipelineC are currently 1) (and potentially 2) in the below image

I say this because on twitter you saw a third style using a 'clock step operator' clk() function. But that is experimental/undocumented at the moment - and maybe this would apply there - but at the moment doesnt apply to you.

So for now, in the style of function we have been writing so far, something like

expr1 & expr2

Creates hardware that is

           ______
expr1---->|      |
          | AND  |--->
expr2---->|______|

Meaning that the expressions are evaluated in parallel by parallel/duplicated hardware prior to the and. There is no opportunity to only evaluate expr1 and stop if false.

This is a result of PipelineC deriving a dataflow graph from the C code. A little bit from the docs:

// Simple example of math pipeline
float main(float x1, float x2, float y1, float y2)
{
   float x_sum;
   x_sum = x1 + x2;
   float y_sum;
   y_sum = y1 + y2;
   return x_sum + y_sum;
}

The above example instantiates 3 floating point adders. Two in parallel, and a third for the return.

Would love to answer any more questions you have :)

[JulianKemmerer]

I see you ask about side effects - a quick sentence if you are interested:
These functions can maintain state (making them style 1 only). But the state the maintain (even if in global namespace, declared as global variable, etc). Is not a 'shared global memory' like on a cpu. There are additional mechanisms to move data between functions like you would normally do via a global/shared memory concept. So 'global stateful side effects' are not really a thing.

[suarezvictor]

To me, the best solution if && appears in code, is the following:

…

-if second and subsequent operands doesn't have side effects, then it would be equivalent to evaluate both or just one of them, the only difference is to test the operand with "!=0" (all bits 0) instead of bitwise and (it would be the same if data is of only a bit -- most common case) -In case the second operand has side effects, then a warning can be reported to user, and implement the correct logic in a less performant way. The chance of having && with side effects statements are exceptionally low... I know adding all this logic is quite difficult, so maybe for the moment an entry on documentation can say "short circuit logic isn't implemented yet, don't use it with operands with side effects!". That would cover the majority of the algorithms, anyways.

On Sat, Oct 2, 2021 at 1:05 PM Julian Kemmerer ***@***.***> wrote: I see you ask about side effects - a quick sentence if you are interested: These functions can maintain state (making them style #1 <#1> only). But the state the maintain (even if in global namespace, declared as global variable, etc). Is not a 'shared global memory' like on a cpu. There are additional mechanisms to move data between functions like you would normally do via a global/shared memory concept. So 'global stateful side effects' are not really a thing. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBHVWP4AZU7CM5RRCZUGKDUE4UURANCNFSM5FFDBLUA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[JulianKemmerer]

Correct support for boolean operators is implemented in 827620b

The remaining part of this is simply supporting the typedef of bool as a uint1_t #52 . For now work around with #define bool uint1_t etc as in new bool.h