El hilo del ocaso de Unity

**Drumpi** · 16/10/2023, 13:48

Volvemos a lo mismo: hay que usar la herramienta correcta para el problema concreto.

Yo he programado dispositivos embebidos en ASM. Cuando empezaron a salir los que se programaban en C me parecieron un atraso. Si Masteries lo ve bien es por una sola cosa: los sistemas lo soportan. La tecnología es mejor, la velocidad lo admite, los compiladores son eficientes, y el ahorro de tiempo es más que perceptible.

Lo mismo que hacer operaciones sobre una copia es perder el tiempo, hacerlo sobre los datos originales puede ser un peligro, o nada recomendable, porque pierdes los datos originales. Puede que los datos te hagan falta más adelante, y si los has modificado, tienes que volver a cargarlos. Mismos motivos por los que la gente trabaja con ficheros en copia local, y nunca desde un pendrive... o trabajaba.

Sí, hacer una copia de datos gasta memoria, pero copiar una matriz de 1024x1024x4 cuando tienes 16GB de espacio para trabajar, no me parece un malgasto de memoria. Diferente sería si estuviéramos con los 32MB de la Wiz.
Y no es que un malloc esté prohibido en un sistema embebido, es que la cantidad de memoria reservada para tal instrucción es extremadamente limitada, y se dice "prohibido" para que la gente se acostumbre a usar la cabeza. Al menos, cuando yo estudiaba, había siempre un bloque de memoria reservado para la pila, y otro para operaciones de memoria dinámica, pero si la memoria no me falla, por cada 8MB de memoria, eran 100KB como mucho.

EDIT: De hecho, siempre he visto un atraso los lenguajes interpretados, tipo Javascript: al final realizas una casi compilación cada vez que ejecutas el código, tienes que identificar las líneas, las palabras reservadas, los comandos, sus parámetros, una y otra vez, y todo en una ristra de caracteres. Eso, antes siguiera de pensar en ejecutar la acción. Y aparte, que cualquiera puede leer tu código, alterarlo, buscar vulnerabilidades... La de veces que habré guardado una imagen o un vídeo de una web que supuestamente lo tiene deshabilitado

Lo de las actualizaciones de 100GB creo que van por otros derroteros. Siempre me ha extrañado que un parche de código, que son los ficheros más pequeños de un proyecto, requieran descargar tantos datos en los juegos de hoy. Tanto espacio es indicativo de que se han modificado los gráficos y los sonidos, y si no hay nadie que se haya dado cuenta de ese detalle, o es que han cambiado datos no visibles (triggers en animaciones, metadatos...), o es que va todo encriptado, y el cambio de algunos bytes del ejecutable obliga a volver a encriptarlo todo por algún checksum o alguna verificación similar.

**masteries** · 18/10/2023, 13:01

Iniciado por Drumpi

Y no es que un malloc esté prohibido en un sistema embebido,

Técnicamente prohibido no,

Pero si tu sistema embebido va para un ascensor, una grúa, un automóvil, un tren, un avión, una nave espacial o un satélite, o para un dispositivo médico.
Y son escenarios bastante comunes para los sistemas embebidos; incluso si es algo de IoT para un coche... como va para un coche y se tiene que homologar,
pues a seguir las reglas, así que lo recomendable es seguir bastante muchas de esas reglas en el día a día, así vas estando preparado llegado el caso

Entonces sí está prohibido; pero se debe a las normas de codificación muy estrictas que debes seguir, creo que nunca te has enfrentado a ellas y no las conoces; tales como MISRA C y las derivadas del IEC según sector. Se trata de evitar casos como el del Challenger, que se cree se debió a dos controladores cuyo código estaba compilado con dos compiladores diferentes, y el tipo de dato predeterminado en ambos no coincidía... ya tampoco se permite hacer uso del tipo de dato predeterminado del compilador, por ejemplo esto:

unsigned short variable;

/* Declarar variables al estilo antiguo, como en C89, nada de declarar variables entre medias del codigo */
/* Ni utilizar tildes en los comentarios, y solo este tipo de comentarios, los de C89 */
/* Se pueden utilizar variables sin inicializar, pero en su primer uso, ha de inicializarse */

...
...

variable = 0;

/* Esto no se permite, porque ese 0 puede ser un double, un uint32, un int32... segun le salga al compilador */
/* la norma MISRA señala que no puedes apoyarte en los tipos por defecto del compilador */
/* ni utilizar funciones que no puedan garantizar un 100% de retorno con exito en todas las ocasiones, como malloc, free... */

variable = (unsigned short)0; /* Asi es como debe ir todo el codigo, incluso cuando se hacen operaciones, es muy pesado si */

Editado: Imaginad el caso del Challenger, desde el controlador central se envía un valor de 100 como un entero sin signo de 32 bits;
y el controlador del motor interpreta ese 100 binario, como un double o un float... el controlador del motor vió de todo menos un 100;
y reventó.

**chipan** · 18/10/2023, 13:48

Iniciado por zhorro

Y que te impide en C pedir memoria dinamica para duplicar los datos, aunque me parece que es una perdida de recursos duplicar los datos y no trabajar directamente con ellos. Atraso para mi es utilizar un lenguaje como python que es lo mas ineficiente que pueda existir o java para un backend o batch. Aunque a dia de hoy es raro utilizar C puro, es mas normal utilizar C++.

Nada te impide trabajar con punteros, salvo el hecho de que estás jugueteando con las direcciones de memoria. Si no cometes ningún error están muy bien, pero los humanos somos dados a cometer errores y los errores cuando estas toqueteando la memoria pueden tener consecuencias muy aleatorias y una trazabilidad un tanto difícil. Por mencionar algo que recuerdo de mis tiempos de estudiante, cuando para ahorrarte duplicar un array pasas un puntero a dicho array y decides avanzar por él sumando posiciones al valor del puntero y te sales de él sin darte cuenta, o cuando retornas un puntero y en lugar de acceder al valor que hay en esa dirección de memoria, tomas la dirección del puntero como valor, etc, etc.

**Drumpi** · 18/10/2023, 15:16

Iniciado por masteries

Técnicamente prohibido no,

Pero si tu sistema embebido va para un ascensor, una grúa, un automóvil, un tren, un avión, una nave espacial o un satélite, o para un dispositivo médico.
Y son escenarios bastante comunes para los sistemas embebidos; incluso si es algo de IoT para un coche... como va para un coche y se tiene que homologar,
pues a seguir las reglas, así que lo recomendable es seguir bastante muchas de esas reglas en el día a día, así vas estando preparado llegado el caso

Entonces sí está prohibido; pero se debe a las normas de codificación muy estrictas que debes seguir, creo que nunca te has enfrentado a ellas y no las conoces; tales como MISRA C y las derivadas del IEC según sector. Se trata de evitar casos como el del Challenger, que se cree se debió a dos controladores cuyo código estaba compilado con dos compiladores diferentes, y el tipo de dato predeterminado en ambos no coincidía... ya tampoco se permite hacer uso del tipo de dato predeterminado del compilador, por ejemplo esto:

unsigned short variable;

/* Declarar variables al estilo antiguo, como en C89, nada de declarar variables entre medias del codigo */
/* Ni utilizar tildes en los comentarios, y solo este tipo de comentarios, los de C89 */
/* Se pueden utilizar variables sin inicializar, pero en su primer uso, ha de inicializarse */

...
...

variable = 0;

/* Esto no se permite, porque ese 0 puede ser un double, un uint32, un int32... segun le salga al compilador */
/* la norma MISRA señala que no puedes apoyarte en los tipos por defecto del compilador */
/* ni utilizar funciones que no puedan garantizar un 100% de retorno con exito en todas las ocasiones, como malloc, free... */

