Joined: 09 Aug 2005
Location: Usono (aka, USA)
LEA optimization (MOV)
Many years ago (2004) I basically hand-translated PSR Invaders 1.1 (DOS, 8086, VGA, 1995) to assemble with other tools (instead of TASM only). In hindsight, I could do a better job, so I've fixed it to separately modify and build cleanly, more simply, with several assemblers (using sed, my favorite tool).
Part of the problem is trying to be byte-for-byte exact, i.e. identical. That's mostly impossible (different instruction encodings that do the exact same thing). But I've worked around all of that. So I can now consistently get the exact same size and exact same x86 instructions, even if the .COM checksums don't always match.
Long story short: part of the problem is the LEA instruction, or at least his (mis)use of it. There are 132 instances of him doing "LEA BX,MyLabel", which TASM automatically converted to (one byte shorter) "MOV" (unless "NOSMART" directive was used). A86 also does this by default unless +G2 is specified. AFAIK, they were copying older MASM behavior, but even MASM stopped doing that circa version 6.1 (suggesting to use "opattr" inside a macro instead). So JWasm too doesn't directly optimize this (but it seems to have a bug with "opattr", at least in JWasmR).
The kludgy imperfect way is to use sed. It works, but it's not perfect by any means. So I weakly tried to write a FASM macro. It seems to work, but I don't feel comfortable with it. I'm really just trying to understand what the "best" solution is.
revolution, I've found at least four LEA macros of yours on this forum, so honestly your advice is probably what I want. It's not crucial, we've all discussed this kind of optimization before (many years ago). I'm just morbidly curious.
I would be happy to help but I don't know what you are asking. I can't find any actual question in your post. It appears as though you are trying to "understand what the 'best' solution is", but you don't define your metric for "best".
Well you do say "it seems to work" and "this limited type of usage". I expect there are cases in the broader realm of source code that your macro would fail (i.e. it isn't fully general) but you don't appear to need it to be fully perfect.
I would suggest this: Since you only need it for this one case then to test it use a disassembler to create a text file and strip the hex bytes just leaving the addresses and the decoded instructions. Then compare the old to the new. When they match then you are done. Unless it uses some type of SMC, or something equally terrible, then as long at the disassembled instructions match then the actual bytes used to generate them are not important.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum