Tema Dividido. ¿ASM Vs C?

[maunix]

Menta, respecto a los macros, opino como carcass.  Todo depende "cómo" los uses.

Si los usarás como un simple ahorro de trabajo para evitar un "copy paste", entonces sí, es lo mismo usar un macro que copiar N veces las líneas que el macro contiene.

El punto está en saber cuando va un macro y cuando no.

Yo uso los macros para ahorrarme pasos:

Por ejemplo, si tengo este macro


    guardareeprom dato,posmemoria



En realidad dentro del macro, guardo el dato y la posición de memoria de destino en los registros adecuados para luego llamar a una subrutina que es la que me graba el dato en la eeprom.

Si lo hiciera copiando y pegando mi código sería "visualmente" mas extenso, de esta forma puedo grabar 10 bytes en eeprom con solo escribir 10 simples líneas.

La subrutina que graba el dato en sí, es única en todo el programa.

Si en el macro yo tengo toda la rutina de grabado en eeprom (que ocupa unos 30 o 40 bytes ya no recuerdo) entonces claro, por cada uso del macro tendría copiada la rutina completa.

[Darukur]

Se pudieron rescatar explicaciones muy buenas, pero entre unas y otras hay tanta cantidad de renglones al pedo...
Ponganse las pilas.. gasten mas tiempo en demostrar un punto sobre electronica que en decir lo buenas personas que son o como hay que comportarse en la vida.. (para eso vayan a la iglesia y hagan donaciones para los pibes del Africa). Esto es un foro de electronica.

Es verdad pero me imagino que es una autocritica tambien, ya que todos nos fuimos bastante por las ramas.
Ya del tema se hablo mucho, de mas y remás.
Claro esta cuando conviene usar C cuando assembler y cuando "C + assembler" , (como pensamos usar para el codec de MP3) u otras yerbas.

Le dejo el link http://www.todopic.com.ar/foros/index.php?topic=14639.0 para ayudar con el MP3.

[maunix]

Y con el tema de la humildad, la arrogancia.. etc etc.. me molesta bastante leer tanto sobre el tema y tan poco sobre electronica.
Que importa si alguien explica algo con arrogancia o con humildad o como se le ocurra, mientras que la explicacion este buena o por lo menos sea una opcion a tener en cuenta.
Creo que el 80% del hilo se expandio a temas sociales y a gente muy suceptible que se ofende facilmente y muy poco a lo que realmente importa:

Por mi parte asunto terminado, no soy susceptible de sentirme ofendido facilmente, tomo a todos como "amigos hasta que demuestren lo contrario" jejeje.

Solo me resta comentar que tal vez te confundas en que es solo un foro de electrónica, acá hay gente que participa , que se reune para hacer proyectos en común, que piensa, etc.  Es en ese marco donde a algunos les puede ofender si algun comentario va con arrogancia, es despectivo o sobervio.

En algun momento me he visto en esa situación, me lo hicieron saber y me acomodé porque me di cuenta de lo que te acabo de decir, que más allá de lo estrictamente técnico hay gente de por medio.

En los foros ingleses o americanos, como el de Microchip, las explicaciones son escuetas, secas, arrogantes, pero es porque ellos son muuuy diferentes a nosotros.  Si visitas con frecuencia su foro, tal vez nos veamos ahí también ya que a veces, cuando tengo tiempo, me gusta leer y participar.  Realmente se aprenden muchas cosas de lo estrictamente técnico. 

Saludos desde Córdoba

[maunix]

Resumo aquí mi opinión:

ASSEMBLER
Es ideal cuando la arquitectura es limitada, cuando se requiere precisión en los parámetros de tiempo. 

También es ideal cuando se trata de lidiar con señales (por ej, comparación y captura). 

Es muy directo y no hay una forma en C de hacerlo más simple.

También es imprescindible su uso cuando se quiere minimalizar una aplicación, exprimir al máximo un microcontrolador o agregarle a un sistema ya armado, alguna opción extra siendo que no se cuente con mucha memoria y/o capacidad de programa libre.




