Variables globales frente a punteros en diseño integrado [cerrado]

Creo que puedo ver de dónde vienes. (Después de leer sus comentarios.) Este es más revelador para mí:

... ¿ve gente diseñando software y simplemente evitando los globales a toda costa en estos diminutos sistemas integrados? Puedes despellejar al gato de cualquier manera, los globales me parecen más rápidos.

(También estoy imaginando los núcleos de la serie 8051/8031/8052/8032, por ahora).

Tomemos un método muy simple para crear colas de sistema operativo para un sistema operativo muy simple. Necesitamos una cola lista y una cola de suspensión, como mínimo. (Podríamos agregar colas de semáforos, pero no lo hagamos porque quiero mantener esto al mínimo). También queremos admitir una cantidad limitada de procesos. (Después de todo, esta es una pequeña MCU sin mucha memoria disponible).

Para empezar, definamos algunas constantes:

#define NPROC 10
#define TAILPRIORITY 10000  /* you will see the need later */

Para las colas, utilicemos un enfoque de lista enlazada y reconozcamos el hecho de que necesitamos inserción y eliminación y nos gustaría que estas operaciones fueran bastante fáciles de lograr. Entonces llegamos a la conclusión de que queremos punteros anteriores y siguientes para cada entrada de la cola. También queremos apoyar un campo prioritario:

typedef struct proc_s proc_t;
typedef struct proc_s {
    int priority;
    proc_t *next;
    proc_t *prev;
} proc_t;

Ahora, podemos simplemente definir esto, estáticamente (el alcance podría mantenerse a nivel de archivo):

proc_t readyhead, readytail, sleephead, sleeptail, freehead, freetail, proc[NPROC];

Veamos ahora lo que se necesita para eliminar e insertar un proceso en una cola (tenga en cuenta que las variables de la cola lista y de suspensión son tipos de proc_t completos, no solo punteros a ellos. Esto simplifica el siguiente código). También agregaré un " getfirst" porque lo necesitamos para algunos propósitos.

/* Assumes that 'item' actually resides within a queue. */
proc_t * remove( proc_t * item ) {
    item->prev->next= item->next;
    item->next->prev= item->prev;
    return item;
}
/* Not to be used if 'item' is already in another queue. */
/* Priority insertion assumes that all queues end in a tail */
proc_t * insert( proc_t * queue, proc_t * item, int priority ) {
    proc_t *n, *p;
    for ( n= queue->next; n->priority < priority; n= n->next ) ;
    item->next= n;
    item->prev= p= n->prev;
    item->priority= priority;
    p->next= item;
    n->prev= item;
    return item;
}
proc_t * getfirst( proc_t * queue ) {
    if ( queue->next->priority == TAILPRIORITY )
        return NULL;
    return remove( queue->next );
}

Todo lo anterior supone, por supuesto, que los punteros de cabeza y cola de la cola se inicializan correctamente y que las entradas en proc[] se insertan primero en la cola libre y se eliminan secuencialmente. (También asume que la cola siempre tiene una "prioridad" que es el mayor valor posible y es más grande que cualquier proceso válido que pueda poseer: TAILPRIORITY).

¿Qué más podriamos hacer? Sin dividir esto en pedazos como arriba, aquí hay otra oportunidad:

#define NPROC (10)
#define TAILPRIORITY (10000)
#define READYQUEUE (NPROC)
#define SLEEPQUEUE (NPROC+2)
int next[PROC+4];
int prev[PROC+4];
int prio[PROC+4];
int remove( int item ) {
    int n= next[item], p= prev[item];
    next[p]= n;
    prev[n]= p;
    return item;
}
int insert( int queue, int item, int priority ) {
    int n, p;
    for ( n= next[queue]; prio[n] < priority; n= next[n] ) ;
    next[item]= n;
    prev[item]= p= prev[n];
    prio[item]= priority;
    next[p]= item;
    prev[n]= item;
    return item;
}
int getfirst( int queue ) {
    if ( next[queue] > NPROC )
        return -1;
    return remove( next[queue] );
}

El compilador de C ahora conoce de antemano la dirección de las matrices next[], prev[] y prio[]. getfirst() ya no necesita depender de un valor de prioridad especial (aunque insert() aún requiere algo así, pero eso también podría cambiarse ahora).

¿Importa esto desde el tamaño del código y/o el argumento de rendimiento? Tal vez. Depende del compilador. Para sonreír, pruebe estos dos enfoques diferentes con el compilador SDCC y eche un vistazo al código ensamblador generado para cada uno. ¿Qué opinas?

