Welcome, Guest. Please login or register.

Author Topic: Disassembled ASM problem.  (Read 2842 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline DoobreyTopic starter

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 1876
    • Show all replies
    • http://www.doobreynet.co.uk
Disassembled ASM problem.
« on: November 11, 2004, 12:40:33 AM »
Just wondered if any of you ASM gurus could tell me wtf is going on with the branch to +2 ?
Code: [Select]

; a1=dos
; a0=exec
; on stack =proc struct,temp,dunno
LAB_0206:
MOVEM.L D2-D3/A3-A4/A6,-(A7) ;2D8A: 48E7301A
MOVEA.L 36(A7),A3 ;2D8E: 266F0024 Addr of buffer to a3
MOVEA.L 24(A7),A4 ;2D92: 286F0018

;## Clear whitespace from start.
LAB_0207:
CMPI #$528B,D0 ;2D96: 0C40528B
MOVE.B (A3),D0 ;2D9A: 1013
MOVEQ #32,D1 ;2D9C: 7220
CMP.B D1,D0 ;2D9E: B001 ;## Check for space.
BEQ.S LAB_0207+2 ;2DA0: 67F6
MOVEQ #9,D1 ;2DA2: 7209
CMP.B D1,D0 ;2DA4: B001 ## Check for tab
BEQ.S LAB_0207+2 ;2DA6: 67F0


Seeing as the code at 0207+2 is actually 'addq.l #1,a3', why the compare?
Is it simply some compiler trick to shave a couple of bytes off the exe, and speed it up by not having another branch?
(Both IRA and VDA68k produced the same code)

BTW, I`ll donate £10 to amiga.org if the first person to correctly answer this *isnt* Piru  :-)
On schedule, and suing
 

Offline DoobreyTopic starter

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 1876
    • Show all replies
    • http://www.doobreynet.co.uk
Re: Disassembled ASM problem.
« Reply #1 on: November 11, 2004, 01:00:10 AM »
Quote

Karlos wrote:
 They jump to the address + 2, which assuming a byte based offset actually jumps into the immediate word data of the instruction (the #$528B).


Yup.. and $528B is the 'addq.l #1,a3' I mentioned, and makes sense to what the code does (it`s part of a routine that reads a config file and strips all whitespace and comments from each line before parsing with ParseArgs() )

I figured the compare is just a dummy op to save on branching past the addq when it`s first called, otherwise it`d scan from the 2nd char in the line.

It`s something I`ve seen quite a bit lately..poking about inside the OS. Some parts of the OS are riddled with it, others don`t have it at all.

Anyway, ta for confirming my suspicions.
On schedule, and suing
 

Offline DoobreyTopic starter

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 1876
    • Show all replies
    • http://www.doobreynet.co.uk
Re: Disassembled ASM problem.
« Reply #2 on: November 11, 2004, 01:06:59 AM »
Ditto  :lol:
On schedule, and suing
 

Offline DoobreyTopic starter

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 1876
    • Show all replies
    • http://www.doobreynet.co.uk
Re: Disassembled ASM problem.
« Reply #3 on: November 11, 2004, 02:14:18 AM »
Quote

Piru wrote:
But if the code is to be executed on 68060, it's obviously not recommended.


So would you be horrified to learn that snippet of code came from Setpatch (v44.38)..specifically the NSDPatch part. ?
On schedule, and suing
 

Offline DoobreyTopic starter

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 1876
    • Show all replies
    • http://www.doobreynet.co.uk
Re: Disassembled ASM problem.
« Reply #4 on: November 11, 2004, 02:49:49 AM »
Quote

Karlos wrote:
at best it saves one unconditional branch on loop entry.


I dunno why they didn`t just do..

 subq.l #1,a3
Loop:
 addq.l #1,a3

 It doesn`t make the code any bigger or use any extra branches.
 As you`ve both said, it looks like it was the result of a C compiler being clever(maybe too clever!)
On schedule, and suing