variable = (unsigned short)0; /* Asi es como debe ir todo el codigo, incluso cuando se hacen operaciones, es muy pesado si */

Editado: Imaginad el caso del Challenger, desde el controlador central se envía un valor de 100 como un entero sin signo de 32 bits;
y el controlador del motor interpreta ese 100 binario, como un double o un float... el controlador del motor vió de todo menos un 100;
y reventó.

No, no conozco esas normas, porque por suerte no me he visto aún en la tesitura de tener que programar un sistema tan limitado, tan crítico, o de tiempo real.
De todas formas, lo entiendo. En un SO tienes la ventaja de que el sistema te reserva un espacio de memoria, y vigila que no te salgas de él. Eso no existe en sistemas embebidos... bueno, no existía, cada vez son más los que usan un kernel Linux, o un BIOS (y no me refiero al Sistema Básico de Entrada y Salida, sino al micro Sistema Operativo para estos cacharros, que no recuerdo cuál era el acrónimo ^^U). Como digo, yo aprendí microcontroladores en ASM, y los que iban dos cursos por detrás usaron C, y creo que ya andan usando Pyton.

En fin, que sí, lo del Challenger, según nos explicaron, a groso modo, fue que hubo un desbordamiento de una variable, por usar un byte en lugar de un int o algo parecido. Y por eso siempre he preferido los lenguajes fuertemente tipados, aunque sea un rollo el andar convirtiendo unidades, pero te obligan a declarar siempre el tipo de la variable.
De hecho, ayer mismo me tuve que pelear con Javascript, porque me estaba guardando un valor como string, y necesitaba que fuera un número... y era algo que ya había corregido anteriormente por otra cosa. Es más, la misma variable servía para guardar el valor tanto en string como en "numérico"... y la conversión la puede hacer automáticamente, en función de la operación que realices... tienes que tener un cuidado.

Iniciado por chipan

Nada te impide trabajar con punteros, salvo el hecho de que estás jugueteando con las direcciones de memoria. Si no cometes ningún error están muy bien, pero los humanos somos dados a cometer errores y los errores cuando estas toqueteando la memoria pueden tener consecuencias muy aleatorias y una trazabilidad un tanto difícil. Por mencionar algo que recuerdo de mis tiempos de estudiante, cuando para ahorrarte duplicar un array pasas un puntero a dicho array y decides avanzar por él sumando posiciones al valor del puntero y te sales de él sin darte cuenta, o cuando retornas un puntero y en lugar de acceder al valor que hay en esa dirección de memoria, tomas la dirección del puntero como valor, etc, etc.

Estaba preguntando que qué te impedía duplicar memoria usando punteros, igual que si pasas una variable por valor. Que no, nada te lo impide, pero es tontería, porque es esfuerzo doble.
A mi, lo que me traía de cabeza era tener que acordarme de recorrer el array al revés para ir borrando elementos, para evitar salirme de la lista con un bucle FOR. O peor, tener que ir con dos punteros para borrar un nodo, y reenlazar el nodo anterior con el siguiente. Un desastre cuando usabas listas doblemente enlazadas. Y ni mencionemos los punteros creadores y consumidores en sistemas asíncronos. El que haya visto algo de procesos y semáforos, sabe de qué hablo.
Pero puedes hacer cosas imposibles de otra forma, como un buffer circular, cuyo último valor es el anterior del primero, y que se usa mucho en el filtrado de señales.

**swapd0** · 18/10/2023, 15:33

Creo que hablais del cohete Ariane, el Challenger exploto por un problema con las juntas de los depositos o algo asi.

**chipan** · 18/10/2023, 15:51

Iniciado por Drumpi

