[DUDA|PUNTOS DE VISTA] EL USO O NO DE LOS TIPOS DE DATOS DEFINIDOS EN STDINT.H

[man3s]

Hola amigos, leyendo la guia de usario de XC8 (cosa rara el que yo lea algo por voluntad propia ), me surgio una duda: utilizar o no los tipos de datos definidos en stdint.h.
Hace tiempo note, en un codigo escrito en codewarrior, el uso de tipos de datos como: uint18_t, uint16_t, etc. pensando que seria algun tipo definido por el propio compilador (como se hace con el tipo de dato word), investigando un poco note que fueron introducidos en el estandar denominado C99 notando su gran ventaja al poder utilizarlo para permitir codigo portable, muchos compiladores de uC tienen ya implementado stdint, y asi lo he hecho inclusive en CCS, ahora que ando en XC8 me he puesto a leer el manual, como ya habia mencionado anteriormente, y entonces veo el siguiente parrafo:

The following example shows the definition of a variable, native, whose size will allow
efficient access on the target device; and a variable, fixed, whose size is clearly indicated and remains fixed, even though it may not allow efficient access on every device.
int native;
int16_t fixed;

a mi entender, hace mencion de que es mas eficiente utilizar los tipos de datos denominados nativos  a los declarados en stdint.h, no se si en este compilador pero en otros he visto que simplemente crean un macro para definir estos, por ejemplo:

#define uint8_t usigned char

pero, si lo dice en mismo microchip en su manual debe ser por algo, entonces, ¿que piensan?, ¿es correcto utilizar estos tipos de datos o utilizar los nativos?, ¿creen que exista un impacto, en rendimiento u optimizacion, muy grande al usarlos o no?.

En lo personal siento es mas ventajoso el utilizarlos a tener darse a la tarea de conocer el tamaño del tipo de dato a utilizar dependiendo de cada compilador, ¿que piensan ustedes?.

Saludos.

[BrunoF]

Hola,

el manual es bastante certero a la hora de dar la definición. Parecería asumir que el lector está al tanto de los problemas latentes relacionados al uso de variables de tipo integer a lo largo de diversas arquitecturas/hardware. El principal problema es que históricamente el integer no ha tenido un tamaño definido y esto ha supuesto muchos problemas al intentar generar código fácilmente portable/multiplataforma.

Lo que está queriendo decir el manual, es que si declaras una variable como int, estás dejando que el compilador, conociendo para qué hardware está compilando, pueda determinar el mejor tamaño nativo para dicha variable entera. En el caso de las familias de PICs 12,16 y 18 debería ser entonces de 8 bits, pero para un dsPIC32, seguramente el tamaño del int debería ser de 32 bits (digo debería porque nada impide que un Compilador reemplace los tamaños nativos por otro por convenienca o porque se le da la gana). Claro que a favor tiene el hecho de elegir automáticamente el mejor tamaño en cuanto a velocidad de cálculos se refiere, pero puede ser un problema no sabe exáctamente qué tamaño tienen las variables integer, más aún cuando intentamos hacer código multiplataforma que compile para varios procesadores distintos.

Por otro lado, al utilizar la declaración fija, como al hacer: int16_t fixed estamos de alguna manera forzando al compilador a que arme una variable integer con 16 bits, independientemente de su tamaño de memoria nativo. Utilizando los mísmos ejemplos previos, para lograrlo en familias de PICs 12,16 y 18 el compilador deberá de alguna manera unir 2 bytes (ya que 8 bits es su tamaño de memoria nativo) y trabajarlos juntos para lograr armar los 16 bits pedidos, claro que con la penalización en consumo de instrucciones/ROM/RAM consecuente y en el caso de la familia dsPIC32, tendrá que utilizar sólo 2 bytes de los 4 (32 bits = 4 bytes) incluso a veces desperdiciando esos dos bytes en desuso, o bien siendo penalizado como en algunas arquitecturas (como en los ARM Cortex-M3) donde se pueden utilizar instrucciones de 16 bits, orientadas a manejo de variables de 8 bits/16 bits, pero siendo penalizados en ciclos de ejecución al hacerlo debido a la interrupción que debe producirse en el normal funcionamiento del pipelining y pre-fetching del código ROM.

En definitiva, la declaración de variables de tamaño nativo asegura el mejor rendimiento, al menos en teoría, mientras que el uso de definición de variables de tamaño fijo explícito, permite mayor portabilidad.

Personalmente no uso jamás el int. Prefiero ser consciente que si declaro una variable de 16 bits / 32 bits en un PIC18F se que estaré perdiendo un poco de rendimiento por ser de 8 bits su tamaño nativo.

 

[MerLiNz]

El unico punto de vista que tiene es la portabilidad, por lo demas es todo igual, por ejemplo si cambias de ccs a xc8 por ejemplo hay tipos que tienen distinta cantidad de bits sin embargo si declaras int16 utilizando el encabezado definido te aseguras que estes en el compilador que estes siempre tendras un integer de 16bits

[man3s]

Valla, nunca espere una respuesta tan completa como la de BrunoF  , no lo habia visto de esa manera simplemente porque a veces se pasa por alto esos detalles cuando uno programa en C  , ademas que no he pasado de uC de 8 bits  pero es bueno saberlo, desde ahora preferire utilizar macros para definir mis propios uint16 basado en los enteros "nativos", cuidando siempre de leer la documentacion del compilador para ver si es mas ventajoso el usar un int o la variable acorde al tamaño de los bits del uC, todo para permitir que el compilador realice las optimizaciones pertinentes  , entonces:
PORTABILIDAD -> STDLIB.H
RENDIMIENTO -> NATIVOS.

Gracias a ambos. Saludos.