LENGUAJE C
Es ideal cuando el problema lógico excede a lo estrictamente del hardware, es decir cuando se deben tomar decisiones con operaciones lógicas de gran complejidad. 

También es ideal cuando se elabora algún algoritmo de control o se necesitan operaciones matemáticas complejas.

Es muy práctico, directo y eficiente cuando se lidia con procesos realmente complejos como por ejemplo un stack tcp/ip e implementación de protocolos de alto nivel.


LENGUAJE C y ASSEMBLER juntos

Cuando la complejidad lógica y de cálculo viene acompañada por requerimientos de precisión o ahorro de memoria en algún periférico, o cuando simplemente se quiera hacer un código en assembler porque se quiere ser bien directo al hardware.

Doy un ejemplo, en caso de requerirse usarts por software que no sean simultáneas, se puede recurrir al assembler para hacer las temporizaciones realmente precisas sobre todo cuando se lidia con baudeajes altos.

[Menta]

Gracias a todos me quedó super claro lo de las macros tanto en asm como es C (defines)

Hice la comunicación i2c básica de un 16f873 con una eeprom (la borraba toda, escribía una página completa, leía y sacaba valores al puerto b). En principio me ocupaba el 21% de la rom. 
Lo depuré un pocó y bajé a 11%. después fui al archivo incluido de la memoria   #include<2402.c>  y lo modifiqué, ya que no usaba las funciones que allí estaban y me quedó solo la iniciación del bus i2c. que la agregué a mi programa principal. Resultado: 5% de la rom. Y supongo que lo podre reducir un poco más...

PD: El compilador que uso es el PCWH de CCS. Me gusta, pero es el único que usé, no sé que tal será...

[PalitroqueZ]

Yo creo que temas como estos siempre se darán.

además yo pienso que la limitación de lenguajes de alto nivel (C, BASIC, etc) no está en el lenguaje en sí, sino en la limitación del hardware, con los micros de la familia 16F por ejemplo, con una velocidad de clock tan baja, lo óptimo siempre será trabajar en su lenguaje nativo, el ensamblador, y es lógico que por cada linea del C se lleve mas lineas en ASM, porque esa es la idea, escribir un código lo mas pequeño posible y fácil para el usuario.

si miran un programa bajo windows, a través de un debugger se daran cuenta de la diferencia de haberlo programado en asm, C, basic, etc y a medida que sube el nivel del lenguaje, verán cantidades de lineas que son redundantes y que no hacen nada, pero con las velocidades de los procesadores que existen hoy en dia, es fáctible ese programa.


la utopia de utilizar un lenguaje de alto nivel usando PIC, es que estos PIC sean más veloces ó por menos tengan un hardware optimizado para ese lenguaje (creo que en los 18F lo traen, pero no estoy seguro).

otro ejemplo práctico son las calculadoras HP48 (que por cierto me trae buenos recuerdos, je je), si hacias un programa en su lenguaje RPL, corría un poco mas lento que si lo hacias usando su set de instrucciones en ensamblador, y verdad que era un diablo en cuanto velocidad, pero el programa era engorroso escribirlo y facilmente te pierdes entre tantas lineas.

bueno este era un pequeño comentario que les queria hacer.

Salu2

[maunix]

la utopia de utilizar un lenguaje de alto nivel usando PIC, es que estos PIC sean más veloces ó por menos tengan un hardware optimizado para ese lenguaje (creo que en los 18F lo traen, pero no estoy seguro).

Sí, los 18F tienen arquitectura pensada para optimizar el desempeño de un compilador C.  Tal vez te pasaste algunos posts por alto, pero se comentó esto.

Es importante aclarar que un lenguaje compilado nunca será más eficiente que trabajar en ensamblador. 

El que un micro tenga arquitectura optimizada para el uso de un compilador en C hace que el código generado sea "casi como si fuese" hecho en assembler. 

Le facilita la tarea al compilador, pero no significa que sea más eficiente que el assembler, de hecho siempre todo termina siendo código máquina el cual tiene una correspondencia directa y unívoca con el assembler.

