From: robert@nospicedham.prino.org   
      
   On 2018-09-17 10:32, Robert Prins wrote:   
   > On 2018-09-16 20:36, Robert Redelmeier wrote:   
   >> Robert Prins  wrote in part:   
   >>> On 2018-09-15 18:09, Robert Redelmeier wrote:   
   >>>> I have some confidence that even MS w7-64 preserves XMM   
   >>>> registers across syscalls & task swaps.  However, your hot   
   >>>> silicon also has YMM and may need a VEX prefix to correctly   
   >>>> do XMM (overflow wrap).   
   >>>   
   >>> W7(-64) supports AVX since SP1, so that's not the problem,   
   >>> and all my code is either using legacy MMX registers or   
   >>> VEX encoded instructions using the XMM/YMM registers.   
   >>>   
   >>> What is "overflow wrap", and how would I detect it,   
   >>> and would this not also affect MMX instructions?   
   >>   
   >> Every transition [upwards] in wordsize presents the machine   
   >> designer decisions of what to do with the new extra bits.   
   >> Essentially to use them for greater precision or parallel-wise.   
   >  >   
   >> Your YMM registers may not always behave exactly as XMM,   
   >> especially since they are wider.  Do they wrap or saturate on   
   >> overflow, or go into higher bits?  There may be a control word   
   >> to set the desired behaviour.  Or use a prefix to distinguish   
   >> XMM from YMM .  MMX is deep legacy and will be coded as such.   
   >   
   > I'm using XMM registers with VEX coded instructions, which sets the upper   
   halves   
   > to zero, there should be no spillage from XMM into YMM.   
   >   
   > Meanwhile, the mystery has deepened, if I run the program using the data that   
   > causes the zero-divide (when part of the full input file), the program will   
   > happily process it, without any problems!   
   >   
   > So, I decided to comment out the very first trip in the input file, and   
   > lo-and-behold, I get another zero-divide, but this time on data that appears   
   > before the data that caused the original one. Comment out also the second   
   trip,   
   > and the zero-divide abend appears even earlier in the process.   
   >   
   > I've run the program with the VP supplied HEAPCHK unit, and other than the   
   known   
   > allocated memory that isn't freed, there is nothing abnormal showing op.   
   >   
   > I am clueless, totally clueless. And without a way to actually set a   
   breakpoint   
   > on access to XMM0, I don't know what more I can do. (Actually, I'll give it   
   one   
   > last try and maybe rebuild the RTL with traps before and after the standard   
   > _MemNew routine goes to Windows)   
      
   Last message hasn't shown up on x86, but here's a follow-up:   
      
   Tried x65dbg, and tracing into Windows is OK, XMM's are ok, until I hit a:   
      
   74AF2320 | EA 1E27AF74 3300         | jmp far 33:74AF271E                     |   
      
   which doesn't want to be traced, and which comes back with XMM0, yes, set to   
   zero.   
      
   Sigh...   
      
   Robert   
      
      
   --   
   Robert AH Prins   
   robert(a)prino(d)org   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)