XPost: comp.lang.forth   
   From: address@nospicedham.not.available   
      
   Albert,   
      
   >Sure enough, I got a long constant with   
   > lots of 90 and no crashes.   
      
   Where "lots" equals just four (the difference between a 32- and a 64-bit   
   operand).    Though you might ofcourse have many more, as those (beyond the   
   first four) will than be recognised as NOP instructions.   
      
   ... which you can easily verify by using another value than 0x90.   Like   
   0xCC ( INT 3 - the "breakpoint" instruction).  Than only exactly four extra   
   bytes will /not/ cause your program to behave unexpectedly.   
      
   A suggestion though: Put some 0xCC bytes /after/ the RET instruction too.   
   That way providing to few bytes om immediate data will cause the same effect   
   (caused by executing an INT 3 /after/ the (intended!) RET as providing to   
   many bytes will (caused executing an INT 3 /before/ the intended RET).   
      
   > One thing to add though: this behaviour is different than   
   > the situation where there is an operation with immediate   
   > data.   
      
   No, its /exactly/ the same. The modified-by-the-prefix command  tries to   
   load a 64-bit register, and thus expects expects 8 bytes of immediate data,   
   where the unmodified one tries to load a 32-bit register, and therefore   
   expects just 4 bytes.   
      
   Its the same difference beween   
      
   MOVI AL, {immediate data}   
   MOVI AX, {immediate data}   
   MOVI EAX,{immediate data}   
      
   The size-in-bytes of the immediate data varies with the size of the   
   targetted register.   
      
   > Then the immediate data is always 32 bit and sign extended.   
      
   Nope :   
      
   1) Ot depends on the target register (or memory). See above   
      
   2) (immediate or not) data has /no/ sign.   There are only a few   
   instructions which actually do look at the sign bit.  Notably the   
   conditional jumps and the IMUL and IDIV ones.  Yes, thats right, not even   
   the addition, subtraction and compare instructions themselves care about a   
   value being signed or not.   
      
   3) "and sign extended".   If-and-when that happens that is your FORTH   
   compiler at work - most likely recognising a preceeding minus sign in your   
   sourcecode as an intention to have a negative value stored - and extends the   
   sign /while compiling/ (read: before the program is executed).   
      
   Regards,   
   Rudy Wieser   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)