Different variable types in calculation?

[Creative25]

Hi I have a question about calculations.
Is it possible to use different variable Types in the same calculation?

C=A/B

Say the result "C" is bigger than 255 therefore it needs a Int variable.
"A" is a long number therefore it needs a Long variable and "B" is always less than 255 therefore it only needs a byte variable.

Is it Ok to use different variable types? Or is it better to use the same type of variable through the whole calculation?
Best Regards:
Uli

[Benj]

Hi Uli,

The different variable types should all work fine together.

Int = Long / Byte

The only time there will be a problem is if the result is too large to fit inside the variable type specified. There can be casting issues when using longs on a 8-bit device but give it a go and see how you get on.

[Creative25]

Hi Benj
Thanks for the Info.
What I have noticed is that some calculations gave a return of 0 instead of the right result.
"A=(b*c)/d"

After I broke the calculation down into smaller ones

"A=b*c
A=a/d"

it works fine.

Best Regards:
Uli

[JonnyW]

Hello. What version of Flowcode is this, and are you talking simulation or download?

For example in simulation Flowcode 6 will always use 32-bit for its intermediate calculations. The compact A=(b*c)/d should always work OK in this case.

Can you post a flowchart that shows your problem?

Cheers,

Jonny

[Creative25]

Hi I am Talking about Flowcode5
Using a program in real Hardware.
A Pic 16F1939
My code is working now. I just want to learn More about variables.
Best Regards.
Uli

[JonnyW]

Hi. OK, no probs.

Flowcode 5 will behave in simulation the same as v6, which is to keep as like to C as it can.

What a C compiler should do is perform any intermediate calculations as 'int', meaning multiplying two bytes will result in an integer. The optimisation may be 'clever' though (read 'wrong') and first look at what you are assigning it to. Many bugs in compilers come down to over-zealous optimisations.

I would be interested in the values that would cause A=(b * c) / d to be zero but not the broken up version, and have a look at the assembly code produced.

Jonny