Hay muchos casos en que el código generado es idéntico al que hubieramos hecho si nos hubieramos enfocado directamente en codificarlo en assembler, he ahí la ventaja! 

Además cuando los conceptos se hacen más complejos y el nivel de abstracción aumenta, el assembler es directamente impracticable. 

Saludos

[Darukur]

El tema es simple.
El compilador siempre va a tener presente los casos, que se puede usar y como de la mejor manera posible.
Tal vez no de la manera mas eficiente que nosotros esperamos, el debe pensar en otros detalles y al fin de cuentas es solo un programa.
Uno para generar assembler de este nivel debe estar muy empapado en el tema, pero si es ese el caso va a ser mejor tu codigo que el del compilador.
Es como en la epoca de la facu. Cuando terminaste de ver una materia seguramente la dominabas a full y pasas por arriba a la compu, cuando usas los conceptos despues de 3 años seguro que vas a tener que releer y va a tardar mas tiempo.
El compilador siempre está como al momento de teminar la materia.

[Zaphyrus]

Coincido, pero el compilador no tiene el conocimiento , la experiencia y los conceptos que acarreas con los años. No es un sistema experto.
Pero eso sí hay compiladores que generan un muy buen asm incluso mejor que lo que uno puede hacer. Como ejemplo el compilador de Intel para micros Intel  aunque no tenga nada que ver con los microcontroladores.

Salutes.

Martín

[Mazinger_bcn]

Hola compañeros,
Yo empece a programar los PIC en assembler porque ya habia programado este lenguaje en ordenadores de 8 bits como el zx81, Spectrum etc. y me era más facil aprender las instrucciones del PIC en asm que empezar a aprender C, ademas la mayoria de libros escritos para los PICs aquí en España estaban orientados para la programación en assembler, aunque me gustaria aprender C, ya que cuando tienes un programa con bastantes líneas te vuelves loco y siempre acabas tirando de aspirina, je,je!! ¿Sabeis si hay algún libro que este bien publicado en España sobre la programación de Pics en C ? Hace bastante tiempo que no paso por una libreria, je, je.

Un saludo a todos,
Esteban.

[xocas]

hola

perdonar porque mi opinion en este hilo tal vez este de mas ya que yo no programo ni en assembler ni en c (aunque estoy tratando con este ultimo). tambien es bastante posible que esto vaya un tanto desordenado, lo voy escribiendo segun sale de mi cabeza...

1.- llevo trabajando en informatica desde el año 83, (he de decir que entonces la informacion era minima e internet no existia). como mi commodore 64 traia un 6502 trate de aprender ensamblador para ese micro y sacarle todo el provecho posible. pague por dos libros (en ingles) un precio que aun hoy me averguenza. cuando pase al pc y su gama 8081 (si no recuerdo mal) comprendi que de seguir por ese camino acabaria loco y me dije: colega el ensamblador no es para ti...
en todos estos años he conocido a muchos programadores, algunos muy buenos y a otros mediocres, algunos con mentalidad de programador y a otros que no. entre aquellos que tenian mentalidad de programador he de decir que tenian un sistema de trabajo similar al de carcass y seguro que al de muchos otros de vosotros: creaban rutinas y rutinas que posteriormente utilizaban y/o adaptaban a otros programas.
yo soy de los que no se consideran un buen programador en ciertos lenguajes aunque parece ser que si lo soy en otros. me aclaro: no me creo capaz de hacer un buen programa en assembler, aunque actualmente gestiono sistemas de seguridad informaticos y la programacion de grandes bases de datos en sql (bueno, desde hace dos años estoy de baja debido a un accidente)
¿sabeis la suerte que teneis quienes pasasteis por una universidad? otros nos lo hemos tenido que currar a pulso en la biblioteca de una pequeña ciudad...

2.- en todos estos años de informatica hice un inciso para dedicarme a lo que de veras me gusta que es la fotografia. en compañia de otro amigo monte un laboratorio orientado exclusivamente a profesionales. solicitamos a todos los fotografos de renombre que nos enviaran unas fotos para comprobar nuestra calidad y en un 90 por ciento se nos dijo que eramos los mejores de la region, pero nadie nos encargaba trabajos posteriormente. el motivo: en fotografia calidad y tiempo son incompatibles y ellos querian las cosas para ya. con esto quiero defender la tesis de quienes entienden que en ocasiones (en muchas) el tiempo es el factor mas importante. a los dos años cerramos.

