SAD disassembler progress

This is where the BIN Hackers and definition junkies discuss the inner workings of the EEC code and hardware. General tuning questions do not go here. Only technical/hardware-specific/code questions and discussions belong here.

Moderators: cgrey8, EDS50, Jon 94GT, 2Shaker

Post Reply
User avatar
tvrfan
Tuning Addict
Posts: 380
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

SAD disassembler progress

Post by tvrfan » Sun Dec 02, 2018 5:26 pm

Just a quick update, and start a new topic...

I have A9L working with auto detect of subroutine variable arguments, but it has a 'kludge' in it which I don't really like.
At the moment it only shows a list of bytes as arguments, as that is how they are read off. Next step is to work out how they get read/processed, and where an 'answer' is returned (in a register normally) for better arguments display. But it works so far ....

Had to change the way SAD does the scans to make sure subroutines always get to the RET, which got in the way.
Haven't implemented if-then yet emulation either (for CARD etc), only djnz for testing (all of A9L uses djnz for its extract loops).

Slow progress, but getting there.....
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

jsa
Tuning Addict
Posts: 524
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: SAD disassembler progress

Post by jsa » Mon Dec 03, 2018 1:00 am

Thanks for the continued effort, great to hear you are making progress.
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

User avatar
tvrfan
Tuning Addict
Posts: 380
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: SAD disassembler progress

Post by tvrfan » Wed Dec 05, 2018 10:53 pm

DAMN !!! Well I *was* making progress, until I came across THIS... (from CARD)

Code: Select all

4459: f9                  stc                    CY = 1;
445a: cc,18               pop   R18              R18 = pop();
445c: b2,19,1a            ldb   R1a,[R18++]      R1a = [R18++];
445f: b2,19,1b            ldb   R1b,[R18++]      R1b = [R18++];
4462: b2,19,1c            ldb   R1c,[R18++]      R1c = [R18++];
4465: b2,19,1d            ldb   R1d,[R18++]      R1d = [R18++];
4468: d3,05               jnc   446f             if (CY = 0) goto 446f;                # 4 bytes
446a: c9,fa,40            push  40fa             push(@Sub87);                     # + 2 extra bytes 
446d: 20,02               sjmp  4471             goto 4471;

446f: c8,18               push  R18              push(R18);
4471: 91,02,2c            orb   R2c,2            R2c |= 2;
....(to a RET)

   Sub86:
40f8: cc,18               pop   R18              R18 = pop();
   Sub87:
40fa: ae,19,14            ldzbw R14,[R18++]      wR14 = [R18++];
40fd: b2,19,17            ldb   R17,[R18++]      R17 = [R18++];
4100: c8,18               push  R18              push(R18);
which means that the PUSH (from checking Carry flag) causes 2 more bytes (arguments) after processing returns.
This is the same as the A9L PUSHing a different return address for a subroutine too, and my 'kludge' gets over that one, but not THIS bit of code...

I was hoping not to have to maintain a fake stack (currently SAD links code blocks by CALLER in a chain, so a RET simply drops back to caller block.) but now it looks like I might have to....

hmmm.... I'll have to think about this....
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

jsa
Tuning Addict
Posts: 524
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: SAD disassembler progress

Post by jsa » Thu Dec 06, 2018 3:59 am

Yes, indeed.

I have not made note,in CMT, of the reason for having JNC on line 4468 when it is set at line 4459. May as well just jump as best as I can tell.
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

sailorbob
BIN Hacker
Posts: 1652
Joined: Tue Jul 12, 2005 6:10 am

Re: SAD disassembler progress

Post by sailorbob » Thu Dec 06, 2018 10:18 am

Have a look a couple of lines above, at 0x4456, where a different entry point to the subroutine is used.

jsa
Tuning Addict
Posts: 524
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: SAD disassembler progress

Post by jsa » Thu Dec 06, 2018 12:14 pm

:shock: thanks, better get my eyes checked.
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

User avatar
tvrfan
Tuning Addict
Posts: 380
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: SAD disassembler progress

Post by tvrfan » Wed Dec 19, 2018 3:30 pm

