elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: Curso de javascript por TickTack


+  Foro de elhacker.net
|-+  Programación
| |-+  Programación General
| | |-+  ASM (Moderador: Eternal Idol)
| | | |-+  ¿Que libro de asm quisieras leer que no encuentras en la internet ?
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: 1 [2] Ir Abajo Respuesta Imprimir
Autor Tema: ¿Que libro de asm quisieras leer que no encuentras en la internet ?  (Leído 9,794 veces)
~

Desconectado Desconectado

Mensajes: 67



Ver Perfil WWW
Re: ¿Que libro de asm quisieras leer que no encuentras en la internet ?
« Respuesta #10 en: 25 Febrero 2013, 18:38 pm »

pero el emsablador tiene algun limite  que desconosca  por que no veo mucho software comercial grande en internet no enteindo el por que :huh: 

ranking 24



podrias decirme los libros que sean recomendables solo nesecito los titulos para ponerme a buscar

El único libro de Ensamblador que compré y leí formalmente en toda mi vida fue el de Charte Ojeda (versión 2005, o 2009). Después de eso simplemente he usado los manuales de procesador de Intel y AMD, y ejemplos en Internet.

Y sobre la razón por la que ya no hay mucho software escrito en Ensamblador actualmente, es porque todos piensan en escribir programas lo más rápido posible. Igualmente, solo los programadores más profesionales pueden realmente y quieren escribir aplicaciones grandes en C o C++; el resto tiende a usar .NET o cosas más misceláneas o simples, que den gratificación y resultados visuales inmediatos.

Cada vez menos programadores entienden siquiera los algoritmos que se usan en las raíces de la informática y ese conocimiento no lo piden en un trabajo a menos que sea un país desarrollado; y ya no se diga programar con herramientas que no ayudan con IDEs y grandes librerías, y es más práctico para la mayoría programar en un nivel más alto (aunque en realidad quienes crean compiladores, la PC en sí misma, y el sistema operativo y drivers por ejemplo, además de los que quieren crear una base de código fuente 100% propia, siempre necesitan saber mucho de Ensamblador, y después de C y C++, para automatizarlo pero también para ser incluso de implementar código que interactúe con estos en Ensamblador).