3.- considero que mas importante que el lenguaje utilizado es el proyecto en si. ¿funciona? ¿lo hace tal como se espera? ¿esta hecho en assembler o en c? hablando a nivel profesional creo que cada caso requeriria un estudio para determinarlo. en el mundillo de la fotografia he conocido fotografos bastante engreidos y con grandes medios a quienes no le he visto jamas una buena foto y a otros con humildad y sin apenas medios excelentes trabajos.

4.- carcass, coincido contigo en el punto de que no importa ser mas o menos educado para ciertas cosas pero veras... este foro va de otra cosa, aqui yo puedo sentir que maunix y otros como el que estan a miles de kilometros sean mis amigos, y cuando tengo una consulta siempre estan ahi. a raiz de mi accidente tengo que tratar con un medico que es un despota, la primera vez me grito y la segunda vez me grito y le grite, desde entonces me trata con educacion. parece que mi postura fue efectiva porque el sigue siendo un despota y las mujeres salen llorando de su consulta. falta decir que el tipo es un buen profesional pero no por eso se le pueden consentir ciertas cosas. te aseguro que si cuando hace casi un año hice mi primera consulta me dieran a entender que usar pbp era de vagos lo habria dejado al momento, pero no fue asi y nunca lo ha sido

5.- programo en pbp y estoy comenzando con c. me encantaria conocer c en condiciones y como no, tambien assembler. aparte de la ayuda de este foro y de cosas que encuentro en internet todo me lo 'curro' yo por tanto no me considero para nada un vago. a modo de anecdota (una mas) hace unos dias hice un pequeño pograma en pbp para una amiga y para resolver una situacion solamente se me ocurria algo que yo mismo sabia que era una chapuza pero al final fue asi. dias despues comente el tema con un amigo que programa en assembler y cuando me comento como se hacia vi que facil habria sido y que la chapuza era mayor de lo que yo creia.

6.- para terminar, y perdon por tanto rollo, borrare este post en unos dias ya que no hace referencia a lo que creo es realmente importante

saludos

[Zaphyrus]

Hola Xocas06, no veo la necesidad de que borres el post. Ya nos hemos ido por las ramas bastante veces y creo que cada uno debe dar su opinión de lo que le parece. Como cada opinión es personal y puede diferir de la de otra persona también me parece justo respetarla y escucharla.
Así que voto para que no la borres

Saludos.

Martín

[MGLSOFT]

Menta, respecto a los macros, opino como carcass.  Todo depende "cómo" los uses.

Si los usarás como un simple ahorro de trabajo para evitar un "copy paste", entonces sí, es lo mismo usar un macro que copiar N veces las líneas que el macro contiene.

El punto está en saber cuando va un macro y cuando no.

Yo uso los macros para ahorrarme pasos:

Por ejemplo, si tengo este macro


    guardareeprom dato,posmemoria



En realidad dentro del macro, guardo el dato y la posición de memoria de destino en los registros adecuados para luego llamar a una subrutina que es la que me graba el dato en la eeprom.

Si lo hiciera copiando y pegando mi código sería "visualmente" mas extenso, de esta forma puedo grabar 10 bytes en eeprom con solo escribir 10 simples líneas.

La subrutina que graba el dato en sí, es única en todo el programa.

Si en el macro yo tengo toda la rutina de grabado en eeprom (que ocupa unos 30 o 40 bytes ya no recuerdo) entonces claro, por cada uso del macro tendría copiada la rutina completa.

Los Macros en Assembler pueden compararse con funciones creadas para realizar una accion, sean propias del compilador de C o creadas por el programador.

Tomo el ejemplo de Maunix en cuanto precisamente a la macro del ejemplo:

    guardareeprom dato,posmemoria


Esta es reemplazada en C por una instruccion propia el compilador:

    write_eeprom (dato,posmemoria);


