c++ vs assembler

"Ricardo Gonzalez [MVP]" escribió en el mensaje
news:

Hola Javier,

Creo que de cualquier manera es mejor ir hacia arriba en los niveles de
abstraccion. Sabiendo C++ es muy facil aprender lenguajes como C# o J# e
incluso VB.NET ya que el conocimiento del lenguaje no es lo mas importante
sino conocer los servicios del Framework. te recomendaría explorar el

mundo

de .NET sea con las extensiones administradas para VC++ o con un lenguaje
como C#, estoy seguro de que te gustará. a mi me encanta y vivi mucho

tiempo

en C++, luego Java, VB y C# ahora no lo cambio.

un saludo y feliz año nuevo

Je, je cómo barres para casa... :-)

Pero estás en lo cierto, siempre hay que ir al nivel más alto disponible,
salvo que te dediques al hardware.

Fco. Javier, si te dedicas o interesas por la programación del hardware
(drivers y cosas de esas), pues te aconsejo el ensamblador, pero si no, lo
que dice Ricardo González.

Segun esa teoria, los que usan Visual C++ deberían dejarlo por otros como
Delphi, Visual Basic, Visual Fox, C# ??

En qué "nivel de abstracción" se puede considerar el VC++ respecto a los
demás ?




"Ricardo Gonzalez [MVP]" wrote in message
news:

Hola Javier,

Creo que de cualquier manera es mejor ir hacia arriba en los niveles de
abstraccion. Sabiendo C++ es muy facil aprender lenguajes como C# o J# e
incluso VB.NET ya que el conocimiento del lenguaje no es lo mas importante
sino conocer los servicios del Framework. te recomendaría explorar el

mundo

de .NET sea con las extensiones administradas para VC++ o con un lenguaje
como C#, estoy seguro de que te gustará. a mi me encanta y vivi mucho

tiempo

en C++, luego Java, VB y C# ahora no lo cambio.

un saludo y feliz año nuevo


Ricardo González Vargas.
MVP


"Fº Javier" wrote in message
news:
> Hola: ¿Pensais que sabiendo VC++ es productivo emplear tiempo

aprendiendo

> ensamblador, o seria mejor aprovechado ese tiempo estudiando nuevas
> librerias para C++, por ejemplo?
> Mis mejores saludos.

-
> Fº Javier
>

Pero estás en lo cierto, siempre hay que ir al nivel más alto disponible,
salvo que te dediques al hardware.

No estoy de acuerdo, actualmente se desperdicia la mayoría de la potencia de
los procesadores por culpa de una capa de abstracción demasiado abstracta,
me refiero a c#, vb.net y similares.
Estudiar ensamblador es muy útil para desarrollar pequeñas DLLs de apoyo,
crear aplicaciones muy veloces o casos puntuales, incluso algunos
compiladores proporcionan injertar codigo en ensamblador en su lenguaje.
Por mejor generación de código me quedaría con el MASM32, luego el Visual
C++ 6, y en general, para programar cualquier cosa, el VC++.

Fco. Javier, si te dedicas o interesas por la programación del hardware
(drivers y cosas de esas), pues te aconsejo el ensamblador, pero si no, lo
que dice Ricardo González.

Si tienes que pasar a mayusculas un flujo de datos constante promedio de 1
MB/s o algo similar, se nota la mucho la diferencia, y no necesariamente
estás trabajando con hardware, olvidate de las antiguas int porque el
ensamblador de Win32 es tan sencillo como el VC++ sin usar MFC.

"Ricardo Passians" escribió en el mensaje
news:

Segun esa teoria, los que usan Visual C++ deberían dejarlo por otros como
Delphi, Visual Basic, Visual Fox, C# ??

Depende.

Desde luego, hacer una aplicación de bases de datos con el VC puede llegar a
ser una tarea ingente, mientras que con Delphi, etc, puede llegar a ser
bastante grata, dado el soporte que para ello tienen. Respecto al C#, NS/NC,
apenas he visto algo de él, pero entiendo que es un C++ de más "alto nivel"

En qué "nivel de abstracción" se puede considerar el VC++ respecto a los
demás ?

Digamos que tienes el ensamblador, que es el nivel más bajo (quitando, claro
está, el meter a mano los códigos de operación).

Luego tienes el C, que digamos es un ensamblador genérico, y que ante la
programación de sistemas se debería corresponder muy pocas instrucciones de
código máquina por sentencia de C. Salvo bucles y algunas construcciones,
cada sentencia de C no debe crear más de dos o tres instrucciones de
ensamblador, amén de ciertos compiladores "agresivos" que aprietan el
código de forma extraordinaria.

Luego estaría el C++, que se correspondería a la parte del VC de bajo nivel,
que digamos es una herramienta a caballo entre el C y otras de mayor nivel,
como el Java o el C#. El C++ junto a bibliotecas de clases (como MFC) se
convertiría en un lenguaje de alto nivel, o casi, que es el otro 50% del VC.

