ASM, basic , C y otros

[pandacba]

Es como en todos los sistemas, hay que ver hasta donde quieres llegar y que quieres hacer, para ciertas cosas el asambler es muy tedioso, pero para otras es imprescindible, conocer el assembler te permitira utilzar la capacidad del micro al 100% pero no en todas las ocaciones se necesita eso.
Para hacer un paralelo, por ejemplo el asemblerl de los micro Intel de la gama X86, te imaginas escribir determinados programas isntegramente en assembler? por ejemplo el sistema operativo? ojo no quiere decir que no se use, hay muchas subrutinas embebidas en assembler pero el resto esta escrito en lenguaje C
Es bueno conocer el asembler y alguno lenguaje de alto nivel, podras ser más flexible a la hora de programar, en mi caso que suelo utilzar rutinas de retardo en asembler, porque es algo que se maneja mejor en asembler que por ejemplo en lenguajes basic, no breves retardos, retardos prolongados, tengo unas subrutinas a las cuales le paso el parámetro necesario para obtener el retardo que deseo y resulta simple y muy efectivo, eso por poner algún ejemplo
Imagina en su momento cuando habia varios lenguajes C, par los x86, estaba borland, watcon, microsoft, pero tambien estaba el pascal, que luego fue Delphi y habia que ver cual se adecuaba mas a las necesidades, al comienzo probar uno u otro si se tenia tal posibilidad y adoptar uno
Aqui es exactamente igual, todo requiere tiempo y mucha paciencia, leer mucho devorarse cuanto documento exista sobre el miciro que queremos utilzar interactuar con otros programadores

Imagina que hoy existen otras posibilidades con otros lenguajes para estos micros populares, pero para otros microcontroladoes como el 8051, los micros de motorola, y lo de otros fabricantes solo habia assembler hasta el popular Z80 con el cual muchos se iniciaron no habia otra cosa que assembler para el 6505 de Rockwell no habia otra cosa que assembler, para la serie 05 hata la 011 motorola o por ejemplo los micros de Rubit que son muy buenos e interesantes, los micro de texas, que incluso te proveen una placa de desrrollo a costo reducido y mucha info pero se programan en assembler

 

[cosmefulanito04]

Yo recomiendo C para usarlo en la mayoría del proyecto que se realice y usar assembler en rutinas muy específicas que requieren un tiempo de ejecución crítico.

 

[Alcocer Garcia Felix Davi]

Me han convencido con sus respuestas. Uso el Microcode con PICBasic. Es muy sencillo.
Existen mikroBasic Pro y muchos otros compiladores.

Estoy empezando con el ensamblador, además en paralelo empezado con el C, pero quisiera saber por qué existe una gran gama de compiladores en C como C18, C8, C16, HI-TECH y mikroC.

¿Quisiera saber un poco sobre en que casos usar mikroC y PIC C Compiler?

Gracias.

 

[cosmefulanito04]

Un compilador de C, no es más que un traductor assembler y a la vez un traductor en código de máquina.

Tenés distintos compiladores según el hardware asociado, un hardware distinto es muy probable que implique instrucciones en assembler distintas, por lo tanto necesitará un "traductor" específico para ese hardware.

Por otro lado, podés tener distintos compiladores para un mismo hardware (ej. x86, 8051, etc), pero c/compilador "traduce" de formas distintas, lo que implica que muchas veces un código en C puede tener muchísimas soluciones en assembler, es por eso que en rutinas muy críticas es mejor tomar el control del hardware uno mismo y evitar tiempos de pérdidas por una mala "traducción" o incluso aprovechar ciertos recursos del hardware que al "traductor" se le escapan.

Mí recomendación, de assembler aprendé lo necesario para poder realizar operaciones básicas, trabajar bien con los registros, acceder a la memoria mediante punteros, realizar un loop y trabajar con funciones/rutinas mediante el uso de CALL (o la variante según el hardware).

 

[papirrin]

Estoy empezando con el asembler , ademas en paralelo empezado con el C pero quisiera saber por q existe una gran gama de compiladores en C como C18 C8 C16 HItech microkaC . Quisiera saber un poco sobre en que casos usar MIcrokC y picccompiler gracias .

a mi me gusta el CCS, yo te recomiento que empieces con ese que es muy sencillo, despues cambias a cualquier otro que en si las instrucciones son muuuuy similares.

hay varios compiladores porque son diferentes estructuras de los pic o sea el de 8 bits es diferente al de 16 0 32 bits.

y aclara si lo que buscas es para microcontroladores PICs de microchip porque ya te estan comentando de otros como el x86 8051 z80 etc. que son totalmente diferentes

 

[Meta]

Hola:

Para hacer tablas de la verdad igual a un 74HCxx o modificado a tu manera por poner un ejemplo, uso PIC con ASM.

Para proyectos muy pequeños como PIC tipo PIC12F509, PIC12F629 se suele usar ASM.

Proyectos grandes prefiero C, más portabilidad y depaso, te ahorras muchísimo tiempo. El C puedes añadirle bloques asm para mayor rendimiento en ciertas partes del código como los temporizadores y tiempos justo a raja tabla que en C no se puede hacer con los PI, es decir, precisión extrema, por poner ejemplos.