¿Qué pasa con el caso de la legibilidad? ¿Cuál es más legible para ti? (No busqué "particularmente legible" o "particularmente ilegible", sino "coherentes entre sí").

¿Qué hay de mantenible? ¿Qué sucede si necesita ampliar el tipo de nodo de lista vinculada? ¿Sería más fácil de mantener agregar otra matriz (segundo ejemplo de código fuente)? ¿O más fácil de mantener para agregar otro elemento a una estructura (primer ejemplo de código fuente)? ¿Haría tanta diferencia, en absoluto?

Suponga que está pasando un nodo de lista enlazada. ¿Es mejor pasar un puntero o un índice? Tenga en cuenta que pasar un puntero permite que una función acceda a cualquier elemento dentro de la estructura, incluso si se supone que no debe hacerlo. Pero pasar un índice podría permitir colocar la visibilidad de partes específicas "en otro lugar" para que, si hubiera un intento, el compilador pudiera emitir un error. Pero hay otras consideraciones, por supuesto. ¿Qué argumentos ves, a favor y en contra?

Y así continúa.

¿Personalmente? Creo que la consistencia del estilo es quizás lo más importante. Puedo acostumbrarme a casi cualquier estilo de codificación, incluso a los que no me gustan mucho. Siempre que la programación sea consistente , se trata principalmente de acostumbrarse y luego seguir adelante. Sin embargo, si la programación cambia de una mentalidad a otra y luego a otra y hay poca o ninguna consistencia en el código, me resulta bastante difícil de leer y/o mantener bien. Así que esto es probablemente lo más importante para mí. Establezca un estilo y luego manténgase consistente con el estilo.

Hay algunas áreas que están llenas de problemas. Por ejemplo, usar el montón en un sistema integrado en lugar de memoria estática. (Especialmente cierto, supongo, para la familia 8051). Es muy, muy fácil para un compilador y enlazador calcular el espacio total requerido para matrices estáticas y hacerle saber si cabe en el procesador que está usando en ese momento. . Pero es muy difícil encontrar errores de memoria similares si la única forma de averiguarlo es ejecutando el programa y asegurándose de ejercer todo el código condicional necesario para forzar la combinación correcta de eventos para exceder la memoria. , cuando se usa el montón.

No hay nada intrínsecamente malo con el montón. Pero en la práctica con sistemas integrados, creo que necesita una buena justificación. Así que buscaría criterios explícitos que justificaran su uso, si se usa.

Así que también busco pensamiento elaborado en código. ¿Por qué se tomaron ciertas decisiones? ¿Muestran buen juicio? En los casos en que se requiere evidencia extraordinaria para algún uso, ¿se ha proporcionado esa evidencia y tiene sentido? Etc.

Sin embargo, en el caso de la familia 8051, las instrucciones necesarias para hacer referencia directa a las direcciones específicas asignadas son mucho más pequeñas (espacio de código) y mucho más rápidas, que todos los buenos compiladores de C (un número cada vez menor de empresas, por cierto) proporcionará un mecanismo para el análisis de ruta de llamada estática para que las variables de funciones locales puedan ser asignadas (con alguna probabilidad de éxito) direcciones fijas. Entonces, en este caso particular, esperaría encontrar un uso mucho mayor de la estática, ya sea local en el archivo o disponible globalmente en el alcance. Tiene demasiado sentido en el 8051.

Las transiciones de las que he sido parte han pasado de ALU de 4-8 bits y anchos de memoria a 32/64/128, con 32 bits bastante comunes ahora. La definición de qué tipo de controlador puede encontrar en un dispositivo pequeño también ha cambiado y no me sorprende en absoluto encontrar que Linux se usa para poco más que parpadear algunos LED en un núcleo 16/32 ARM7TDMI. (O incluso una superescala Cortex-A53). Entonces, lo que es apropiado en el nivel de codificación C variará un poco.

Espero consistencia en el código fuente y un razonamiento bien considerado para las elecciones de diseño que se toman. Eso es lo más importante, para mí. Más allá de eso, soy un poco más flexible con mi opinión.

Lo que 'quieres' es refactorizar. Si es para un negocio (por lo que hay dinero involucrado), solo hazlo cuando el tiempo (por lo tanto, el dinero) te esté dando más:

• mantenibilidad
• legibilidad
• posibilidad de ampliar

Si es un proyecto de 'hobby' y 'sientes' que es mejor usar punteros, adelante. De lo contrario (y los elementos anteriores no son aplicables o no tanto para dedicarle tiempo), deje el código como está.