La computadora mas antigua del mundo será reiniciada

[Dr. Zoidberg]

bueno ideas son ideas , personalmente no me gusta usar casi nada que allan echo otros , y los lenguajes de alto nivel, son ni mas ni menos que eso

Ahhh...buenooo....
Con ese criterio podrías diseñar y usar tu propio PIC por que Microchip ya inventó los otros...

(sos programador?)

Entre otras varias cosas, si...un poquito mas que eso...

 

[Eduardo]

...Sinceramente no entiendo por que imaginan que pueden escribir mejores programas en assembler que lo que podría traducir un compilador C ajustado por especialistas y con años de desarrollo encima...

Eso no es cierto, los compiladores de C generan un código lo suficientemente bueno como para que no valga la pena usar assembler, pero los "especialistas y con años de desarrollo encima" se calientan hasta ahí.

Un compilador de C te genera un buen código en las operaciones arimético-lógicas, en las comparaciones/switch, te saca el código muerto, te optimiza el codigo repetido en los bucles, te optimiza la inicialización de variables...

Se puede pensar: Que más se puede pedir? --> Que terminen la optimización.
El código generado necesita siempre una pasada más. No tengo idea por qué, pero no la hacen o la hacen para el orto.


Unas optimizaciones son "limpiar" el código escrito por nosotros. Es decir, instrucciones redundantes que se dejan por una mejor legibilidad o porque se está sacando diferentes variantes con mínimas modificaciones del fuente.
Es decir, porciones sueltas que deberíamos haber corregido nosotros son "limpiadas" en lo generado.

Como ejemplo (con CCS) :

- Si hay una rutina que nunca es llamada, el compilador debe eliminarla del código si se activa la optimización. --> Pero esté activada o no, la elimina igual.

- Si hay una variable local que se asigna y no se usa, el compilador debe eliminarla --> No la elimina pero te avisa .

- Si una variable local se usa inútilmente como registro intermedio --> el compilador debe corregirlo.
Es decir, si tengo

void test(){
int8 aux8 ;
    aux8 = Var1 ;
    Var2 = aux8 ;
}

debería generarse directamente el código correpondiente a Var2=Var1.
Otros compiladores lo hacen, CCS no.



Las otras optimizaciones son relativas al código generado, en CCS no encuentro mayores objeciones salvo que le falta una pasada.

Durante operaciones aritméticas casi siempre es necesario la creación de variables auxiliares, pero después es necesario un análisis mas para eliminar las que no hacen falta.

Si tengo algo así :

A16 &= C8 | B16

con A16,B16 de 16 bit y C8 de 8 bit
CCS me genera esto (#opt 9):

  MOVF   C8,W      
  IORWF  B16_low,W      
  MOVWF  Aux8       <<--
  MOVF   Aux8,W     <<-- WTF !
  ANDWF  A16_low,F      
  MOVF   B16_high,W
  ANDWF  A16_high,F

Las direcciones de las variables las reemplacé por el nombre por legibilidad
Se está usando inútilmente una variable auxiliar, si se suprimen esas dos líneas anda igual


Por suerte, esos defectos solamente puede importar corregirlos en un servicio de interrupción, y solamente si se trata de un servicio de alta velocidad donde interesa que dure el menor tiempo posible.

No se por qué, pero la asignación inútil de variables auxiliares es un pifio bastante común. Será difícil de analizar
El único compilador que pude verificar que optimizaba de verdad es el de Borland version 4, pero solamente en 32bit. Tanto las anteriores como las posteriores nada que ver.

 

[diego_z]

hola , ¿ donde aprendiste C ?

tenes algun libro o apunte para orientarme ???
tenes algo en la compu. para pasarme o colgarlo aqui ???

saludos y gracias

aca https://www.forosdeelectronica.com/f24/ tene un monton de ejemplos y manuales para orientarte y aprender c , y aca https://www.forosdeelectronica.com/f24/ccs-c-programas-hechos-mplab-proyecto-completo-20784/ unos ejemplos muy buenos si no te gusta el entorno de ccs , tambien este http://www.ucontrol.com.ar/forosmf/programacion-en-c/ o este http://www.todopic.com.ar/foros/index.php?board=4.0 muy bueno tambien,

ezaballa , no me interesa diseñar mi pic ni discutir con nadie , tengo mi punto de vista y ni vos ni nadie me lo va a cambiar , es por eso no que no me gusta mucho entrar y dar mi opinion , todos opinan distinto y piensan que por ir incrementando el contador de mensajes saben mas que otros , me parece perfecto que brinden su opinion y apoyo a los que menos " SABEMOS " pero no quiere decir que debamos acatarnos a sus opiniones y consejos , aunque esto me cueste el baneo doy mi opinion tambien

 

[Dr. Zoidberg]

ezaballa , no me interesa diseñar mi pic ni discutir con nadie , tengo mi punto de vista y ni vos ni nadie me lo va a cambiar , es por eso no que no me gusta mucho entrar y dar mi opinion , todos opinan distinto y piensan que por ir incrementando el contador de mensajes saben mas que otros , me parece perfecto que brinden su opinion y apoyo a los que menos " SABEMOS " pero no quiere decir que debamos acatarnos a sus opiniones y consejos , aunque esto me cueste el baneo doy mi opinion tambien

1- No me interesa cambiar tu punto de vista.
2- NO me importa el contador de mensajes (ni sé por cuanto vá).
3- No creo saber mas o menos que vos, ni me importa conocerlo...sobre todo por que no dás ningún argumento válido que respalde tu posición.
4- No tenés que acatar mi opinión ni mucho menos. Es una OPINION, igual que la tuya...pero con algo de respaldo.
5- No te dí ningún consejo.

En resumen: Si vos crees que tenés que programar en assembler, pues es una decisión y un problema tuyo. Si vos creés que sos productivo trabajando en assembler, pues seguilo haciendo.
Pero que te queda claro: Este es un foro técnico, donde las opiniones se respaldan con pruebas tangibles. Vos no dás ninguna prueba y además te declarás caliente cuando rebaten tus argumentos...sin contar que no te gusta participar por que todos opinan diferente ...creo que vas a tener que conversar solo, por que es la unica forma que te pongas de acuerdo en algo...

 

[diego_z]

yo caliente ?? jua jua ahi si que me rei ,por favor indicame donde, lee lo que dice el mensaje de un buen amigo de otro foro ( abajo el cuadradito )



e aqui el tipico argentino, es por eso que en el mundo mucho no nos quieren

me canse

 

[Dr. Zoidberg]

yo caliente ?? jua jua ahi si que me rei ,por favor indicame donde, lee lo que dice el mensaje de un buen amigo de otro foro ( abajo el cuadradito )

Poné el dibujo más grande para que se vea claramente que es lo que dice tu sabio amigo...no ves que tengo que trabajar yo para ampliarlo...y la verdad...no tengo ganas.
Claro...a menos que estés trolleando, en cuyo caso te lo podés guardar.

e aqui el tipico argentino, es por eso que en el mundo mucho no nos quieren

Eso no lo entendí....

Flaco:
Tenés un serio "sindrome de persecución". Te repito por si no entendiste: no te doy bola ni me interesan las estupideces que escribas. Si no vas a poner algún argumento para apoyar tus opiniones, pues quedate fuera de la discusión...por que te estás comportando como un TROLL.

PD: Si es cierto que te cansaste, no contestés...

 

[diego_z]

jeje no soy flaco , otra vez demostraste ser argentino , pero esta vez interesante ,
no es que no me interese el tema , si te ofendiste te pido disculpas
, yo solo di mi opinion sobre el asm, que es un lenguaje en el que se manejan todos los recursos del pic, cosa que no se puede en c , la otra es el espacio en memoria que ocupa un mismo proyecto en una y otra lengua y asi innumerables ventajas que tiene el lenguaje de maquina con respecto a uno de alto nivel , si quieres mas ventajas te puedo enviar algun manual donde lo explica mas detalladamente , eduardo tambien le dio un ejemplo claro

 

[lubeck]

Yo tengo una pregunta.....

porque siempre que se habla de computadoras se defiende un programa , sistema, procesador etc ect...
como si su vida dependiese de ello....

porque no se defiende de igual forma... no se... unos zapatos o un martillo, un coche....

no es una herramienta y nada mas

saludos...

 

[fernandob]

no es al programa lo que defienden.

defienden (algunos ) LO QUE TIENEN , el camino que tomaron.
defienden lo que creen .

el tema es que a veces lo defienden tontamente y se pierden el descubrir cosas nuevas.

es ........orgullo, estupidez, dejadez tambien .

si yo digo:
LO QUE TENGO ES LO MEJOR lo que ocurre es:

1 -- soy un piola lo que estudie era lo mejor.
2 -- no tengo que esforzarme mas, por que lo que estudie es lo mejor.
3 -- de nuevo soy un piola y los demas entonces no estan a mi nivel, la mejor la consegui yo.

como dije es un error para mi , en su momento tuve un piquitin de ganas de aprender un lenguaje como C . pero no tenia a donde ir a aprenderlo.
pero lo mas importante es que me pregunte a mi mismo :
lo necesitas ?? o necesitaras ??
la respuesta de mi otro yo fue :
ni el asm. necesitas salamin, vivi feliz , comprate una revista porno. y vivi tranquilo si no haces diseños complejos, vos andas por tu linea de clients por otro lado.



ADEMAS: hay otra cosa a tenerse en cuenta, cuando uno programa en lenguajes de alto nivel no es solo eso, uno no usa C para hacer boludeces con leds o reles.
ANTES DE programar en C u otro lenguaje similar hay que tener un proyecto en vista, yo ni se esas palabras siquiera:
control por puerto USB de network no se que , o placa de GPS por medio de celular, o manjejar a travez de la PC o via internet, ethernet o requetenet.
en fin, primero hay que conocer la TEORIA DE ESOS CARAJOS y eso es INGENIERIA.
y cuando uno se mete en un proyecto aparecen mychisimos temas en los que uno tiene que meterse para resolver la teoria, LUEGO uno comienza con el programa.

yo no comprendo como es que me da la impresion a veces que veo o leo a pibes que se meten a programar y preguntan como manejar un T para disparar un rele.
o que ........................
no se, en verdad , cada uno hace las cosas como quiere, yo antes de aprender a limpiarme el culo aprendi a desenrollar el papel higienico.

no se peleen, cada quien tiene su realidad y cada quien tiene su fantasia.

 

[lubeck]

Si. si... ya lei tu post anterior a este.... y obvio este anterior ....

una vez mas coincido en mucho con lo que dices....

yo no se.... pero yo aprendi muy poco ASM un poco de C... y por giros de la vida me fui por los administrativos... FoxPro Dbase Basic.... todos muy similires....

y nunca he desarrollado una aplicacion para la NASA, BANAMEX,TELMEX, lo mas cercano fue una asesoria a un programador de la CFE y procesos informaticos a una empresa que se instalo en Mexico hace ya un par de años Barpimo, nunca he defendido a capa y espada ningún sistema lo deje de hacer casi desde que cai en la cuenta de que no es la herramienta es quien usa esa herramienta... y para que se necesita esa herramienta.... por alla desde el msdos 5.0 y los procesadores 386

pero en fin

me rei mucho con lo del lo listados y programas de asm....

se te olvido lo que tardaba la impresora de matriz en sacar ese listado... a desayunar mientras.... jjejejej

saludos

 

[fernandob]

casi desde que cai en la cuenta de que no es la herramienta es quien usa esa herramienta... y para que se necesita esa herramienta....
saludos

estamos sintonizando la misma estacion mientras caminamos

 

[Dr. Zoidberg]

Eso no es cierto, los compiladores de C generan un código lo suficientemente bueno como para que no valga la pena usar assembler, pero los "especialistas y con años de desarrollo encima" se calientan hasta ahí.

Un compilador de C te genera un buen código en las operaciones arimético-lógicas, en las comparaciones/switch, te saca el código muerto, te optimiza el codigo repetido en los bucles, te optimiza la inicialización de variables...

Se puede pensar: Que más se puede pedir? --> Que terminen la optimización.
El código generado necesita siempre una pasada más. No tengo idea por qué, pero no la hacen o la hacen para el orto.

El tema es que depende de como escribas el código. Mirá lo que me dió a mí:
Codigo original:

#OPT 9
void main()
{
   // TODO: USER CODE!!

   int16 A16, B16;
   int8 C8;
   
   A16 &= C8 | B16;

   // Esto es igual que arriba pero escrito de otra forma
   B16 |= C8;
   A16 &= B16;
}

Simbolos:

020     @SCRATCH
021     @SCRATCH
021     _RETURN_
022     @SCRATCH
023     @SCRATCH
024     @SCRATCH
026-027 main.A16
028-029 main.B16
02A     main.C8

Código ASM:

....................    A16 &= C8 | B16; 
0010:  MOVF   2A,W
0011:  IORWF  28,W
0012:  MOVWF  20
0013:  MOVF   20,W
0014:  ANDWF  26,F
0015:  MOVF   29,W
0016:  ANDWF  27,F
....................  
....................    B16 |= C8; 
0017:  MOVF   2A,W
0018:  IORWF  28,F
....................    A16 &= B16; 
0019:  MOVF   28,W
001A:  ANDWF  26,F
001B:  MOVF   29,W
001C:  ANDWF  27,F

Ves lo que sucede? Vos estás forzando un cambio de "precisión" en el medio de la ecuación y tal vez por eso use una variable auxiliar (no sé quien lo programó así), aunque está demás. De la otra forma, es claro que la OR de C8 es con la parte baja de B16 y no tiene que hacer ningún cambio de precisión en el medio.

Moraleja: La pasada adicional no es del compilador, sino nuestra.

 

[Eduardo]

El tema es que depende de como escribas el código. Mirá lo que me dió a mí:
...........

  B16 |= C8;
  A16 &= B16;

No es lo mismo, ahí estás alterando B16.

Ves lo que sucede? Vos estás forzando un cambio de "precisión" en el medio de la ecuación y tal vez por eso use una variable auxiliar (no sé quien lo programó así), aunque está demás. De la otra forma, es claro que la OR de C8 es con la parte baja de B16 y no tiene que hacer ningún cambio de precisión en el medio.

En este caso es porque el dato es de 16 bits y el acumulador de 8, lo que obliga a hacer la operacion paso a paso (necesita crear una variable temporal).
Por eso digo que les queda faltando una pasada, porque algunas de esas variables no son necesarias.

Si en lugar de hacer mezcla de 8 con 16 bits, hacés todo en 16:

A16 &= C16 | B16 ;
​

te crea dos variables temporales

MOVF 0x14, W
IORWF 0x12, W
MOVWF 0xc <<-- aux1
MOVF 0x15, W
IORWF 0x13, W
MOVWF 0xf <<-- aux2
MOVF 0xc, W <<-- aux1
ANDWF 0x10, F
MOVF 0xf, W <<-- aux2
ANDWF 0x11, F
​

Optimizar eso a mano es trivial, pero para un compilador no lo es tanto.
Pero en el ejemplo que dí antes es trivial también para el compilador, porque a la variable temporal se le asigna un valor y en la instrucción siguiente lo descarga y no se usa mas.
Como ya dije antes, estas dos instrucciones redundantes (carga de la variable temporal, descarga en la instrucción siguiente y no more) es un detalle desprolijo frecuente entre distintos compiladores.

Es a esto lo que apunto, entre los fans de C está el mito de que el código generado por el compilador está tanto o más optimizado que uno hecho a mano. Cuando en realidad se genera un buen código al que le falta una última limpieza "a mano".

 

[electroconico]

^^ lo que tiene ASM es que te liga mas al hardware , a un arquiectura.
C ya es portabilidad. Además que realizas trabajos mas complejos sin quebrarte el coco ^^

 

[Dr. Zoidberg]

No es lo mismo, ahí estás alterando B16.

Sip, eso es cierto, pero sin contexto adecuado, me daba lo mismo hacer una u otra.

Es a esto lo que apunto, entre los fans de C está el mito de que el código generado por el compilador está tanto o más optimizado que uno hecho a mano. Cuando en realidad se genera un buen código al que le falta una última limpieza "a mano".

Vos sabés como es esto...no se puede evitar el KARMA
Siempre hay que dar algo para recibir algo, y esto no es la excepción...pero anda bastante cerca, y recibís mucho mas de lo que das...

 

[Eduardo]

Sip, eso es cierto, pero sin contexto adecuado, me daba lo mismo hacer una u otra.

La idea era un ejemplo donde no se optimiza el uso del acumulador.

Vos sabés como es esto...no se puede evitar el KARMA
Siempre hay que dar algo para recibir algo, y esto no es la excepción...pero anda bastante cerca, y recibís mucho mas de lo que das...

Es que yo en eso estoy de acuerdo, la diferencia esta en que no pongo tan arriba las bondades del compilador.
Es como una mujer con plata, son tantos los problemas que nos resuelve que a quien le importan sus defectos.


Yo soy una persona a la que le gusta hacer hacer declaraciones y forzar tipos de variable complejos, en consecuencia, constantemente me saltan errores que me obligan a ver el listado en assembler para saber que corno esta pasando, y muchas veces te sorprenden las instrucciones redundantes obvias que se generan.


Solamente el viejo compilador de Borland BCC32 v4.0 (para x86) es una excepcion, no solo te optimizaba realmente el uso de los registros del procesador sino tambien el stack del coprocesador matematico.
Vos escribias varias lineas de operaciones complejas en punto flotante y te las modificaba completamente alterando el orden de los diferentes pasos para minimizar las descargas a memoria. Te usaba los 8 niveles del stack cuando cualquier otro te usa st(0), st(1) y el resto no existe.
Ese si se acercaba a la perfeccion . Lamentablemente, en las versiones posteriores volvieron a la "normalidad".

 

[lubeck]

Eduardo

Realmente tengo mucha curiosidad y no creas que es mala leche....
todos tenemos un razon del porque hacemos asi las cosa....

mi curiosidad consiste en que para que quieres tanta prefeccion estamos hablando yo creo que de milinanosegundos.....

que aplicaciones realizas....

entiendo que por el nivel del desarrollo que veo puede ser algo secreto... y comprendo si decides no hacerlo publico....

saludos y de antemano gracias....

 

[Eduardo]

mi curiosidad consiste en que para que quieres tanta prefeccion estamos hablando yo creo que de milinanosegundos.....

Ehh..No tanto!

Estas agarrando la cosa para otro lado.

De lo que yo hablo es que el codigo generado por un compilador no es superior al hecho a mano (solo si el que lo programa en assembler sabe lo que hace ), algo que no tiene nada que ver con si me sirve o no.

La velocidad de desarrollo y facilidad de mantenimiento son factores importantisimos pero son de indole practica, mientras que la optimizacion es mas bien tecnica y el "buen codigo" es filosofica. Si un programa fuera una mujer esto seria como mezclar dinero, inteligencia y belleza.


Respecto a si tiene sentido ahorrarse microsegundos.
Y... tiene sentido si hace falta, como te puede pasar con un servicio de interrupcion de un evento rapido --> Aunque el tiempo te alcance siempre es conveniente tener mas margen.
Pero eso no significa que haya que escribir el programa completo en assembler --> Se escribe solamente la rutina o el fragmento de rutina comprometido, cosa que podes hacer dentro del programa con la directiva ASM.

 

[lubeck]

Pero eso no significa que haya que escribir el programa completo en assembler --> Se escribe solamente la rutina o el fragmento de rutina comprometido, cosa que podes hacer dentro del programa con la directiva ASM.

eso es lo que yo siempre he pensado.... utilizas un lenguaje u otro dependiendo si la aplicacion lo requiere... muchos lenguajes ofrecen esa virtud...

y si creo que lo estaba agarrando por otro lado pero me queda claro tu punto de vista....

concuerdo....

saludos...

 

[Dr. Zoidberg]

Es como una mujer con plata, son tantos los problemas que nos resuelve que a quien le importan sus defectos.

Solamente el viejo compilador de Borland BCC32 v4.0 (para x86) es una excepcion, no solo te optimizaba realmente el uso de los registros del procesador sino tambien el stack del coprocesador matematico.
Vos escribias varias lineas de operaciones complejas en punto flotante y te las modificaba completamente alterando el orden de los diferentes pasos para minimizar las descargas a memoria. Te usaba los 8 niveles del stack cuando cualquier otro te usa st(0), st(1) y el resto no existe.
Ese si se acercaba a la perfeccion . Lamentablemente, en las versiones posteriores volvieron a la "normalidad".

Si, esas cosas pasan, pero todo tiene una razón...aunque desconozco las de Borland.
En programación concurrente o en ISR (código compilado) es muy común ver la recarga de valores a los registros desde la memoria, aún cuando parece inútil...como en el caso de la variables volatile del C, y eso es solo para asegurar que se vea el ultimo valor de la variable en memoria cuando otro proceso "puede" haberla modificado concurrentemente...pero no es el caso de tu ejemplo.