Por lo que veo, el C/C++ de MPLAB X con el C8 para los PIC18F es lo que recomiendo. X32 para los PIC32.

Hi-Tech está obsoleto y solo permite PIC de 18F.

En cuanto a CSS es muy bueno, pero muchas veces se tarda en actualizar algunas funciones de ciertos PIC, sobre todo los nuevos hasta un año y no lo puedes usar, a parte que no usa C estandar. Tienes que recurrir incrustar bloques en ASM dentro de C para modificar ciertos registros que en C no puedes porque todavía CSS no está preparado para ello.

Por eso recomiendo el oficial de Microchip como e lMPLAB X con su compilador de C oficial para los PIC de 8, 16 y 32 bits. Es de lo mejor.

Se ha hablado de programar ARM con el nuevo moderno lenguaje C# y hay proyectos sobre ello.

En C trapicheado de Arduino se usa bastante cada vez más.

En resumen.

C en general, lenguaje de alto nivel, por su mayor tiempo en hacer proyectos, portabilidad, modificacoines o actualizaciones de código rápido y otras muchas ventajas.

Saludos.

 

[cosmefulanito04]

Si no hay dependencia del tiempo, si algo es fácil en assembler, en C todavía es más fácil, salvo excepciones, como instrucciones raras que en C cuestan digerir.

Sobre lenguajes de alto nivel como C#, cero control de lo que pasa. Yo uso Java en un ARM bajo Linux y la verdad ni idea de lo que pasa, lo uso nada mas como interfaz de usuario, pero contra el gcc en procesamiento no le llega ni a los talones.

 

[Meta]

Los lenguajes de alto nivel, precisamente es para no preocupar la programador de lo que pasa.

Al hacer una división en asm con un PIC. Tienes que preocuparte de poner hasta el en resto, en una posición de memoria, ejjejejje.

Saludos.

 

[cosmefulanito04]

En una PC eso está muy bien, en un sistema embebido... mmmm

Hay que tener un equilibrio, ni exagerar y hacer todo en assembler, ni perder el control absoluto de lo que pasa, salvo que realmente no importe y se necesite implementar algo "bonito" para el usuario.

 

[Miembro eliminado 356005]

Por ejemplo, el ensamblador de los micro Intel de la gama X86, ¿te imaginas escribir determinados programas íntegramente en ensamblador, por ejemplo el sistema operativo?

Yo no me lo imagino. Existe: MenuetOS (resumen en WIkipedia) Precisamente hoy ha salido la última actualización.

• Programación en 32 y 64 Bits en FASM
• GUI con resoluciones de hasta 1280x1024, en 16 millones de colores
• IDE: Editor/Macro Assembler para aplicaciones
• TCP/IP
• Aplicaciones de red incluidos servidores FTP/HTTP/MP3
• Forma libre para las ventanas de aplicaciones
• Reproductor de vídeo
• Reproductor de DVD/MP3
• Cliente HTTP
• Soporte para DVB-T
• Soporte para USB 2.0
• Soporte Multiprocesador, multitarea, multihilo

Y todo esto cabe en un disquete de 1.44 MB

No es el único. Existe un derivado, llamado KolibriOS, que arranca en menos de 5 segundos

 

[Saint_]

Hace tiempo el la facultad en una materia programaros en asm para el x86 manejo de pantalla (modo testo y gráfico), interrupciones del bios y dos...periféricos de entada como teclados, puertos paralelo, serie y mas...pero un sistema operativo en asm... Señores me quito el sombrero ante eso.

 

[cosmefulanito04]

Gracias a que Linux mostró el camino de la independencia de la arquitectura con C, hoy podemos usarlo en muchos desarrollos.

Hasta tal punto se independizó, que directamente descartó el uso del scheduler (administrador de tareas) que tienen los x86 por hard, si bien se pierde la ventaja del hard, se gana mucha compatibilidad.

 

[Dr. Zoidberg]

Como siempre, lo verdaderamente inteligente no es convertirse en un ayatollah del C o del ASM, ni comenzar a buscar justificaciones esotericas que ocurren una vez cada 10 millones de años para justificar el uso del ASM sobre el C.
Lo inteligente, y por supuesto MUY DIFICIL, es dominar ambos lenguajes y balancear - si resulta necesario - su aplicacion en la solucion de un problema REAL... y en los problemas reales no participa el ego personal de decir "soy mas macho por que programo en ASM y exprimo los recursos del micro" ...y no participa por que hay que considerar las hs-hombre invertidas en el desarrollo en asm y el tiempo de salida al mercado usando uno u otro o la mezcla de ambos lenguajes.
Ahora bien... si algunp cree que tiene la "verdad" opinando desde un punto de vista del aficcionado o del hobbista, yo le recomiendo seriamente que se guarde la opinion hasta que conozca la realidad de los proyectos serios, a gran escala y en entornos muy competitivos.

PD: lo de exprimir al micro se da mediante mediciones en el contexto dr.la aplicacion y no mediante opiniones polarizadas que solo buscan mostrar la realidad que le interesa a cada uno.

 