Ambas haran lo mismo, con pasaje de parametros (dato a guardar de 1 byte y direccion de la EEPROM donde guardarlo).

Ventajas?
En C viene escrita y probada, mientras en Assembler habra cien formas de hacerla diferente, a gusto del programador.

Desventajas?
En Assembler (si el programador optimiza bien y elige las instrucciones adecuadas) optimizara el programa y acelerara la ejecucion, mientras en C no tendremos el control real de la optimizacion.
(Aqui cometo pecado ya que la instruccion de grabacion de EEPROM siempre tendra un tiempo similar para cualquier lenguaje, pero el ejemplo sirve)
En Assembler tendremos que reescribirla para cambiar de un micro a otro, mientras el C realizara el cambio necesario de direcciones, control de bits de estado y de paginacion y otros temas por nosotros.

Pero aqui esta la mayor ventaja del uso de macros o funciones!!!
EL MANTENIMIENTO DE LA APLICACION!!
SI, ese es el punto fundamental del tema, en cualquiera de los dos cuando hay que hacer un cambio solo SE RETOCA el codigo de la Macro o de la funcion!!!

Alli esta la magia del programador!!
No se trata de jactarse en cuantas lineas de codigo escribes, ni cuanta optimizacion pudiste realizar tampoco.
Si tu codigo lo lee otro programador o tu mismo al termino de un año y no se entiende la idea sin tener la documentacion en la mano, nada de lo que hiciste sirve !!!

Entonces, cual sera en ese momento la diferencia entre que este escrito en C o Assembler ???

[Zaphyrus]

Hace mucho ya desde que empezó este debate pero recién encontré este artículo por Jack Ganssle que es el creador del sistema operativo uCOS y del excelente libro MicroC/OS-II - The Real-Time Kernel:

Is Assembly Language Obsolete?

En resumen dice que los mejores desarrolladores de software empotrado/embebido deben saber como funciona una conputadora o microcontrolador en detalle. Por lo tanto debe saber asm.

Saludos

[Menta]

En resumen dice que los mejores desarrolladores de software empotrado/embebido deben saber como funciona una conputadora o microcontrolador en detalle. Por lo tanto debe saber asm.

Es verdad, deben saberlo, pero usan C. 
Asembler para mí no significa un lenguaje de programación, es el modo en que funciona un microprocesador
al programarlo le vas a decir qué tiene que hacer... y cómo hacerlo según sus recursos. Con un compilador se complica el decirle el cómo...
ahora bien, se puede obrar de varias formas en la tarea de decirle al micro lo que debe hacer:

■Sabiendo cómo funciona el micro, qué puede hacer y qué no, y sabiendo cómo lo hace, como maneja sus registros y sus banderas pero ignorando las rutinas de nuestro compilador (C, basic o el que fuere)

■Se pueden conocer a fondo el compilador, saber las mil y una formas de configurar una función, pero no saber que hace el micro con esos códigos, cómo interpretará esas rutinas.

■Se puede saber de pe a pa las artimañas del compilador y tener un conocimiento completo sobre el harware, bit x bit.

Seguramente todos coincidimos en que este último caso es el más óptimo para desarrollar un firmware, pero la verdad es que pienso que en los 3 casos se puede llegar a un resultado funcional para la mayoría de las aplicaciones.
*El primero debe solventar quizas las falencias de su compilador en interpretar lo que realmente se quiere hacer o mejordicho como se quiere que se haga, pero puede meter mano en bajo nivel y solucionar cualquier problema.
*El segundo, está sujeto al buen funcionamiento y eficiencia del compilador, será tan eficiente como lo sea este último.

En fin todos coincidimos en qué depende de la aplicación, en lenguajes de más alto nivel se simplifican tareas tediosas y se acortan tiempos de desarrollo. Siempre va a haber cosas para hacer que no van a estar en las funciones del compilador y hay que meter mano e ingenio bit a bit pensando en asm. pero si haces todo en asm no podés competir con ninguno de los 3 casos anteriores en la mayoría de las aplicaciones.