flat assembler
Message board for the users of flat assembler.

Index > Macroinstructions > LEA optimization (MOV)

Author
Thread Post new topic Reply to topic
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo 27 Oct 2016, 21:47
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.

Code:
macro LEA a*,b* {
  local dummy
  dummy:
if ~defined NOSMART
  if b eqtype dummy
    mov a,b
  else
    lea a,b
  end if
else
  if b eqtype dummy
    lea a,[b]
  else
    lea a,b
  end if
end if
}
    


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. Shocked
Post 27 Oct 2016, 21:47
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 27 Oct 2016, 23:50
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".
Post 27 Oct 2016, 23:50
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo 28 Oct 2016, 05:07
My question is whether my macro is sufficient (to convert this limited type of usage) or can you point me to a more suitable one?
Post 28 Oct 2016, 05:07
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 28 Oct 2016, 05:29
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.
Post 28 Oct 2016, 05:29
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo 30 Oct 2016, 19:59
Quote:

[ FreeDOS ] G:\TONY>inv-tasm
INVADERS COM 9,194 10-30-16 2:21p
INVADERS.COM 9A476DE7
INVADERS.COM 9A476DE7

[ FreeDOS ] G:\TONY>inv-fasm
INV-FASM COM 9,194 10-30-16 2:21p
INV-FASM.COM FFF22EF9
INV-FASM.COM FFF22EF9

[ FreeDOS ] G:\TONY>disall2
Files inv-fasm.dis and invaders.dis are identical

[ FreeDOS ] G:\TONY>inv-tasm nosmart
INVADERS COM 9,325 10-30-16 2:21p
INVADERS.COM BE91E45C
INVADERS.COM BE91E45C

(Below uses "include 'lea.mac'" and "fasm -DNOSMART=1 inv-fas2.asm"):

[ FreeDOS ] G:\TONY>inv-fas2
INV-FAS2 COM 9,325 10-30-16 2:21p
INV-FAS2.COM 1D830F0E
INV-FAS2.COM 1D830F0E

[ FreeDOS ] G:\TONY>disall2
Files inv-fas2.dis and invaders.dis are identical

[ FreeDOS ] G:\TONY>fasm inv-fas2.asm
flat assembler version 1.71.57 (2734325 kilobytes memory)
4 passes, 9194 bytes.

[ FreeDOS ] G:\TONY>crc32 inv-fas2.com
INV-FAS2.COM FFF22EF9


N.B. Lines like "LEA AX,[BX+SI+5150h]" are assembled correctly whether NOSMART is enabled or not.
Post 30 Oct 2016, 19:59
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
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


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.