[Meta]

Hola:

¿Alguien exprime en asm su microprocesador de un PC?


Saludos.

 

[papirrin]

Busca proyectos con el procesador 8086 o similares,seguramente hay varias decenas., es muy comun que muchos usen tecnologias antiguas para proyectos recientes porque son mas accesibles.

Tu pregunta tiene cientos de interpretaciones, es mejor si eres mas especifico.

 

[cosmefulanito04]

Hola:

¿Alguien exprime en asm su microprocesador de un PC?


Saludos.

En procesamiento de imágenes/video, realmente vale la pena su uso puntual, ya que tenés instrucciones muy preparadas para eso. Yo lo utilicé y realmente se notaba la diferencia, ahora bien, hablo de una rutina, es decir una simple función llamada desde C.

Sin embargo, guste o no, con los uP que van sacando día tras día, muchas veces ni se nota la diferencia, a pesar de que si existen, pero deja de ser práctica su optimización.

Por ej. hablando de los ARM como el último Raspberry, es notable la diferencia del uP entre la versión 1 y la 2.

 

[Dr. Zoidberg]

Sin embargo, guste o no, con los uP que van sacando día tras día, muchas veces ni se nota la diferencia, a pesar de que si existen, pero deja de ser práctica su optimización.

Cosme:
El problema es que no existe tal "optimizacion" !!!!
Absolutamente todos los intentos de optimizacion a los que se hace referencia son "en tamaño" por que son faciles de hacer y verificar, pero nunca veo - en este nivel - optimizacion para velocidad de ejecucion... y el porque es simple: para hacerlas.hay que conocer las mismas tecnicas que conocen los que diseñan compiladores y perfiladores. Asi que si alguien tiene una app real time jugada en tiempo, probablemente intente - al boleo - reescribir codigo en assembler e lugar de analizar las opciones del compilador. Y ni te digo si una optimizacion atenta contra la otra...
La unica solucion es SABER... o mandar fruta en su defecto...

 

[cosmefulanito04]

Cosme:
El problema es que no existe tal "optimizacion" !!!!
Absolutamente todos los intentos de optimizacion a los que se hace referencia son "en tamaño" por que son faciles de hacer y verificar, pero nunca veo - en este nivel - optimizacion para velocidad de ejecucion... y el porque es simple: para hacerlas.hay que conocer las mismas tecnicas que conocen los que diseñan compiladores y perfiladores. Asi que si alguien tiene una app real time jugada en tiempo, probablemente intente - al boleo - reescribir codigo en assembler e lugar de analizar las opciones del compilador. Y ni te digo si una optimizacion atenta contra la otra...
La unica solucion es SABER... o mandar fruta en su defecto...

Es cierto que a la hora de compilar en C tenés que saber configurar muy bien los flags, cosa que a veces se me escapa.

Pero también es cierto, que los compiladores, por más bien que los configures y les limites su rango de acción, perfectos no son y eso lo he visto con ARM y sus instrucciones Neon (hablo del querido GCC). En C no tenía forma de hacer un rotador de imagen en tiempo real que requiere hacer interpolación lineal y la única forma de resolverlo fué usando assembler (no es algo que me guste mucho, pero no había otra).

En x86, también he usado las instrucciones SIMD (parecidos al Neon, en realidad es lo contrario, el Neon es un imitación de ese tipo de instrucciones) y los resultados que podés obtener son muy buenos.

 

[Dr. Zoidberg]

Pero eso no es una optimizacion, eso es usar un recurso muy particular de una familia de micros para conseguir algo que sin usarlo es dificil o imposible de lograr. De hecho, eso deberia ser parte de una biblioteca de aplicacion especifica, de procesamiento de imagenes en tu caso, pero no tiene nada que ver con una optimizacion, por que el compilador no puede adivinar en que vas a usar las instrucciones especificas del micro.
No se si soy claro...

 

[cosmefulanito04]

Pero eso no es una optimizacion, eso es usar un recurso muy particular de una familia de micros para conseguir algo que sin usarlo es dificil o imposible de lograr. De hecho, eso deberia ser parte de una biblioteca de aplicacion especifica, de procesamiento de imagenes en tu caso, pero no tiene nada que ver con una optimizacion, por que el compilador no puede adivinar en que vas a usar las instrucciones especificas del micro.
No se si soy claro...

Para mí si es una optimización, tengo dos formas de llegar y una resulta mucho más rápido que la otra, sin dudas esa última está optimizada, no importa como.

De hecho hay funciones intrínsecas en gcc para suplir esas instrucciones y por lo que averigüe no son del todo útiles, aunque admito que no llegué a probarlas, decidí usarlas directamente en assembler.

No quiero hacer offtopic, pero en este post dejé un ejemplo de eso en una rutina bastante sencilla en C, assembler básico y usando las instrucciones especiales:

https://www.forosdeelectronica.com/posts/1000184/

Admito que la "forma" de medir el tiempo deja bastante que desear, lo ideal sería usando un contador de intrucciones en assembler, cosa que de hecho existe, pero lamentablemente no pude utilizarla con éxito.

Edito:

Y si, usé un puntero void.