No, no conozco esas normas, porque por suerte no me he visto aún en la tesitura de tener que programar un sistema tan limitado, tan crítico, o de tiempo real.
De todas formas, lo entiendo. En un SO tienes la ventaja de que el sistema te reserva un espacio de memoria, y vigila que no te salgas de él. Eso no existe en sistemas embebidos... bueno, no existía, cada vez son más los que usan un kernel Linux, o un BIOS (y no me refiero al Sistema Básico de Entrada y Salida, sino al micro Sistema Operativo para estos cacharros, que no recuerdo cuál era el acrónimo ^^U). Como digo, yo aprendí microcontroladores en ASM, y los que iban dos cursos por detrás usaron C, y creo que ya andan usando Pyton.

En fin, que sí, lo del Challenger, según nos explicaron, a groso modo, fue que hubo un desbordamiento de una variable, por usar un byte en lugar de un int o algo parecido. Y por eso siempre he preferido los lenguajes fuertemente tipados, aunque sea un rollo el andar convirtiendo unidades, pero te obligan a declarar siempre el tipo de la variable.
De hecho, ayer mismo me tuve que pelear con Javascript, porque me estaba guardando un valor como string, y necesitaba que fuera un número... y era algo que ya había corregido anteriormente por otra cosa. Es más, la misma variable servía para guardar el valor tanto en string como en "numérico"... y la conversión la puede hacer automáticamente, en función de la operación que realices... tienes que tener un cuidado.

Estaba preguntando que qué te impedía duplicar memoria usando punteros, igual que si pasas una variable por valor. Que no, nada te lo impide, pero es tontería, porque es esfuerzo doble.
A mi, lo que me traía de cabeza era tener que acordarme de recorrer el array al revés para ir borrando elementos, para evitar salirme de la lista con un bucle FOR. O peor, tener que ir con dos punteros para borrar un nodo, y reenlazar el nodo anterior con el siguiente. Un desastre cuando usabas listas doblemente enlazadas. Y ni mencionemos los punteros creadores y consumidores en sistemas asíncronos. El que haya visto algo de procesos y semáforos, sabe de qué hablo.
Pero puedes hacer cosas imposibles de otra forma, como un buffer circular, cuyo último valor es el anterior del primero, y que se usa mucho en el filtrado de señales.

Efectivamente, pero una de las funcionalidades más usadas de los punteros, como es acceder a una variable de otra función o de otra parte del programa, se ha simplificado mucho con los años con las referencias anidadas (no se si ese es el nombre oficial, me refiero a la típica manera de codificar en visual studio de acceder a variables de otra función poniendo el nombre de la función, un punto y el nombre de la variable, en plan "funcion2.variable1"), por lo que una de las mayores justificaciónes que tenían en un principio, que es la de no duplicar datos en memoria, ya no es válida hoy en día. Otra cosa es que esas referencias anidadas sean internamente punteros, pero el caso es que con esa sintaxis ahorras muchos quebraderos de cabeza y errores accidentales.

**josepzin** · 18/10/2023, 19:29

Iniciado por swapd0

Creo que hablais del cohete Ariane, el Challenger exploto por un problema con las juntas de los depositos o algo asi.

Ya me parecía, porque de los dos transbordadores accidentados uno fue por unas juntas que se congelaron (creo) y el otro fue por unas placas termicas que se desprendieron.

**Drumpi** · 18/10/2023, 20:03

Iniciado por swapd0

Creo que hablais del cohete Ariane, el Challenger exploto por un problema con las juntas de los depositos o algo asi.

Lo siento, pero es que no nos presentaron formalmente, por lo que no se me quedó su nombre en la cabeza

Iniciado por chipan

Efectivamente, pero una de las funcionalidades más usadas de los punteros, como es acceder a una variable de otra función o de otra parte del programa, se ha simplificado mucho con los años con las referencias anidadas (no se si ese es el nombre oficial, me refiero a la típica manera de codificar en visual studio de acceder a variables de otra función poniendo el nombre de la función, un punto y el nombre de la variable, en plan "funcion2.variable1"), por lo que una de las mayores justificaciónes que tenían en un principio, que es la de no duplicar datos en memoria, ya no es válida hoy en día. Otra cosa es que esas referencias anidadas sean internamente punteros, pero el caso es que con esa sintaxis ahorras muchos quebraderos de cabeza y errores accidentales.

Que yo sepa, el mayor uso de los punteros es el de referenciar a una zona de memoria que hemos reservado, y que vamos pasando de una función a la siguiente como parámetro, para no tener que duplicarla. O el paso por referencia, en lugar de por valor.
No sé a qué te refieres con "acceder a variables de otra función" en lenguajes que no sean Orientados a Objetos o de ejecución procedural. En C yo aprendí que los datos entre funciones o métodos siempre se pasan por parámetro (de nuevo, por valor o referencia) o devolviendo un valor, por lo que siempre tendremos o una variable de tipo x, o un puntero a una zona de memoria. A lo mejor son cosas mucho más avanzadas de las que yo vi, pero el acceso a una zona de memoria, sin tener una referencia, nunca ha sido, por lo que yo aprendí, buenas prácticas.
Por eso se crearon las clases, para ir pasando instancias de clases, o referencias estáticas, y que su "zona de memoria" sean sus atributos, y su acceso esté más controlado, ya sea mediante sus métodos o por sus funciones de acceso (get/set).
También están los punteros a funciones, pero eso ya quedó fuera de lo que aprendí, y aunque alguna vez me pareció útil, al final nunca lo usé. Creo que tiraba de directivas del precompilador, que jamás llegué a usar y temas de cadenas a funciones que nunca me gustaron, sobre todo, porque usar una string como un valor absoluto siempre me pareció una fuente de errores muy grandes (esto lo llegué a usar en Java, y una simple tilde o una mayúscula o un carácter en una codificación diferente y ya no sabía dónde tenía que ir).

**chipan** · 19/10/2023, 00:30

Iniciado por Drumpi

Lo siento, pero es que no nos presentaron formalmente, por lo que no se me quedó su nombre en la cabeza

Que yo sepa, el mayor uso de los punteros es el de referenciar a una zona de memoria que hemos reservado, y que vamos pasando de una función a la siguiente como parámetro, para no tener que duplicarla. O el paso por referencia, en lugar de por valor.
No sé a qué te refieres con "acceder a variables de otra función" en lenguajes que no sean Orientados a Objetos o de ejecución procedural. En C yo aprendí que los datos entre funciones o métodos siempre se pasan por parámetro (de nuevo, por valor o referencia) o devolviendo un valor, por lo que siempre tendremos o una variable de tipo x, o un puntero a una zona de memoria. A lo mejor son cosas mucho más avanzadas de las que yo vi, pero el acceso a una zona de memoria, sin tener una referencia, nunca ha sido, por lo que yo aprendí, buenas prácticas.
Por eso se crearon las clases, para ir pasando instancias de clases, o referencias estáticas, y que su "zona de memoria" sean sus atributos, y su acceso esté más controlado, ya sea mediante sus métodos o por sus funciones de acceso (get/set).
También están los punteros a funciones, pero eso ya quedó fuera de lo que aprendí, y aunque alguna vez me pareció útil, al final nunca lo usé. Creo que tiraba de directivas del precompilador, que jamás llegué a usar y temas de cadenas a funciones que nunca me gustaron, sobre todo, porque usar una string como un valor absoluto siempre me pareció una fuente de errores muy grandes (esto lo llegué a usar en Java, y una simple tilde o una mayúscula o un carácter en una codificación diferente y ya no sabía dónde tenía que ir).

Resumiendo, quería decir que una de las cosas que antes se hacía con punteros ahora se hace con referencias anidadas. Vamos, que en lugar de tener que andar pasando direcciones de memoria con los problemas que puede dar eso, ahora se hace de manera implícita accediendo directamente a variables de otras funciones poniendo el nombre de la función un punto y el de la variable. No se si me explico.

**josepzin** · 19/10/2023, 00:44

Usar variables... pfff estos programadores modernos.

