XPost: comp.lang.forth   
   From: albert@nospicedham.cherry   
      
   In article ,   
   R.Wieser  wrote:   
   >Albert,   
   >   
   >> That is not how my assembler rolls.   
   >   
   >You are targetting an X86 processor ? Than it /has/ to.   
   >   
   >> It requires to specify whether byte or XELL.   
   >   
   >/How/ you specify it doesn't matter.  /What/ you specify does.   
   >   
   >> xell size depends on the environment (segment type c.q. 32/64 bit mode)   
   >   
   >:-)   You call it "xell", we call it "native size".  In this newsgroup we   
   >still recognise a 16-bit native size.   
   >   
   >> *and cannot be specified in the instruction itself*   
   >   
   >Look at the three MOVI instructions I posted.   Where do I specify the size   
   >?   I don't.  Its implicitily taken from the target register.    The same   
   >happens when the target is some memory.   
   >   
   >> Most people don't know that there are three instructions   
   >> to swap the RAX and the RBX registers, because their   
   >> assembler allows one.   
   >   
   >Not /allows/, but /generates/ just an arbitrary one of them.   When the   
   >effect is the exactly same, why would you want to be able to pick one   
   >yourself ?   What /good/ would that do you ?   
      
   My ciasdis is a reverse engineering assembler. If you're in the habit   
   of analysing viruses you wouldn't ask this question.   
   >   
   >>>> Then the immediate data is always 32 bit and sign extended.   
   >>   
   >> Confirmed see below   
   >   
   >You have confirmed exactly nothing.    Besides the problem of calling it   
   >"always 32 bit and sign extended" and in your conclusion "Looks like a 64   
   >bit signed constant" <-no idea where you got that from, but certainly not   
   >from your emitted code dump.   
   >   
   >Ask yourself, why would a "MOVI AX, 12" need a four-byte immediate value ?   
   >It doesn't.  It could have generated a 05 0C 00 instead.   
      
   Why do you insist in using a patronizing assembler that bamboozles you?   
   As long as it suits you that is fine but not for this matter it is   
   not.   
      
   >   
   >Also, when I disassemble the emitted bytes in that dump of yours I get   
   >something a bit different:   
   >   
   >58                               pop eax   
   >48                               dec eax   
   >81 C0 0C 00 00 00    add eax, 000000Ch   
   >50                               push eax   
   >48                               dec eax   
   >AD                              lodsd   
   >FF 20                          jmp dword ptr [eax]   
   >   
   >No AX anywhere.    But the 32-bit immediate value now matches the size of   
   >the, instead present, EAX register.   
      
   Okay. Apparently you insist on considering the code as being 32 bits.   
   Small wonder that everything looks 32 bit to you.   
   This is the central genius trick that allowed AMD to introduce 64 bit   
   computing:   
   Repurpose the 4x instruction space as a prefix.   
   Now the  4x prefix in 64 bits mode means that the instruction following is   
   using 64 bit size operands, as well as specifying if any of the extra registers   
   is used.   
   This makes the remainder of your comment irrelevant so I stop here.   
      
   If anbybody want the full story including disassemblies in 64 bit mode,   
   go back to the previous message.   
      
   Groetjes Albert   
      
   >Regards,   
   >Rudy Wieser   
   >   
   >   
   --   
   This is the first day of the end of your life.   
   It may not kill you, but it does make your weaker.   
   If you can't beat them, too bad.   
   albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)