Hola buenas bueno viendo que al veces para hacer pruebas en codigos C/C++ necesito insetar codigo asm
y sabiendo que si inserto codigo asm en C mi codigo ya no es portable, esto quiere decir que solo se podra ejecutar
en la arquitectura de codigo asm que inserte verdad? entonces como puedo hacer para que se pueda ejecutar
en un x86 y en un x64 o es imposible
si es necesario leer bastante lo hare me interesaria aprender y saber si es posible ( y si lo es, como?) hacer aplicaciones
para x86 y x64 muchas gracias 

Una máquina de 64 bits con un sistema de 64 bits puede ejecutar de forma nativa por las capacidades intrínsecas del CPU, tanto código de 32 bits como de 64 bits.

El código de 32 bits funcionando bajo modo de 64 bits es "Legacy Mode" (Modo de Compatibilidad), todos los CPUs de 64 bits son capaces nativamente de hacer esto.

Para pruebas de bajo nivel, el código de 64 bits tendría que ejecutarse solo en máquinas de 64 bits, o emular un CPU en modo de 64 bits usando instrucciones de 32 bits (relativamente fácil, aunque trabajoso, si solo nos limitamos a instrucciones determinadas y que preferiblemente no necesiten privilegios especiales -rings, etc.- y necesitamos leer detalladamente los manuales de CPUs de Intel y AMD para la especificación de las instrucciones a emular).

El código/programa de 32 bits puede usarse en un sistema de 64 bits sin problemas, desde el punto de vista simplemente del CPU y la aplicación de usuario.

Si se desea ejecutar un programa en el modo predeterminado y nativo del sistema, habría que crear 2 versiones del mismo programa, de 32 y 64 bits.

Es posible crear código fuente de ensamblador semiportable (usando macros, IFs de precompilador, etc., o algún lenguaje especial, o dejarle simplemente el trabajo a C/C++ si es adecuado para nuestras necesidades, usando un poco de Makefiles para cada versión, o una combinación de lo anterior).

No lo es.

C/C++ es portable a nivel de código fuente, cuando se sigue el estándar en cuestión este puede ser compilado (sin importar la implementación) y tendrá un comportamiento bien definido.

Un saludo

A mí me tardó 6 meses a tiempo completo para aprender apenas lo básico del Ensamblador x86 (con muchos intentos anteriores fallidos de entenderlo), incluyendo arrancar la máquina, leer/escribir discos duros IDE en modo PIO, entrar a modo de 32 bits, y cosas por el estilo.

Aprender a hacer programas de Windows me tomó mucho más tiempo, y aprender apropiada y realmente C entendiendo una parte de las interacciones a nivel de Ensamblador es algo realmente reciente para mí, y todavía me hace falta entender cómo funcionan las excepciones en C++ vistas desde Ensamblador.

En resumen, el lenguaje Ensamblador es diferente para cada procesador distinto, de diferente arquitectura, no es algo de un momento sino que un proceso de preparación y aprendizaje de tiempo completo y extenso. Este lenguaje es una necesidad. C/C++ son el siguiente nivel estandarizado, para que el programador no tenga que encargarse de conocer las instrucciones y optimizaciones de un CPU, y es el compilador el que debe tener la capacidad de crear código de máquina para uno u otro CPU, y a su vez encapsularlo en un formato de archivo apropiado para la máquina (aunque es posible correr código sin absolutamente ningún formato, pero a un nivel más bajo y difuso, pero es perfectamente posible).

Con compiladores como GCC, a veces no solo es posible sino que necesario crear módulos de código objeto hechos en Ensamblador. Estos se usan más tarde en programas de C/C++ usando extern.

Pero en términos generales, siempre hay convenciones que respetar, aunque se trabaje directamente en Ensamblador, por ejemplo, la más común, que es respetar las convenciones de llamada de funciones, sean estas cdecl (programas en C) o stdcall (WinAPI), y llamadas a funciones de C++ con excepciones, etc., que es algo mucho más avanzado y mucho menos conocido con lo que trabajar directamente en Ensamblador (como el caso de MFC).

____________________________________________________


Aquí hay un programa de Windows de 32 bits que hice 100% en Ensamblador, incluyendo las estructuras del formato PE. Todo está hecho en Ensamblador.


http://devel.no-ip.org/tmp/ClockCount.zip

El programa se llama ClockCount.exe, e incluye también un archivo .BAT junto con la versión correcta de NASM para compilarlo por uno mismo. Todo está allí, también el icono del programa incluido como código fuente de Ensamblador.


El código fuente muestra el tipo de instrucciones que se usan en aplicaciones de usuario. No hay obligación de usar extensiones del CPU especiales. Nada especial ni privilegiado.

Siempre es posible emular absolutamente cualquier instrucción que no requiera privilegios especiales, y siempre y cuando sepamos lo que estamos haciendo, con los manuales de Intel/AMD en mano, aunque obviamente nunca van a tener el rendimiento de las instrucciones nativas.

El CPU puede indicar qué extensiones están disponibles usando la instrucción cpuid y otros trucos avanzados, aunque ese es un tema muy extenso, como para otro tema del foro y totalmente cubierto por los manuales de los CPUs.

C y C++ son independientes de Ensamblador, aunque las características de más bajo nivel siempre son fuertemente influenciadas por esos CPUs, tanto así que los mismos manuales y la propia Intel ofrecen un compilador optimizador de C/C++, y las optimizaciones al estilo de C/C++ se dicuten en los propios manuales.

_______________________________________________

Los registros de segmento como el de FS o GS (a aún peor para un sistema operativo bien establecido, DS, ES o SS, o CS -solo indirectamente-) no se usan en lenguajes como C/C++, así que tampoco suelen usarse en las APIs de 32 o 64 bits de los diferentes sistemas.

Aunque a más bajo nivel, todo se vale, por ejemplo estando en 16 bits y activar 32 bits, incluso podemos ejecutar (o incluso emular) el código del BIOS, que no tiene un formato definido.

De nadas.