**Drumpi** · 19/10/2023, 11:58

Iniciado por chipan

Resumiendo, quería decir que una de las cosas que antes se hacía con punteros ahora se hace con referencias anidadas. Vamos, que en lugar de tener que andar pasando direcciones de memoria con los problemas que puede dar eso, ahora se hace de manera implícita accediendo directamente a variables de otras funciones poniendo el nombre de la función un punto y el de la variable. No se si me explico.

Pues no, como no me pongas ejemplos de qué lenguajes estás hablando, yo pienso que hablas de C, y como no sean variables estáticas, una función, por sí sola, no tiene valores en sus variables, a no ser que sea una instancia, padre de la función que se está ejecutando en ese momento, y puede haber varias instancias (ejemplo: recursividad).
Como digo, en C# puedes hacer MiClase.campo1 siempre que campo1 sea estática, o bien instanciaMiClase.campo2, donde instanciaMiClase es de tipo MiClase, y campo2 es una variable public, internal o tenga implementada Get(). Y lo bueno de las clases es que puedes acceder a MiClase.campo3 que es private, siempre que lo hagas mediante un método public, que ya se encarga, por ejemplo, de verificar que los valores son válidos, que las condiciones lo permiten, o que se puede devolver su valor en el tipo que se necesite (por ejemplo, una string en el "culture" apropiado, es decir, con coma decimal en español, o con punto decimal en inglés).

Moderneces innecesarias para el programador de C de toda la vida, que ya sabe todo eso y toma sus propias medidas para evitar estos problemas

Y en el caso del que usa ASM, ya ni te cuento ¿Cultures? Da gracias de que te devuelve una serie de chars ASCII por la consola de comandos, que alguien ya redirigirá a un log de texto al ejecutar el binario.

Ten en cuenta una cosa (y así me lo enseñaron): cada función de C tiene dos zonas de memoria reservadas, la parte de código, que es compartida por todas las instancias de dicha función, y que es de sólo lectura, para la ejecución de comandos, y la parte de las variables, de la que se crea una copia por instancia, ya que "int cont" no vale lo mismo en miFuncion padre que en miFunción hija, o miFuncion que se ejecuta en el segundo core. Por eso decir "un puntero a una variable de una función" es muy ambiguo, tienes que haber pasado el puntero por parámetro, y asegurarte de que dicha zona de memoria no se ha liberado, porque podría haber sido machacada por otra instancia. Es el tipo de errores que eran usados por hackers para acceder a zonas de memoria del sistema, antes de que los SO limitasen el acceso a las direcciones reservadas para esa ejecución del programa. Aunque claro, estoy hablando de una época donde W95 no era más que un proyecto :P

**swapd0** · 19/10/2023, 19:55

Iniciado por Drumpi

Ten en cuenta una cosa (y así me lo enseñaron): cada función de C tiene dos zonas de memoria reservadas, la parte de código, que es compartida por todas las instancias de dicha función, y que es de sólo lectura, para la ejecución de comandos, y la parte de las variables, de la que se crea una copia por instancia, ya que "int cont" no vale lo mismo en miFuncion padre que en miFunción hija, o miFuncion que se ejecuta en el segundo core.

Las variables locales de una funcion se meten en la pila.

**Drumpi** · 20/10/2023, 12:02

Iniciado por swapd0

Las variables locales de una funcion se meten en la pila.

Cierto, perdón por mi error.
Lo cual no quita para que, si no hay instancia, no hay memoria en la pila :P

Al final, es una cuestión de preferencias, si prefieres la simplicidad de los punteros, la seguridad de las clases, o si eres un Máster del código que prefiere ensuciarse las manos hasta los codos, y aprovechar el HW al máximo. Lo que no entiendo son las guerras que se forman en torno a cada lenguaje, y por qué el lenguaje de los demás es siempre una aberración... Excepto Java, Java es el demonio, ineficiente, y todas las alternativas son siempre mejores