From: mutazilah@nospicedham.gmail.com   
      
   Next thing I tried was putting the generated assembler   
   into one of my own assembler files. It didn't directly   
   assemble, so I modified it like this:   
      
   public dumplong3   
    x = 0006   
    buf = fffa   
    Line 5910   
   dumplong3:   
   	push	bp   
   	mov	bp,sp   
   	sub	sp,OFFSET L04632   
   	sub	sp,06H   
    Line 5911   
    Line 5912   
    Line 5914   
   	mov	BYTE PTR [bp-6],80   
    Line 5915   
   	mov	BYTE PTR [bp-5],OFFSET 80   
    Line 5916   
   	mov	BYTE PTR [bp-4],OFFSET 80   
    Line 5917   
   	mov	ax,OFFSET 2   
   	sub	ax,WORD PTR y   
   	lea	bx,WORD PTR [bp-6]   
   	add	bx,ax   
   	mov	BYTE PTR ss:[bx],OFFSET 82   
    Line 5918   
   	mov	BYTE PTR [bp-3],OFFSET 80   
    Line 5919   
   	mov	ax,WORD PTR y   
   	add	ax,OFFSET 3   
   	lea	bx,WORD PTR [bp-6]   
   	add	bx,ax   
   	mov	BYTE PTR ss:[bx],OFFSET 83   
    Line 5920   
   	mov	ax,OFFSET 4   
   	push	ax   
   	lea	ax,WORD PTR [bp-6]   
   	mov	dx,ss   
   	push	dx   
   	push	ax   
   	call	FAR PTR dumpbuf   
   	add	sp,OFFSET 6   
    Line 5921   
    Line 5922   
    Line 5922   
   L03803:   
   	mov	sp,bp   
   	pop	bp   
   	retf   
           int 3   
           int 3   
           int 3   
           int 3   
           int 3   
           int 3   
           int 3   
      
   .data   
   y dw 0   
      
      
   The int 3 is an eyecatcher.   
      
   The most suspicious change I made was this:   
      
   	sub	sp,OFFSET L04632   
   	sub	sp,06H   
      
   That label doesn't actually appear in the generated assembler.   
      
   Anyway, the handwritten assembler works!   
      
   So lea is fundamentally fine.   
      
   I then went looking to match the machine code. Here is   
   the handwritten assembler:   
      
                                 558B EC83EC06  ....XX.L.!U....   
   000150  C646FA50 C646FB50 C646FC50 B802002B  .F.P.F.P.F.P...+   
   000160  0600008D 5EFA03D8 36C60752 C646FD50  ....^...6..R.F.P   
   000170  A1000083 C0038D5E FA03D836 C60753B8  .......^...6..S.   
   000180  0400508D 46FA8CD2 52509A00 00000083  ..P.F...RP......   
   000190  C4068BE5 5DCB   
      
   And here is the C code:   
      
                          55 8BEC81EC 0600C646  .......U.......F   
   013310  FA50C646 FB50C646 FC50B802 002B0600  .P.F.P.F.P...+..   
   013320  008D5EFA 03D8C607 52C646FD 50A10000  ..^.....R.F.P...   
   013330  0503008D 5EFA03D8 C60753B8 0400508D  ....^.....S...P.   
   013340  46FA8CD2 52509A00 00000083 C4068BE5  F...RP..........   
   013350  5DCB   
      
   The first thing I noticed was that the x'83' (subtract):   
      
   http://sparksandflames.com/files/x86InstructionChart.html   
      
   is strangely an "add" ('x81') in C, which isn't going to work.   
      
   I tried zapping the add into a subtract, on the assumption   
   that it was a compiler bug, since I think I am using 1.52   
   but I think there is a 1.52C available via patch.   
      
   But the C code still didn't work.   
      
   I suspect that the add is correct, and that label has a   
   value of -6 in it, and so it is meant to work, and may   
   explain why the number of bytes of code is different   
   between the two, as it is perhaps a reference rather   
   than an immediate.   
      
   Still investigating.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)