variables and their calculations on CCS C

z1rqdym · Joined: 14 Dec 2014 Posts: 24

compiler version 5.015
mcu/dsp : dsPIC33F

i want to know something about variables and calculations.

example:

RF_Developer · Joined: 07 Feb 2011 Posts: 839

Ttelmah · Joined: 11 Mar 2010 Posts: 19382

The key point though is the maths type.

This is fundamental to C (not just CCS C).

In C, if you perform arithmetic between two values. Say int16/int8, then int16 arithmetic will be used. C 'looks' at the types of the two variables, and uses the type of the 'highest' variable.
Types are organised as:

double (PCD only)
float
signed int32
int32
signed int16
int16
signed int8
int8
(highest to lowest)

Now types carry forward. So:

(int16*int8) / int8

Will use int16 arithmetic everywhere - the first expression has an int16, so the int8 is converted to int16, and int16 arithmetic used. The result is then int16, so the next sum becomes int16/int8, and int16 arithmetic will be used.

Important thing is that it is the types of the two arguments, _not_ the final result.

So if you have a sum like:

float = int16/int8

int16 arithmetic is used.

So if you did y/k (int16), 15098/12546, and put the result into a float, the result would be 1. Int's don't have a fractional part.

This becomes particularly important on CCS C, because unlike a lot of PC "C's", the maths is all library based. Historically this was the case on early computers and so the PDP-8, used 12bit arithmetic, and this was the default size of it's 'integer'. However on things like the PC (except for the earliest models), we get spoilt, and maths is now done by the CPU itself, but the FPU. A separate part just optimised to do arithmetic. This has the design that it'll automatically 'overflow' if needed. So if you do int16*int16, you can get an int32 result. This 'hides' the way that C historically (and on the PIC) handles maths. CCS C also defaults to int8, as the default integer size, so problems can appear earlier than on systems where int16 is the default.

The advantage of the constrained math type, for a device without the FPU, is speed, and size. An int8 division takes 11.3uSec on a modern PIC18. Int16, 32uSec, int32 106.6uSec, and float 144.9. Because you know what maths type is involved, the speed is known and won't change. However values can (and will) overflow with data lost. The maths code for larger types also grows enormously, so if you tried to use a automatic switching library on a PIC16, it probably wouldn't even fit.

The 'cast' allows you to convert a value _before_ the maths is performed. So:

So if you do (float)y/k, the result is the float 1.203411.

You need to consider what maths type to use, where you can save space and time by using smaller types, and ensure that your values are inside the ranges that can be handled by the maths as you write your code.

Also don't get 'fooled' by the apparent abilities of floating point. A 32bit FP value, offers _less_ precision than an int32. Only 23bits of actual 'precision' (technically 23.5 bits), what you gain is the ability to handle numbers over a massive range. What you lose is accuracy. Try doing some financial calculations using float, and then be surprised at how many digits 'out' your final result will be. Financial calculations are normally done using 'scaled integers', so counting 'integer cents' for example, to avoid this....

Most jobs on the PIC involve numbers with a constrained 'range' (ADC values for example), so it is worth not using unnecessarily complex maths types for dealing with this.