Y encima de todo, tendríamos el VB, Delphi, supongo que el C# y demás, que
entrarían dentro del nivel más alto de los lenguajes de programación como
tales.

Desde luego, que conforme vamos bajando de nivel, aumentamos el rendimiento
hasta quizás el nivel de "C en lugar de ensamblador", en el que debería
haber muy pocas diferencias entre el código generado por el compilador de C
y el tuyo propio en ensamblador.

Es, en mi opinión, una elección personal, pero hay que tener siempre cierto
criterio a la hora de elegir.

"ViKT0RY" escribió en el mensaje
news:bsjvt9$ps7$

> Pero estás en lo cierto, siempre hay que ir al nivel más alto

disponible,

> salvo que te dediques al hardware.
>

No estoy de acuerdo, actualmente se desperdicia la mayoría de la potencia

de

los procesadores por culpa de una capa de abstracción demasiado abstracta,
me refiero a c#, vb.net y similares.

Sí. Pero te permiten hacer cosas en poco tiempo, que de otro modo te
llevarían bastante más.

Estudiar ensamblador es muy útil para desarrollar pequeñas DLLs de apoyo,
crear aplicaciones muy veloces o casos puntuales, incluso algunos
compiladores proporcionan injertar codigo en ensamblador en su lenguaje.
Por mejor generación de código me quedaría con el MASM32, luego el Visual
C++ 6, y en general, para programar cualquier cosa, el VC++.


> Fco. Javier, si te dedicas o interesas por la programación del hardware
> (drivers y cosas de esas), pues te aconsejo el ensamblador, pero si no,

lo

> que dice Ricardo González.
>
>

Si tienes que pasar a mayusculas un flujo de datos constante promedio de 1
MB/s o algo similar, se nota la mucho la diferencia, y no necesariamente
estás trabajando con hardware, olvidate de las antiguas int porque el
ensamblador de Win32 es tan sencillo como el VC++ sin usar MFC.

Ok, pero yo lo haría en C. Realmente no sé el nivel de optimización del VC,
pero las herramientas para plataforma cruzada que yo uso son extremadamente
eficientes pasando de C a código máquina, y en funciones largas y con mucho
código el resultado final es, con diferencia mejor que el que yo pudiera
hacer sin dedicarle un tiempo excesivo.
Te pondré un ejemplo:
Normalmente, los micros tienen un espacio de direcciones dedicados a la
configuración de sus elementos internos, uarts, chip selects,
interrupciones, etc. Cuando tocas algo de eso, tienes dos formas de hacerlo:
con un puntero a una estructura en C, que "cubra" el espacio de direcciones
completo (o parte), o con macros que terminan en una escritura en una
dirección fija.
En el primer caso sería algo asi:
m_mbar->cs[0].cscr=0xffe0000;
en el segundo,
WRITE_MBAR(ADDR_CS0_CSCR,0xffe0000);
o
WRITE_MBAR(MAKE_CS_ADDR(CS0,CSCR),0xffe0000);
o similar.
Desde luego, la primera solución es la más elegante y menos dada a errores,
compruebas tipos de datos, etc, pero ciertos compiladores generan algo del
estilo
-Cargar la dirección de m_mbar en R1
-Cargar el offset de cs en R2
-Cargar el multiplicador de CS en R3
-Cargar el offset de cscr en R4
-Multiplicar R3*R2
-Sumar R1
-Sumar R4
-Poner el acumulador en A1
-Cargar 0xffe0000 en R1
-Poner R1 en la direccion a que apunta A1.

Quizás use menos instrucciones, pero al menos se carga una dirección base,
se realiza una suma y se escribe un valor, mientras que con el código de la
macro, o con un compilador de C bueno, ambos resultados serían:

-Pon en A1 la dirección a que apunta m_mbar->cs[0].cscr.
-Escribe en la dirección de memoria que está en A1 0xffe0000.

Ya está. Igual que con la macro. Igual que tu lo harías en ensamblador. Y
teniendo en cuenta que el compilador no se equivoca y tu podrías hacerlo,
siempre que un compilador fuera tan eficiente, yo lo tendría claro. De
hecho, el CodeWarrior para 68K y ColdFire es tan eficiente como eso, e
incluso sabe multiplicar haciendo desplazamientos y otras "cosas raras" a
las que a simple vista no le ves sentido.

Desde luego que a veces tienes que terminar en ensamblador, pero en mi caso
se reduce a realizar micro retardos (con bucles en ensamblador con NOPs
entre medias, contando las instrucciones y sus tiempos), que si los hago en
C, el compilador los saca de sitio o los elimina.

Si en C aplicas los modificadores const, static y volatile adecuadamente, el
código puede llegar a ser insuperable.

Desde luego, hacer una contabilidad así no se lo recomiendo a nadie.