Update -
I feel like I'm stuck in the "all alike maze" in the old text adventure game "...you are in a maze of twisty little passages, all alike..." in a kind of multifaceted catch 22.... To cover THIS bit I need logic to do THAT, but THIS bit in CARD needs it to work differently, and THIS bit in here needs another .....

I've got A9L working pretty well now, without the kludge, including the pop() shortcuts (7273 - 7292 approx) , but then as I go, I discover new things in CARD (as posted above) and multibank versions in 22CA which blow my logic assumptions about the way if-then-else and loops are structured, and it falls apart again.

From the Ford viewpoint, it seems that either the compiler/code got a lot more efficient at optimizing the end result, or the programming team did. Those neat little tricks make the code smaller, with more reuse of the same segments, but it makes it harder to unscramble. And there's many ways of writing code to do those same jobs...

So I'm stuck at the moment.....I need a new idea or several....
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

jsa
Tuning Addict
Posts: 524
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: SAD disassembler progress

Post by jsa » Wed Dec 19, 2018 10:01 pm

I think CARD is a conglomeration of different age strategies.

Some sections of code look like GUFB, others look like CDAN and a sprinkle of LHBH1.

Depending on the section of code, the loops are programmed differently. It looks like they plucked a block code from one strat, grabbed something else from others then patched it together.

Lurking is the depths is a 2 digit fault code while all others are 3.
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

User avatar
tvrfan
Tuning Addict
Posts: 380
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: SAD disassembler progress

Post by tvrfan » Thu Dec 20, 2018 10:08 pm

Yes, there is (rightly) a lot of reuse. For example, so far I've only seen 2 1D lookup (function) code versions (OK some with minor variations) and 2 versions of the 2D code (tables). Why reinvent something which works ?? Mathematically and codewise, the way the 2D data is interpolated is very neat and quite clever.

It makes perfect sense to grab different bits of working code and repackage, and perhaps only have to fix up some of the 'glue' which holds them together... We did that all the time - reuse and adapt !!

My problem stems from trying to merge a 'static' tree analysis with an emulation pass for arguments, and expecting the code to always 'flow' the same. I've got some things to try out already ....
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

motorhead1991
Regular
Posts: 100
Joined: Tue Nov 21, 2017 2:32 am

Re: SAD disassembler progress

Post by motorhead1991 » Thu Dec 20, 2018 10:17 pm

tvrfan wrote:
Thu Dec 20, 2018 10:08 pm
Yes, there is (rightly) a lot of reuse. For example, so far I've only seen 2 1D lookup (function) code versions (OK some with minor variations) and 2 versions of the 2D code (tables). Why reinvent something which works ?? Mathematically and codewise, the way the 2D data is interpolated is very neat and quite clever.

It makes perfect sense to grab different bits of working code and repackage, and perhaps only have to fix up some of the 'glue' which holds them together... We did that all the time - reuse and adapt !!

My problem stems from trying to merge a 'static' tree analysis with an emulation pass for arguments, and expecting the code to always 'flow' the same. I've got some things to try out already ....
Sent you a PM, tvr.
1990 Ford Ranger FLH2 conversion. Ford forged/dished pistons, Total Seal file-fit rings, Clevite rod and main bearings, Clevite cam bearings, IHI turbo, Siemens Deka 60lb/hr injectors, Ford slot MAF in custom 3" housing. Moates Quarterhorse with Binary Editor, using the PAAD6 database.

OpenEEC Telegram Chat:
Telegram

teal95
Regular
Posts: 102
Joined: Fri Oct 18, 2002 2:46 pm
Location: Walkerton, IN

Re: SAD disassembler progress

Post by teal95 » Wed Dec 26, 2018 4:09 pm

Realize that important sections that get used frequently (like interpolations) probably got written directly in assembly by the programmers as any efficiency they could gain gets multiplied many times as this chunk of code gets used so often.

It doesn't surprise me that some of the stuff that was passed down from older programs weren't updated at all. I imagine even the compiling was done in chunks and when routines were used it grabbed the already compiled pieces instead of compiling everything every time.

steve
'95 GT - T4M0 x3
'93 notch - A9P
'87 TC - 8UA or LB2 or LA3 x2
'85.5 & '86 SVO - PE x2
'83 & '84 GT turbo - TA x2

Post Reply

Who is online

Users browsing this forum: No registered users and 6 guests