Cada vez las computadoras y los programas se vuelven más desechables. Las compañias más grandes, comerciales y transnacionales ya dominan la tecnología y ahora solo les interesa crear aplicaciones nuevas cada tantos meses para ganar dinero, aunque esta sea un paquete enorme que pudo haber sido un programa mucho más pequeño y rápido. Puede que usen C++ (pero actualmente más bien C#), pero ni siquiera se esfuerzan en identificar código de librería innecesario para eliminarlo.





El ensamblador no es portable, en proyectos grandes de miles de paginas de codigos ( más si es escrito en ASM ) es mucho
más dificil de mantener ordenado, modificar/mejorar partes, arreglar errores incluso si el programador lo tien ordenado.
C/C++ creo que es el lenguaje perfecto, estándar, portable, eficiente todo esto más la optimizacion que ofrece el compilador.
Compañias dudo que escriban sus programas en ASM por los motivos que mencione, no es nada bueno para ellos.
Aparte que C/C++ puede hacer el 90-92% de las cosas que ASM puede hacer. pero a la vez es tan bueno saber programar en ASM.
Esto es lo que he estado tratando de hacer, creando un lenguaje de programación con la sintaxis fácil de editar y leer de C, y el bajo nivel de Ensamblador. El resultado es un compilador que crea código en Ensamblador partiendo de código más fácil de entender tanto que el de C como el de Ensamblador x86, y el resultado es hacer que la programación en Ensamblador se vuelva eficiente, y en un futuro portable.

Si queremos ser realmente independientes en tecnología, en lugar de simplemente usar compiladores que no comprendemos por mucho que optimicen, tendremos que efectuar este tipo de esfuerzo de desarrollo para aprender ese tipo de magia de optimización y magia informática (pero al final muchísimo más avanzado que lo que pongo aquí):

El Proyecto del Lenguaje de Programación RealC


Eventualmente esperaría que algún día existiera un compilador capaz de usar directamente todos los lenguajes, incluyendo Ensamblador x86, y producir código para cualquier plataforma.

El Ensamblador puede perfectamente convertirse en portable e incluso unificar varios tipos de Ensamblador si simplemente se creara un compilador que convierta el Ensamblador a código de máquina nativo (y si se usa en la máquina nativa, sería una conversión directa).

Esto es todo lo que nos separa de hacer que todo el código que se ha escrito alguna vez en Ensamblador tenga mucha más relevancia.

Digo "simplemente", pero esto sería tan complicado como un compilador, pero obviamente posible.

Programar en Ensamblador es realmente más simple que programar en C o C++, porque siempre y cuando sea código que no interactúe con APIs externas (es decir, potencialmente la mayor parte), uno no está obligado a seguir convenciones ni aprender la estructura o sintaxis adicional, y eso lo hace más simple.

Lo difícil es manejar una gran cantidad de código, especiaqlmente si no está bien comentado o documentado, o hay que depurar errores.

Aprender C es mucho más fácil y tiene mucho más sentido si primero se aprende a programar en Ensamblador. Después viene aprender C++.


En línea

Sitio web (si la siguiente imagen no aparece es porque está offline):
x64core


Desconectado Desconectado

Mensajes: 1.908


Ver Perfil
Re: ¿Que libro de asm quisieras leer que no encuentras en la internet ?
« Respuesta #11 en: 25 Febrero 2013, 19:13 pm »





Esto es lo que he estado tratando de hacer, creando un lenguaje de programación con la sintaxis fácil de editar y leer de C, y el bajo nivel de Ensamblador. El resultado es un compilador que crea código en Ensamblador partiendo de código más fácil de entender tanto que el de C como el de Ensamblador x86, y el resultado es hacer que la programación en Ensamblador se vuelva eficiente, y en un futuro portable.

Si queremos ser realmente independientes en tecnología, en lugar de simplemente usar compiladores que no comprendemos por mucho que optimicen, tendremos que efectuar este tipo de esfuerzo de desarrollo para aprender ese tipo de magia de optimización y magia informática (pero al final muchísimo más avanzado que lo que pongo aquí):

El Proyecto del Lenguaje de Programación RealC


Eventualmente esperaría que algún día existiera un compilador capaz de usar directamente todos los lenguajes, incluyendo Ensamblador x86, y producir código para cualquier plataforma.

El Ensamblador puede perfectamente convertirse en portable e incluso unificar varios tipos de Ensamblador si simplemente se creara un compilador que convierta el Ensamblador a código de máquina nativo (y si se usa en la máquina nativa, sería una conversión directa).

Esto es todo lo que nos separa de hacer que todo el código que se ha escrito alguna vez en Ensamblador tenga mucha más relevancia.

Digo "simplemente", pero esto sería tan complicado como un compilador, pero obviamente posible.

Programar en Ensamblador es realmente más simple que programar en C o C++, porque siempre y cuando sea código que no interactúe con APIs externas (es decir, potencialmente la mayor parte), uno no está obligado a seguir convenciones ni aprender la estructura o sintaxis adicional, y eso lo hace más simple.

Lo difícil es manejar una gran cantidad de código, especiaqlmente si no está bien comentado o documentado, o hay que depurar errores.

Aprender C es mucho más fácil y tiene mucho más sentido si primero se aprende a programar en Ensamblador. Después viene aprender C++.

Hola,

Me ha llamado la atencion algo que mencionas, y es el hecho que el ensamblador podría ser "portable", podrias explicar mejor lo que piensas?
como el lenguaje ensamblador podría ser portable para ti? solo basándonos en estas arquitecturas: x86, x86-64.
Más bien impossible que el lenguaje ensamblador sera portable por más macros que tenga, es como decir que estas instrucciones se puedan ejecutar nativamente
dentro de un x86:

MOV RAX,0x800000000
MOV [R8],RAX

Yo no desvaloro lo que tienes en mente pero no crees que seria mejor crear un lenguaje ( basado en C ) y mejorarlo, Hablo acerca de mejorarlo debido a que
sabemos que al veces nos es necesario usar ensamblador en linea o linkear modulos .asm con projectos C/C++ a diferencia de tratar de hacer el ensamblador portable?






En línea

~

Desconectado Desconectado

Mensajes: 67



Ver Perfil WWW
Re: ¿Que libro de asm quisieras leer que no encuentras en la internet ?
« Respuesta #12 en: 25 Febrero 2013, 20:22 pm »

Hola,

Me ha llamado la atencion algo que mencionas, y es el hecho que el ensamblador podría ser "portable", podrias explicar mejor lo que piensas?
como el lenguaje ensamblador podría ser portable para ti? solo basándonos en estas arquitecturas: x86, x86-64.
Más bien impossible que el lenguaje ensamblador sera portable por más macros que tenga, es como decir que estas instrucciones se puedan ejecutar nativamente
dentro de un x86:

MOV RAX,0x800000000
MOV [R8],RAX

Yo no desvaloro lo que tienes en mente pero no crees que seria mejor crear un lenguaje ( basado en C ) y mejorarlo, Hablo acerca de mejorarlo debido a que
sabemos que al veces nos es necesario usar ensamblador en linea o linkear modulos .asm con projectos C/C++ a diferencia de tratar de hacer el ensamblador portable?
Lo mismo que hace portables a C o C++ (hacer ciertas conversiones entre distintas arquitecturas, o dejar las instrucciones como están) es lo que haría al Ensamblador portable en los mismos términos, pero por una u otra razón nadie se ha interesado hasta ahora en resolver ese problema.

Pero por ejemplo para ingeniería inversa, en los casos en los que no se puede representar código con C, un lenguaje como este sería la mejor opción, además de hacer que sea más fácil leer desensamblajes enormes.


La realidad es que hay tareas de programación que solo se ven elegantes con código de tan bajo nivel como este; y hay otras tareas que solo se ven elegantes con lenguajes a nivel de C o C++. Por eso sería mejor un compilador capaz de usar diferentes lenguajes de forma nativa, para que cada tarea sea lo más elegante y legible posible en su dimensión.

Por ejemplo, sea dentro o fuera de Windows, si lo que queremos es programar registros gráficos VGA estándar o no estándar, lo mejor es usar un lenguaje claro y portable, de más bajo que C. Eso hará el código extremadamente elegante.

Librería VGA Estándar (para 16, 32 y 64 bits, con RealC)

Por ejemplo este es código de RealC para cambiar modos en VGA:
Código:
//This function makes the VGA card enter in
//standard 320x200 256-color MCGA mode,
//without using the BIOS.
//
//It follows the following sequence:
//
// 1. Turns off monitor output to completely avoid flicker,
//    frequency/synchrony issues while setting the video mode,
//    and apparently making the video mode switching much faster
//    from text to graphics.
//
// 2. Configures the Miscellaneous Output Register.
//
// 3. Configures the Feature Control Register.
//
// 4. Write the 5 Sequencer registers.
//
// 5. Unprotect CRTC registers 0-7.
//
// 6. Writes the 25 CRTC registers.
//
// 7. Protects CRTC registers 0-7.
//
// 8. Writes the 9 Graphics Controller Registers.
//
// 9. Writes the Attribute Controller Registers.
//    Here's an optimization: From its 21 registers, only
//    registers 16 to 20 are written. Registers 0 to 15
//    are left unchanged because those palette registers are
//    not useful for MCGA 320x200x256, so we skip writing those.
//
//10. Enable reads to the palette by setting bit 5 of the
//    Attribute Controller Index Register at 0x3C0, to 1.
//
//11. Turn back on monitor output to make use of the graphics mode.
//
//This sequence takes the best from all of the other programming sequences floating around
//for manually entering mode 13h, and thus has original-research optimizations
//from me (skipping configuration the 16-color palette of the Attribute Controller),
//and avoiding inferior ways of doing things (wait for vertical retrace, instead of
//doing it much better by disabling hardware video output, while reconfiguring
//the registers), etc. And it is much, much more documented and easy to read/understand,
//with nice and elegant public domain low level standard VGA "API" functions.
//
//This program does NOT reconfigure BIOS video mode metrics in the BDA, nor clears
//the screen after setting the video mode, just because those tasks are entirely
//apart from the low level hardware programming shown here. That would just add to the
//bulk of this demo program, and it will be programmed by me, but in a different, yet
//equally reusable/combinable "API" package.
///
function set_mode_MCGA_320x200x256()
{
 push $WIDEAX;
 push $WIDEBX;
 push $WIDECX;
 push $WIDESI;

 //Write to Color register address in all cases
 //that apply to our interfacing functions:
 ///
  $BX=0000000001000000b;


 //Turn monitor output off to be nicer with older
 //and delicate monitors while fiddling with the configuration:
 ///
  stdVGA_Sequencer_Monitor_Off();


 //We want to set this register to clear its bit 0,
 //to enforce activating I/O register addresses for
 //color video modes, and the rest of its configurations:
 ///
  $AL=[CGA_320x200x256Gen__MiscOutputReg];
  stdVGA_set_Miscellaneous_Output_Register();


 //Write the Feature Control Register:
 ///
  $AL=[CGA_320x200x256Gen__FeatureControlReg];
  //$BX=0000000001000000b;  //Write to Color register address
  stdVGA_set_Feature_Control_Register();


 //Write the Sequencer registers:
 ///
  $CH=0;  //Index of first register to write
  $CL=5;  //Number of registers to write
  $WIDESI=CGA_320x200x256SequencerRegs;
  stdVGA_set_Sequencer_regs();


 ///INIT: Write the CRTC registers
 ///INIT: Write the CRTC registers
 ///INIT: Write the CRTC registers
 ///INIT: Write the CRTC registers
 ///INIT: Write the CRTC registers

  //First unprotect registers 0-7:
  ///
   $CL=00000000b;          //Do Unprotect
   //$BX=0000000001000000b;  //Use Color I/O port address
   stdVGA_protect_unprotect_CRTC_regs();



  //Write the CRTC registers:
  ///
   $CH=0;   //Index of first register to write
   $CL=25;  //Number of registers to write
   //$BX=0000000001000000b;  //Use Color I/O port address
   $WIDESI=CGA_320x200x256CRTCRegs;
   stdVGA_set_CRTC_regs();



  //Finally, protect registers 0-7 again:
  ///
   $CL=10000000b;          //Do Protect
   //$BX=0000000001000000b;  //Use Color I/O port address
   stdVGA_protect_unprotect_CRTC_regs();


 ///END:  Write the CRTC registers
 ///END:  Write the CRTC registers
 ///END:  Write the CRTC registers
 ///END:  Write the CRTC registers
 ///END:  Write the CRTC registers



 //Write the Graphics Controller registers:
 ///
  $CH=0;  //Index of first register to write
  $CL=9;  //Number of registers to write
  $WIDESI=CGA_320x200x256GraphicsRegs;
  stdVGA_set_Graphics_regs();



 //Write the Attribute Controller registers. We will
 //try skipping the 16-color palette registers here,
 //since MCGA 320x200@256 colors uses the DAC instead
 //of those registers, and these registers don't care
 //in this mode:
 ///
  //Address bits of attribute flip/flop to reset it by reading it
  ///
   //$BX=0000000001000000b;
   $CH=16;     //Index of first register to write
   $CL=21-16;  //Number of registers to write
   $WIDESI=CGA_320x200x256AttributeRegs+16;
   stdVGA_set_Attribute_regs();



  //Enable the capability of reading the palette.
  //Otherwise, the screen will stay absolutely black!:
  ///
   stdVGA_set_Attribute_regs__EnablePalette();


 //Turn monitor output on (this assumes that the register
 //set values we are using keep the Sequencer's Screen Off bit
 //off at all times, to not defeat the very purpose of this
 //"protection"):
 ///
  stdVGA_Sequencer_Monitor_On();


 pop $WIDESI;
 pop $WIDECX;
 pop $WIDEBX;
 pop $WIDEAX;
}

Y este es en Ensamblador (bastante menos legible y modificable, especialmente si leemos el resto del código en el ZIP):
Código:
set_mode_MCGA_320x200x256:
push eax
push ebx
push ecx
push esi



mov bx,0000000001000000b;



call stdVGA_Sequencer_Monitor_Off;


mov al,[CGA_320x200x256Gen__MiscOutputReg];
call stdVGA_set_Miscellaneous_Output_Register;


mov al,[CGA_320x200x256Gen__FeatureControlReg];
call stdVGA_set_Feature_Control_Register;



mov ch,0;
mov cl,5;
mov esi,CGA_320x200x256SequencerRegs
call stdVGA_set_Sequencer_regs;



mov cl,00000000b;
call stdVGA_protect_unprotect_CRTC_regs;


mov ch,0;
mov cl,25;
mov esi,CGA_320x200x256CRTCRegs
call stdVGA_set_CRTC_regs;



mov cl,10000000b;
call stdVGA_protect_unprotect_CRTC_regs;



mov ch,0;
mov cl,9;
mov esi,CGA_320x200x256GraphicsRegs
call stdVGA_set_Graphics_regs;



mov ch,16;
mov cl,5;
mov esi,CGA_320x200x256AttributeRegs+16;
call stdVGA_set_Attribute_regs;


call stdVGA_set_Attribute_regs__EnablePalette;



call stdVGA_Sequencer_Monitor_On;



pop esi
pop ecx
pop ebx
pop eax
ret






Si hay registros que no están disponibles se pueden implementar internamente usando otros registros o variables (y optimizaciones), tal como estructuras altamente complejas se implementan siempre en software, en memoria. El resultado es código de Ensamblador fácil de reusar, tanto como C.

Al final, la herramienta nos ha permitido compilar ese código exacto en una variedad de arquitecturas, aunque en algunas se refleje exactamente, en otras parcialmente, y en otras sea internamente diferente. Pero lo importante es que un esfuerzo de depuración único nos permite usar el mismo código fuente de forma portable, desde el punto de vista de usabilidad inmediata del mismo código (puede ser beneficioso para abstraer adicionalmente código específico de plataformas, para que sea mucho más reusable).

Emular elementos pequeños como registros es tan o más eficiente que usar estructuras, porque son datos más simples y pequeños.

Sería un tipo de paravirtualización simple (para tareas de nivel de sistema se necesita crear convenciones más cuidadosamente, pero es posible cubrir compromisos razonables que normalicen diferentes arquitecturas), y no es cuestión de macros sino de crear un compilador propiamente dicho que se encargue de traducir todo lo que sea necesario para el verdadero código Ensamblador final. Es difícil (tanto como crear un GCC), pero técnicamente es posible.

En el link anterior explicaba una de muchas convenciones que se pueden usar para hacer que el código sea más portable.

Por ejemplo, si la convención de nuestro programa es usar el registro más grande posible, se puede usar $WIDEAX, lo que sería $EAX en 32 bits y RAX en 64 bits, y mayores en el futuro. Si deseamos usar $RAX en todos los modos menores a 32 bits, debería implementarse como variable además de optimizaciones (que pueden ser opcionales).


Aquí tengo un proyecto que creé hace un tiempo que tiene la inteción de enviarle comandos a los periféricos desde una consola nativa de DOS (y emular registros del CPU para poder enviarle interrupciones paso a paso):

Proyecto LowEST (Inglés)

El código fuente está escrito en RealC, y también incluye el código de Ensamblador equivalente. Una función en RealC es menos confusa que su misma versión en Ensamblador, pero realmente es Ensamblador más fácil de leer con potencial de ser totalmente portable:

RealC
Código:
function sys_get_args()
{
 asm pushad

  $ESI = 0x81;       ;//Start of command-line string
  $EDI = sys_argv;
  $CL  = byte[0x80]; ;//Size of command-line string


  while($CL != 0)
  {
    if( byte[$ESI]!=0x20 && byte[$EDI]!=0x0D )
    {
     dword[sys_argc]++;

     dword[$EDI]=$ESI;
     $EDI+=4;

     sys_args_last_arg_char();
     dword[$EDI]  = $EAX;
     dword[$EDI] -= $ESI;
     $CL-=[$EDI];


     $ESI=$EAX;
     $EDI+=4;
     continue;
    }


   ;//These 2 instructions are only in case
   ;//the characters are 0x20 or 0x0D, and the
   ;//"continue" just above avoids it from being
   ;//run if we processed actual characters in this
   ;//iteration:
   ;;
    $ESI++;
    $CL--;
  }

 asm popad
}



align 16                               ;//DEBUG STRING
db "int argc void *argv             "  ;//DEBUG STRING
 sys_argc dd 0
 sys_argv times 128 dd 0

align 16                               ;//DEBUG STRING
db "       int argc void *argv {END}"  ;//DEBUG STRING




function /*$EAX */sys_args_last_arg_char()
{
 asm push ecx


  $EAX=$ESI;

  while($CL != 0)
  {
    if( byte[$EAX]==0x20 || byte[$EAX]==0x0D )
    break;

    $EAX++;
    $CL--;
  }

 asm pop ecx
}

Ensamblador
Código:
sys_get_args:
  pushad
    mov esi,0x81
    mov edi,sys_argv
    mov cl,[0x80]




   .while_ln28:
   cmp cl,0
   jz .while_ln28_end
       cmp byte[esi],0x20
       je .not_if_ln28
       cmp byte[esi],0x0D
       je .not_if_ln28

       inc dword[sys_argc]

       mov dword[edi],esi
       add edi,4


       call sys_args_last_arg_char

       mov dword[edi],eax
       sub dword[edi],esi
       sub cl,[edi]

        mov esi,eax
        add edi,4

       jmp .while_ln28

     .not_if_ln28:

   ;//These 2 instructions are only in case
   ;//the characters are 0x20 or 0x0D, and the
   ;//"continue" just above avoids it from being
   ;//run if we processed actual characters in this
   ;//iteration:
   ;;
    inc esi
    dec cl

   jmp .while_ln28
   .while_ln28_end:

  popad
ret



align 16
db "int argc void *argv             "
 sys_argc dd 0
 sys_argv times 128 dd 0

align 16
db "       int argc void *argv {END}"



sys_args_last_arg_char:
  push ecx
    mov eax,esi

   .while_ln74:
   cmp cl,0
   jz .while_ln74_end
      cmp byte[eax],0x20
      je .while_ln74_end
      cmp byte[eax],0x0D
      je .while_ln74_end


      inc eax
      dec cl

   jmp .while_ln74
   .while_ln74_end:

  pop ecx
ret


Si se tiene experiencia en crear programas de Windows en Ensamblador desde el formato del Portable Ejecutable, entonces sería mucho más fácil con un lenguaje como RealC, sin necesidad de linkers o compiladores, solo un ensamblador.

Ensamblador
Código:
;NOTA: Ensamblar con el comando:
;
;        NASM pehead.asm -o pehead.exe


EXE_start:

bits 32

alig equ 16


%define round(n, r) (((n+(r-1))/r)*r)



DOS_stub_start:
  db 'MZ'


  times 0x3A db 0


  dd PEhead


DOS_stub_end:
DOS_stub_SZ equ (DOS_stub_end-DOS_stub_start)


PE_head_start:
  PEhead:

  PEhead.Signature            db 'P','E',0,0

  PEhead.Machine              dw 0x14C

  PEhead.NumberOfSections     dw 1

  PEhead.TimeDateStamp        dd 0

  PEhead.PointerToSymbolTable dd 0

  PEhead.NumberOfSymbols      dd 0

  PEhead.SizeOfOptionalHeader dw 4

  PEhead.Characteristics      dw 0x0103

PE_head_end:
PE_head_SZ equ (PE_head_end-PE_head_start)



Opt_Head_start:
  OptHead:

  OptHead.Magic                   dw 0x10B
  OptHead.MajorLinkerVersion      db 8
  OptHead.MinorLinkerVersion      db 0
  OptHead.SizeOfCode              dd round(codesize,alig) ;1024 ;Code_SZ
  OptHead.SizeOfInitializedData   dd 0
  OptHead.SizeOfUninitializedData dd codesize ;1024
  OptHead.AddressOfEntryPoint     dd PrgEntry
  OptHead.BaseOfCode              dd codesize ;1024
  OptHead.BaseOfData              dd PrgEntry
  OptHead.ImageBase               dd 0x400000
  OptHead.SectionAlignment        dd alig
  OptHead.FileAlignment           dd alig
  OptHead.MajorOSVersion          dw 4
  OptHead.MinorOSVersion          dw 0
  OptHead.MajorImageVersion       dw 0
  OptHead.MinorImageVersion       dw 0
  OptHead.MajorSubsystemVersion   dw 4
  OptHead.MinorSubsystemVersion   dw 0
  OptHead.Win32VersionValue       dd 0
  OptHead.SizeOfImage             dd round(hdrsize,alig)+round(codesize,alig) ;1024 ;EXE_SZ
  OptHead.SizeOfHeaders           dd round(hdrsize,alig) ;Headers_SZ
  OptHead.Checksum                dd 0
  OptHead.Subsystem               dw 2
  OptHead.DllCharacteristics      dw 0
  OptHead.SizeOfStackReserve      dd 0
  OptHead.SizeOfStackCommit       dd 0
  OptHead.SizeOfHeapReserve       dd 0
  OptHead.SizeOfHeapCommit        dd 0
  OptHead.LoaderFlags             dd 0
  OptHead.NumberOfRvaAndSizes     dd 3
    OptHead.ExportTable.VirtualAddress dd 0
    OptHead.ExportTable.Size           dd 0

    OptHead.ImportTable.VirtualAddress dd ImportDirectoryTable
    OptHead.ImportTable.Size           dd ImportDirectoryTable_SZ

    OptHead.ResourceTable.VirtualAddress dd ResourceTable
    OptHead.ResourceTable.Size           dd 4096 ;ResourceTable_SZ

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0
Opt_Head_end:
Opt_Head_SZ equ (Opt_Head_end-Opt_Head_start)



hdrsize equ $ - $$



Headers_SZ equ $-$$ ;(Opt_Head_SZ+PE_head_SZ+DOS_stub_SZ)






db ".code"
times 3 db 0

_virtualsize dd 2048
_virtualaddress dd PrgEntry
_sizeofrawdata dd 2048
_pointertorawdata dd PrgEntry
_pointertorelocations dd 0
_pointertolinenumbers dd 0
_numberofrelocations dw 0
_numberoflinenumbers dw 0
_characteristics dd 0x60000020



db ".rsrc"
times 3 db 0

virtualsize dd 2048
virtualaddress dd ResourceTable
sizeofrawdata dd 2048
pointertorawdata dd ResourceDirectoryEntry
pointertorelocations dd 0
pointertolinenumbers dd 0
numberofrelocations dw 0
numberoflinenumbers dw 0
characteristics dd 0x50000040





align 16
PrgEntry:
align 16
    push dword 0x20
    push dword str1+0x400000
    push dword str2+0x400000
    push dword 0
    call dword[ImportAddressTable.1_array0+0x400000]

    push dword 0x20
    push dword str1+0x400000
    push dword str2+0x400000
    push dword 0
    call dword[ImportAddressTable.1_array0+0x400000]

    push dword 0x20
    push dword str1+0x400000
    push dword str2+0x400000
    push dword 0
    call dword[ImportAddressTable.1_array0+0x400000]

    push dword 0x20
    push dword str1+0x400000
    push dword str2+0x400000
    push dword 0
    call dword[ImportAddressTable.1_array0+0x400000]
ret


align 4
str1 db "Stringz 1",0
align 4
str2 db "Srins 2",0
align 4
str3 db "Strins a3",0


;align 1048576



align 16
db "[EOF]",0










align 16
ResourceTable:




;align 8
;






ResourceDirectoryEntry:


ResourceDirectoryTable0:
  ResourceDirectoryTable0.Characteristics     dd 0
  ResourceDirectoryTable0.Time_DateStamp      dd 0x49DDFF5E
  ResourceDirectoryTable0.MajorVersion        dw 0
  ResourceDirectoryTable0.MinorVersion        dw 0
  ResourceDirectoryTable0.NumberOfNameEntries dw 0
  ResourceDirectoryTable0.NumberOfIDEntries   dw 1

    ResourceDirectoryEntry1:
      ResourceDirectoryEntry1.IntegerID           dd 3
      ResourceDirectoryEntry1.EntryRVA            dd 0x80000000+ResourceDirectoryTable2 ;(ResourceDirectoryTable2-ResourceTable)

        ResourceDirectoryTable2:
          ResourceDirectoryTable2.Characteristics     dd 0
          ResourceDirectoryTable2.Time_DateStamp      dd 0x49DDFF5E
          ResourceDirectoryTable2.MajorVersion        dw 0
          ResourceDirectoryTable2.MinorVersion        dw 0
          ResourceDirectoryTable2.NumberOfNameEntries dw 0
          ResourceDirectoryTable2.NumberOfIDEntries   dw 1


            ResourceDirectoryEntry3:
              ResourceDirectoryEntry3.IntegerID           dd 1
              ResourceDirectoryEntry3.EntryRVA            dd ResourceDirectoryTable4 ;(ResourceDirectoryTable4-ResourceTable)


                ResourceDirectoryTable4:
                  ResourceDirectoryTable4.Characteristics     dd 0
                  ResourceDirectoryTable4.Time_DateStamp      dd 0x49DDFF5E
                  ResourceDirectoryTable4.MajorVersion        dw 0
                  ResourceDirectoryTable4.MinorVersion        dw 0
                  ResourceDirectoryTable4.NumberOfNameEntries dw 0
                  ResourceDirectoryTable4.NumberOfIDEntries   dw 1

                    ResourceDirectoryEntry5:
                      ResourceDirectoryEntry5.IntegerID           dd 0
                      ResourceDirectoryEntry5.EntryRVA            dd ResourceDataEntry6 ;(ResourceDataEntry6-ResourceTable)


                        ResourceDataEntry6:
                          ResourceDataEntry6.DataRVA                  dd vsico
                          ResourceDataEntry6.Size                     dd 1024 ;vsico_SZ
                          ResourceDataEntry6.CodePage                 dd 0
                          ResourceDataEntry6.Reserved                 dd 0



;ResourceDirectoryEntry:
;  ResourceDirectoryEntry.NameRVA             dd namerva
;  ResourceDirectoryEntry.IntegerID           dd 3
;  ResourceDirectoryEntry.DataEntryRVA        dd ResourceDirectoryTable
;  ResourceDirectoryEntry.SubdirectoryRVA     dd 0
;
;
;
;ResourceDirectoryTable:
;  ResourceDirectoryTable.Characteristics     dd 0
;  ResourceDirectoryTable.Time_DateStamp      dd 0
;  ResourceDirectoryTable.MajorVersion        dw 8
;  ResourceDirectoryTable.MinorVersion        dw 0
;  ResourceDirectoryTable.NumberOfNameEntries dw 1
;  ResourceDirectoryTable.NumberOfIDEntries   dw 1
;
;
;
;ResourceDataEntry:
;  ResourceDataEntry.DataRVA                  dd vsico
;  ResourceDataEntry.Size                     dd vsico_SZ
;  ResourceDataEntry.CodePage                 dd 0
;  ResourceDataEntry.Reserved                 dd 0



align 16
vsico:
;incbin "bc.ico"

vsico_SZ equ $-vsico


ResourceTable_SZ equ $-ResourceTable

















ImportDirectoryTable:
ImportDirectoryTable_start:
   ImportTable.ImportLookupTableRVA_array0  dd ImportLookupTable_array0
   ImportTable.Time_DateStamp_array0        dd 0
   ImportTable.ForwarderChain_array0        dd 0
   ImportTable.NameRVA_array0               dd DLL_name_array0
   ImportTable.ImportAddressTableRVA_array0 dd ImportAddressTable_array0

   ImportTable.ImportLookupTableRVA_array1  dd 0
   ImportTable.TimeDateStamp_array1         dd 0
   ImportTable.ForwarderChain_array1        dd 0
   ImportTable.NameRVA_array1               dd 0
   ImportTable.ImportAddressTableRVA_array1 dd 0





ImportDirectoryTable_end:
ImportDirectoryTable_SZ equ (ImportDirectoryTable_end-ImportDirectoryTable_start)


ImportAddressTable_array0:
   ImportAddressTable.1_array0 dd Hint_NameTable_array0 ;0x80000000+477
   ImportAddressTable.2_array0 dd 0


ImportLookupTable_array0:
   ImportLookupTable.Ordinal_Name_OrdinalNum_array0 dd Hint_NameTable_array0 ;0x80000000+477
   ImportLookupTable.Hint_NameTableRVA_array0       dd 0




Hint_NameTable_array0:
   dw 0x1DC
   db "MessageBoxA",0



DLL_name_array0:
db "USER32.dll",0



codesize equ $ - PrgEntry


namerva db "ICON",0


EXE_end:
EXE_SZ equ round((EXE_end-EXE_start),alig)

Code_SZ equ round(($-PrgEntry),alig)

Y nada impide usar el código resultante enlazado con código objeto de C o C++, y habríamos programado en Ensamblador con un nivel de claridad y mantenibilidad comparable al de C.





Hay muchas otras convenciones en las que pensar, pero esto requiere un nivel dramáticamente alto en creación de compiladores optimizadores, convenciones de llamada estándar, y lenguajes como C y C++ (para integrarlos), además de muchos estándares para poder hacer algo realmente utilizable que interactúe bien con el resto del mundo real. Eso es lo que habría que aprender a implementar desde cero para que este tipo de ideas de un Ensamblador portable pudiera extenderse.

Y pensándolo bien, si esto llegara por ejemplo al navegador web, además de usar javascript y HTML5, como para correr ese Ensamblador o emular código x86 ya binario, el Ensamblador tomaría un auge increíble y entonces, gracias a la emulación en algo tan usado como el navegador web, en aplicaciones de usuario, tendría más que sentido preocuparse por mantener y revivir librerías buenas de Ensamblador en un lenguaje/sintaxis legibles y sobre todo tan portable como Java, pero más extensible por ser principalmente código x86 y/o ARM (y después incluyendo Ensambladores del tipo del que se usa en lenguajes/entornos como ACPI o de aceleradores gráficos, eventualmente).


« Última modificación: 25 Febrero 2013, 20:33 pm por ~ » En línea

Sitio web (si la siguiente imagen no aparece es porque está offline):
x64core


Desconectado Desconectado

Mensajes: 1.908


Ver Perfil
Re: ¿Que libro de asm quisieras leer que no encuentras en la internet ?
« Respuesta #13 en: 25 Febrero 2013, 22:00 pm »

Lo mismo que hace portables a C o C++ (hacer ciertas conversiones entre distintas arquitecturas, o dejar las instrucciones como están) es lo que haría al Ensamblador portable en los mismos términos, pero por una u otra razón nadie se ha interesado hasta ahora en resolver ese problema.
No solo es el termino portable, además es la facilidad a agregar modificaciones y correcciones , por ejemplo que hay acerca de agregar variables,
array locales, en ensamblador se tendria que reescribir la completa funcion en cambio en C/C++ es simplemente agregar el tipo y nombre de la variable(s)
y luego el compilador se encarga de todo los calculos, entiendo que podría hacerse un compilador de tal idea ( no he dicho que no es posible )

Pero por ejemplo para ingeniería inversa, en los casos en los que no se puede representar código con C, un lenguaje como este sería la mejor opción, además de hacer que sea más fácil leer desensamblajes enormes.[/b]
Que quieres decir? Te estas refiriendo en que los desemsabladores mostrarian tal sintaxis en lugar, creo que los desemsambladores se hicieron para tal caso
mostrar totalmente las instrucciones de un programa como tal, diferente es poder representar algun tipo de Pseudocodigo para el desensamblaje.

La realidad es que hay tareas de programación que solo se ven elegantes con código de tan bajo nivel como este; y hay otras tareas que solo se ven elegantes con lenguajes a nivel de C o C++. Por eso sería mejor un compilador capaz de usar diferentes lenguajes de forma nativa, para que cada tarea sea lo más elegante y legible posible en su dimensión.

Por ejemplo, sea dentro o fuera de Windows, si lo que queremos es programar registros gráficos VGA estándar o no estándar, lo mejor es usar un lenguaje claro y portable, de más bajo que C. Eso hará el código extremadamente elegante.

Estas hablando de saber varios lenguajes de programación para hacer cada tipo de tareas?
No crees que es mucho? Si lo que se quiere es ahorrar tiempo, lo que quiero decir es, sabemos que algunos tareas se hacen más rapido con lenguajes de alto nivel a diferencia de "medios"/bajos, Pero agregar elegancia a un lenguaje? Más elegancia de lo que un lenguaje como C++ puede tener? Yo creo en que un lenguaje de programación es un lenguaje como tal, diferente es que una tarea en comun luce dependiendo en que lenguaje de programación fue hecha, así de simple.


Librería VGA Estándar (para 16, 32 y 64 bits, con RealC)
Por ejemplo este es código de RealC para cambiar modos en VGA:
Lo unico que veo son llamadas y llamadas a funciones que utilizan ensamblador en linea, con estilo de sintaxis C.
Aquí el tema es la potabilidad, es lo realmente creo que interesa, hay muchos lenguajes con estilo de sintaxis C o nada interesante realmente.


Y este es en Ensamblador (bastante menos legible y modificable, especialmente si leemos el resto del código en el ZIP):
Mira lo que haces, estas comparando el lenguaje lenguaje ensamblador y un lenguaje de estilo sintaxis C y hablando de legibilidad y de modificabilidad?
Eso es tan obvio, si no hay más de las muchas diferencias hay entre ensamblador y C existen?

Aquí tengo un proyecto que creé hace un tiempo que tiene la inteción de enviarle comandos a los periféricos desde una consola nativa de DOS (y emular registros del CPU para poder enviarle interrupciones paso a paso):

Proyecto LowEST (Inglés)

El código fuente está escrito en RealC, y también incluye el código de Ensamblador equivalente. Una función en RealC es menos confusa que su misma versión en Ensamblador, pero realmente es Ensamblador más fácil de leer con potencial de ser totalmente portable:
Mostrar tu código esta bien, pero como digo de nuevo aqui el tema es que dices que es conveniente, posible hacer que el lenguaje ensamblador sea portable.
La verdad me gustaría mirar ese compilador o algo interesante sobre tal tema y no comparación entre lenguajes.

Si se tiene experiencia en crear programas de Windows en Ensamblador desde el formato del Portable Ejecutable, entonces sería mucho más fácil con un lenguaje como RealC, sin necesidad de linkers o compiladores, solo un ensamblador.
Ensamblador
Código:
;NOTA: Ensamblar con el comando:
;
;        NASM pehead.asm -o pehead.exe


EXE_start:

bits 32

alig equ 16


%define round(n, r) (((n+(r-1))/r)*r)



DOS_stub_start:
  db 'MZ'


  times 0x3A db 0


  dd PEhead


DOS_stub_end:
DOS_stub_SZ equ (DOS_stub_end-DOS_stub_start)


PE_head_start:
  PEhead:

  PEhead.Signature            db 'P','E',0,0

  PEhead.Machine              dw 0x14C

  PEhead.NumberOfSections     dw 1

  PEhead.TimeDateStamp        dd 0

  PEhead.PointerToSymbolTable dd 0

  PEhead.NumberOfSymbols      dd 0

  PEhead.SizeOfOptionalHeader dw 4

  PEhead.Characteristics      dw 0x0103

PE_head_end:
PE_head_SZ equ (PE_head_end-PE_head_start)



Opt_Head_start:
  OptHead:

  OptHead.Magic                   dw 0x10B
  OptHead.MajorLinkerVersion      db 8
  OptHead.MinorLinkerVersion      db 0
  OptHead.SizeOfCode              dd round(codesize,alig) ;1024 ;Code_SZ
  OptHead.SizeOfInitializedData   dd 0
  OptHead.SizeOfUninitializedData dd codesize ;1024
  OptHead.AddressOfEntryPoint     dd PrgEntry
  OptHead.BaseOfCode              dd codesize ;1024
  OptHead.BaseOfData              dd PrgEntry
  OptHead.ImageBase               dd 0x400000
  OptHead.SectionAlignment        dd alig
  OptHead.FileAlignment           dd alig
  OptHead.MajorOSVersion          dw 4
  OptHead.MinorOSVersion          dw 0
  OptHead.MajorImageVersion       dw 0
  OptHead.MinorImageVersion       dw 0
  OptHead.MajorSubsystemVersion   dw 4
  OptHead.MinorSubsystemVersion   dw 0
  OptHead.Win32VersionValue       dd 0
  OptHead.SizeOfImage             dd round(hdrsize,alig)+round(codesize,alig) ;1024 ;EXE_SZ
  OptHead.SizeOfHeaders           dd round(hdrsize,alig) ;Headers_SZ
  OptHead.Checksum                dd 0
  OptHead.Subsystem               dw 2
  OptHead.DllCharacteristics      dw 0
  OptHead.SizeOfStackReserve      dd 0
  OptHead.SizeOfStackCommit       dd 0
  OptHead.SizeOfHeapReserve       dd 0
  OptHead.SizeOfHeapCommit        dd 0
  OptHead.LoaderFlags             dd 0
  OptHead.NumberOfRvaAndSizes     dd 3
    OptHead.ExportTable.VirtualAddress dd 0
    OptHead.ExportTable.Size           dd 0

    OptHead.ImportTable.VirtualAddress dd ImportDirectoryTable
    OptHead.ImportTable.Size           dd ImportDirectoryTable_SZ

    OptHead.ResourceTable.VirtualAddress dd ResourceTable
    OptHead.ResourceTable.Size           dd 4096 ;ResourceTable_SZ

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0

    dd 0
    dd 0
Opt_Head_end:
Opt_Head_SZ equ (Opt_Head_end-Opt_Head_start)



hdrsize equ $ - $$



Headers_SZ equ $-$$ ;(Opt_Head_SZ+PE_head_SZ+DOS_stub_SZ)






db ".code"
times 3 db 0

_virtualsize dd 2048
_virtualaddress dd PrgEntry
_sizeofrawdata dd 2048
_pointertorawdata dd PrgEntry
_pointertorelocations dd 0
_pointertolinenumbers dd 0
_numberofrelocations dw 0
_numberoflinenumbers dw 0
_characteristics dd 0x60000020



db ".rsrc"
times 3 db 0

virtualsize dd 2048
virtualaddress dd ResourceTable
sizeofrawdata dd 2048
pointertorawdata dd ResourceDirectoryEntry
pointertorelocations dd 0
pointertolinenumbers dd 0
numberofrelocations dw 0
numberoflinenumbers dw 0
characteristics dd 0x50000040





align 16
PrgEntry:
align 16
    push dword 0x20
    push dword str1+0x400000
    push dword str2+0x400000
    push dword 0
    call dword[ImportAddressTable.1_array0+0x400000]

    push dword 0x20
    push dword str1+0x400000
    push dword str2+0x400000
    push dword 0
    call dword[ImportAddressTable.1_array0+0x400000]

    push dword 0x20
    push dword str1+0x400000
    push dword str2+0x400000
    push dword 0
    call dword[ImportAddressTable.1_array0+0x400000]

    push dword 0x20
    push dword str1+0x400000
    push dword str2+0x400000
    push dword 0
    call dword[ImportAddressTable.1_array0+0x400000]
ret


align 4
str1 db "Stringz 1",0
align 4
str2 db "Srins 2",0
align 4
str3 db "Strins a3",0


;align 1048576



align 16
db "[EOF]",0










align 16
ResourceTable:




;align 8
;






ResourceDirectoryEntry:


ResourceDirectoryTable0:
  ResourceDirectoryTable0.Characteristics     dd 0
  ResourceDirectoryTable0.Time_DateStamp      dd 0x49DDFF5E
  ResourceDirectoryTable0.MajorVersion        dw 0
  ResourceDirectoryTable0.MinorVersion        dw 0
  ResourceDirectoryTable0.NumberOfNameEntries dw 0
  ResourceDirectoryTable0.NumberOfIDEntries   dw 1

    ResourceDirectoryEntry1:
      ResourceDirectoryEntry1.IntegerID           dd 3
      ResourceDirectoryEntry1.EntryRVA            dd 0x80000000+ResourceDirectoryTable2 ;(ResourceDirectoryTable2-ResourceTable)

        ResourceDirectoryTable2:
          ResourceDirectoryTable2.Characteristics     dd 0
          ResourceDirectoryTable2.Time_DateStamp      dd 0x49DDFF5E
          ResourceDirectoryTable2.MajorVersion        dw 0
          ResourceDirectoryTable2.MinorVersion        dw 0
          ResourceDirectoryTable2.NumberOfNameEntries dw 0
          ResourceDirectoryTable2.NumberOfIDEntries   dw 1


            ResourceDirectoryEntry3:
              ResourceDirectoryEntry3.IntegerID           dd 1
              ResourceDirectoryEntry3.EntryRVA            dd ResourceDirectoryTable4 ;(ResourceDirectoryTable4-ResourceTable)


                ResourceDirectoryTable4:
                  ResourceDirectoryTable4.Characteristics     dd 0
                  ResourceDirectoryTable4.Time_DateStamp      dd 0x49DDFF5E
                  ResourceDirectoryTable4.MajorVersion        dw 0
                  ResourceDirectoryTable4.MinorVersion        dw 0
                  ResourceDirectoryTable4.NumberOfNameEntries dw 0
                  ResourceDirectoryTable4.NumberOfIDEntries   dw 1

                    ResourceDirectoryEntry5:
                      ResourceDirectoryEntry5.IntegerID           dd 0
                      ResourceDirectoryEntry5.EntryRVA            dd ResourceDataEntry6 ;(ResourceDataEntry6-ResourceTable)


                        ResourceDataEntry6:
                          ResourceDataEntry6.DataRVA                  dd vsico
                          ResourceDataEntry6.Size                     dd 1024 ;vsico_SZ
                          ResourceDataEntry6.CodePage                 dd 0
                          ResourceDataEntry6.Reserved                 dd 0



;ResourceDirectoryEntry:
;  ResourceDirectoryEntry.NameRVA             dd namerva
;  ResourceDirectoryEntry.IntegerID           dd 3
;  ResourceDirectoryEntry.DataEntryRVA        dd ResourceDirectoryTable
;  ResourceDirectoryEntry.SubdirectoryRVA     dd 0
;
;
;
;ResourceDirectoryTable:
;  ResourceDirectoryTable.Characteristics     dd 0
;  ResourceDirectoryTable.Time_DateStamp      dd 0
;  ResourceDirectoryTable.MajorVersion        dw 8
;  ResourceDirectoryTable.MinorVersion        dw 0
;  ResourceDirectoryTable.NumberOfNameEntries dw 1
;  ResourceDirectoryTable.NumberOfIDEntries   dw 1
;
;
;
;ResourceDataEntry:
;  ResourceDataEntry.DataRVA                  dd vsico
;  ResourceDataEntry.Size                     dd vsico_SZ
;  ResourceDataEntry.CodePage                 dd 0
;  ResourceDataEntry.Reserved                 dd 0



align 16
vsico:
;incbin "bc.ico"

vsico_SZ equ $-vsico


ResourceTable_SZ equ $-ResourceTable

















ImportDirectoryTable:
ImportDirectoryTable_start:
   ImportTable.ImportLookupTableRVA_array0  dd ImportLookupTable_array0
   ImportTable.Time_DateStamp_array0        dd 0
   ImportTable.ForwarderChain_array0        dd 0
   ImportTable.NameRVA_array0               dd DLL_name_array0
   ImportTable.ImportAddressTableRVA_array0 dd ImportAddressTable_array0

   ImportTable.ImportLookupTableRVA_array1  dd 0
   ImportTable.TimeDateStamp_array1         dd 0
   ImportTable.ForwarderChain_array1        dd 0
   ImportTable.NameRVA_array1               dd 0
   ImportTable.ImportAddressTableRVA_array1 dd 0





ImportDirectoryTable_end:
ImportDirectoryTable_SZ equ (ImportDirectoryTable_end-ImportDirectoryTable_start)


ImportAddressTable_array0:
   ImportAddressTable.1_array0 dd Hint_NameTable_array0 ;0x80000000+477
   ImportAddressTable.2_array0 dd 0


ImportLookupTable_array0:
   ImportLookupTable.Ordinal_Name_OrdinalNum_array0 dd Hint_NameTable_array0 ;0x80000000+477
   ImportLookupTable.Hint_NameTableRVA_array0       dd 0




Hint_NameTable_array0:
   dw 0x1DC
   db "MessageBoxA",0



DLL_name_array0:
db "USER32.dll",0



codesize equ $ - PrgEntry


namerva db "ICON",0


EXE_end:
EXE_SZ equ round((EXE_end-EXE_start),alig)

Code_SZ equ round(($-PrgEntry),alig)

Lo que veo es que has hecho un pequeño programa que esta hecho basado en bytes, cadenas definidas y mnemonicos y hablas acerca de que seria más facil
en lugar de usar un linker y como dije ensamblador en linea, pero no veo nada acerca de como resuelves posibles insercion de bytes como instrucciones ( __emit de VC ), o archivos .obj ( como tu dices ) calculo de offsets, y claro implementación de la tabla relocalizadora del formato del .EXE. Realmente creo que hay mucho pero demasiado que falta y esta bien, pero si hablas de hechos que realmente son, nos gustaria mirar un poco acerca de la facilidad del uso.


Hay muchas otras convenciones en las que pensar, pero esto requiere un nivel dramáticamente alto en creación de compiladores optimizadores, convenciones de llamada estándar, y lenguajes como C y C++ (para integrarlos), además de muchos estándares para poder hacer algo realmente utilizable que interactúe bien con el resto del mundo real. Eso es lo que habría que aprender a implementar desde cero para que este tipo de ideas de un Ensamblador portable pudiera extenderse.
Y honestamente no hay mucho que hablar no cite todos tus parrafos donde mencionas la facilidad de la que hablas, escribir es facil , realmente demostrar es distinto si solo muestras un lenguaje en estilo de sintaxis de C y Ensamblador, como dije no seria nuevo o interesante,
A mi lo que me intereso fue lo que mencionabas, hacer que el lenguaje ensamblador fuera portable ( basandome en la idea que tienes: crear un compilador que pueda generar los codigos de operacion respectivos para cada arquitectura apartir de x86 o x86-64? probablemente x86 ) , la idea esta bien incluso me esperaría al menos un POC de un programa hola mundo por lo menos y pues claro tenga todas la facilidades que mencionaste anteriormente. :)

Amigo realmente crees que no estas exagerando?


En línea

Eternal Idol
Kernel coder
Moderador
***
Desconectado Desconectado

Mensajes: 5.905


Israel nunca torturó niños, ni lo volverá a hacer.


Ver Perfil WWW
Re: ¿Que libro de asm quisieras leer que no encuentras en la internet ?
« Respuesta #14 en: 25 Febrero 2013, 22:37 pm »

Piff ...
En línea

La economía nunca ha sido libre: o la controla el Estado en beneficio del Pueblo o lo hacen los grandes consorcios en perjuicio de éste.
Juan Domingo Perón
Páginas: 1 [2] Ir Arriba Respuesta Imprimir 

Ir a:  

WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines