Why auto disassembly is tough

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, 2Shaker, Jon 94GT

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

Why auto disassembly is tough

Post by tvrfan » Mon Jan 29, 2018 3:52 pm

I haven't posted here in a long time. I've been working away from home, amongst other things.

I thought I had come up with a neat solution, and then came along the CARD binary and f*cked it up, yet again.

So, I will release SAD where I've got to, as it's better (I believe) then previous version, but it still doesn't
work right automatically, which was my target. It's a tough problem to solve.

Here's a little lecture as to why. (code examples provided...)

Firstly, disassembly of a binary where the opcodes are of variable lengths is tough, because once you do something wrong,
you get lost, as you don't know where the next opcode truly starts. You also can't go backwards, and have to step through
forwards for each opcode.

Secondly there is always the debate about 'static' versus 'emulate'.

Static goes through and creates a map where the code jumps or calls, and so builds a kind of tree structure.
The problem with this is that 'shortcut' and some clever code can confuse this method.
Sorting out arguments (= data) for subroutines is sometimes difficult if you don't emulate.
This is what SAD does, and it has a kind of 'fingerprint' code match to spot the tricks, which sort of works, ... but....

Emulation means that the setup must emulate every condition and event to find all the code, which creates its own problems.
How do you know the emulation has covered everything ? Also as the code execution may be dependent on values set a long way away,
you HAVE to be VERY CAREFUL about how you handle jumps and 'shortcuts', and make sure the code is emulated in the right order, which
gets tricky when there's a bunch of (possibly nested) jumps to handle

back to what happened -

As you probably now know, or are learning, the standard way to add arguments (data,parameters) to a subroutine for a single bank
binary is like THIS -

Code: Select all


Sub57:

pop   R18              R18 = pop();             # get calling address
ldb   R1a,[R18++]      R1a = [R18++];
ldb   R1b,[R18++]      R1b = [R18++];           # get one word (2 bytes)
ldb   R1c,[R18++]      R1c = [R18++];
ldb   R1d,[R18++]      R1d = [R18++];           # get one word (2 bytes)
push  R18                                       # push modified address back

the code where this is called from looks like this (with binary shown as this makes more sense)

Code: Select all

2a,2d,           scall 41fe             Sub57(4f0,9a40);
f0,04,40,9a      #args                           

at any CALL, the return address is pushed onto the stack, and a RET goes back to that address and drops it off the stack.
What the code above does is to add 4 to that return address, so there are four bytes of data.

A9L already has some extra 'nasty' tricks (nasty for a disassembler that is - it's perfectly good code)

here is the param getter for rolling averages

Code: Select all


3695: cc,38               pop   R38              R38 = pop();                       # This subroutine's return addr
3697: cc,3a               pop   R3a              R3a = pop();                       # Caller subroutine's return addr
3699: b2,3b,3c            ldb   R3c,[R3a++]      R3c = [R3a++];                     
369c: b2,3b,3d            ldb   R3d,[R3a++]      R3d = [R3a++];                     # 3C = Word param from caller
369f: c8,3a               push  R3a              push(R3a);                         # restore caller address (+2)
36a1: c8,38               push  R38              push(R38);                         # restore this return address

This actually gets a word (2 bytes) from the CALLING subroutine (2 levels back), not this one. The two pops and pushes do this.
Note that the first pop to R38 does not get changed, just PUSHed back. (R38 is THIS subr's return address).

also A9L has a JUMP to a subroutine within a subroutine ....a few A9L listings around still have this wrong, as it so happens the error doesn't
cause an invalid opcode (another little gotcha for disassembly processes)

this trick is here -

Code: Select all


 Sub54:

7273: ef,79,08            call  7aef             Sub71(); 
7276: c9,7f,72            push  727f             push(727f); 
7279: 28,12               scall 728d             OCC_chk1(81,6,10,46);              # SCCS Open Circuit Check, pars = E81,limit,bit mask(=SCCS),IO
727b: 81,06,10,46         #args
727f: 28,a4               scall 7325             Sub63();
7281: 91,10,46            orb   R46,10           Scvnt = 1;                         # LSO output line 4 ON (Speed Control Vent)
7284: c9,97,72            push  7297             push(7297);                        # return from 7A76 to this address
7287: 28,06               scall 728f             OCC_chk2(82,4,01,46);              # DOL Open Circuit Check, E82,limit,bit mask(=DOL),IO
7289: 82,04,01,46         #args 

  OCC_chk1:
728d: 28,8a               scall 7319             Sub62();                           # SCCS controls off & stuff?

  OCC_chk2:
728f: e7,e4,07            jump  7a76             goto Test_IO;                      # Open Circuit Check function
   
you can see that the 782f subr simply does a jump to 7a76. this looks like it was patched afterwards to me, as it's pretty messy, with jumps
actually PUSHED (for returns) and arguments extracted by 7a76, but why the jump ?? Why not just CALL 7a76 ??
Frankly, although it works, it doesn't make a lot of sense to do it this way. I had to add a whole raft of code to handle this.

..continued......
Last edited by tvrfan on Tue Jan 30, 2018 4:21 pm, edited 4 times in total.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by tvrfan » Mon Jan 29, 2018 3:55 pm

MORE.......

here is the 'easy' variable argument extract code, which is relatively easy to deal with (A9L)

Code: Select all


77be: a1,1a,00,16         ldw   R16,1a           R16 = 1a;                          # destination is R1a onwards
77c2: cc,3c               pop   R3c              R3c = pop();                       # Return address
77c4: b2,3d,3a            ldb   R3a,[R3c++]      R3a = [R3c++];                     # Get count of bytes required 
77c7: cc,42               pop   R42              R42 = pop();                       # Get Caller's return address
77c9: b2,43,3b            ldb   R3b,[R42++]      R3b = [R42++];                      
77cc: c6,17,3b            stb   R3b,[R16++]      [R16++] = R3b;                      
77cf: e0,3a,f7            djnz  R3a,77c9         R3a--;
                                                 if (R3a != 0) goto 77c9;           # Get bytes reqd. from Caller's into dest. addr
77d2: c8,42               push  R42              push(R42);                         # push back caller's address + bytes 
77d4: c8,3c               push  R3c              push(R3c);                         # push back THIS address plus 1
77d6: f0                  ret                    return;

This allows a subroutine to say "I want x arguments" by calling 77be, like this. those get copied into R1a onwards.

Code: Select all


sub55:

77f9: 2f,c3               scall 77be             GetbytesR1a(3);                   # get 3 data bytes to R1A,B,C
77fb: 03                  #args

77fc: 63,73,02,02,1a      an2w  R1a,[R72+202]    R1a &= Fmem_monitor;
7801: df,04               je    7807             if (R1a != 0)  {   
...

This means effectively, that calls to sub55 have 3 arguments.

OK - so I got all this done in my code, but Ford weren't done yet....

You remember that A9L jump trick in last post ? well, that gets WORSE....

Code: Select all


  OCC_chk2:
728f: e7,e4,07            jump  7a76             goto Test_IO;                      # Open Circuit Check function

...

7a76: 28,29               scall 7aa1             Sub68();                           # load params from stack & OCC base line test of circuit
7a78: ac,1d,20            ldzbw R20,R1d          R20 = (uns)R1d;      

...

7aa1: 28,33               scall 7ad6             Sub70();
7aa3: cc,1e               pop   R1e              R1e = pop();                       # back up stack by one more call
7aa5: 2d,17               scall 77be             GetbytesR1a(4);                    # Get 4 bytes from Grandcaller into R1A
7aa7: 04                  #args
7aa8: c8,1e               push  R1e              push(R1e);       

so this jumps to a subroutine instead of CALLing it, and then that calls a variable parameter subroutine, but adds a THIRD level
so that the caller/jumper to 728f is the one that has 4 parameters ! (think grandcaller)

YUK !! Pretty damn messy code I have to say, the type that gives structured programmers nightmares....(C++, Java, etc)

So I got even that to work, by adding the idea of a POP_level and tracing back in the call tree, with a special for jumps to subroutines.

and then comes along 22ca ....

Code: Select all


04126: cc,2e              pop   R2e              R2e = pop();
04128: 10,00              bank  0
0412a: b2,2f,30           ldb   R30,[R2e++]      R30 = [R2e++];
0412d: 10,00              bank  0
0412f: b2,2f,31           ldb   R31,[R2e++]      R31 = [R2e++];
04132: 10,00              bank  0
04134: b2,2f,32           ldb   R32,[R2e++]      R32 = [R2e++];
04137: 10,00              bank  0
04139: b2,2f,33           ldb   R33,[R2e++]      R33 = [R2e++];
0413c: 3b,80,0a           jb    B3,R80,4149      if (B3_R80 = 0)  {
0413f: 10,00              bank  0
04141: b2,2f,36           ldb   R36,[R2e++]      R36 = [R2e++];
04144: 10,00              bank  0
04146: b2,2f,37           ldb   R37,[R2e++]      R37 = [R2e++]; }
04149: c8,2e              push  R2e              push(R2e);

so this is a 2 bank binary, but it still uses 'old style' pop access (More on multibanks later) with BANK prefix,
which means this subr works only when called from bank 0

But notice that THIS subr has either 4 or 6 bytes, according to a flag (bit 3) in R80 (external to this subr).

So I added extra code to check for a conditional jump instead of a PUSH after the repeated LDB ....

and then I found THIS in the CARD binary, and it finally convinced me that my neat, cherished solution simply isn't
clever enough, and mpaton was right all along - the only way to sort out some of this is by emulation....
B*gger - I'll have to scrap a large part of my work and rewrite chunks to actually emulate a stack and subr calls.

Code: Select all

  

  Sub46:
4069: cc,18               pop   R18              R18 = pop();
406b: b2,19,1a            ldb   R1a,[R18++]      R1a = [R18++];
406e: b2,19,1b            ldb   R1b,[R18++]      R1b = [R18++];
4071: 88,1a,40            cmpw  R40,R1a
4074: d7,03               jne   4079             if (R40 = R1a)  {
4076: 91,02,2c            orb   R2c,2            R2c |= 2; }
4079: 20,7f               sjmp  40fa             goto 40fa;                   # 40fa gets another 2 bytes !!
 ...


  Sub49:
40f8: cc,18               pop   R18              R18 = pop();
40fa: ae,19,14            ldzbw R14,[R18++]      R14 = (uns)[R18++];
40fd: b2,19,17            ldb   R17,[R18++]      R17 = [R18++]; 
4100: c8,18               push  R18              push(R18);
 ...


  Sub67:
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 ((uns) R2c >= 0)  { 
446a: c9,fa,40            push  40fa             push(40fa);                  # ARRGGHHHH !!!!
446d: 20,02               sjmp  4471             goto 4471; }                 # skip push if called sub49
446f: c8,18               push  R18              push(R18); 
4471: 91,02,2c            orb   R2c,2            R2c |= 2;
4474: ad,1a,3e            ldzbw R3e,1a           R3e = (uns)1a; 
4477: 28,26               scall 449f             Sub69(); 


See, this again is perfectly good code, it's simply reusing 40fa-4101 to get two more arguments, calling it from
several places. It saves space. BUT from a disassembly point of view, SAD is looking for a
< POP, LDB with increment, PUSH >, where any of those 3 might repeat, so how the hell am I supposed to tell that this PUSH
is actually a clever CALL ??

There's also a binary (which I can't find at the moment) which uses a flag from its first parameter to decide how many arguments
but it looks like this -

Code: Select all


pop   R18              R18 = pop(); 
ldb   R1a,[R18++]      R1a = [R18++]; 
ldb   R1b,[R18++]      R1b = [R18++]; 
ldb   R1c,[R18++]      R1c = [R18++]; 
ldb   R1d,[R18++]      R1d = [R18++];
jb    B0,R18,4567      if (B0_R1a = 0)  { 
ldzbw R14,[R18++]      R14 = (uns)[R18++];
ldb   R17,[R18++]      R17 = [R18++]; 
push  R18              push(R18);

so 4 or 6 arguments, depending upon the first argument....


and finally, the last straw was this (also in CARD)

Code: Select all

  

40df: cc,3a               pop   R3a              R3a = pop(); 
40e1: 71,fd,2c            an2b  R2c,fd           R2c &= fd;
40e4: ae,3b,14            ldzbw R14,[R3a++]      R14 = (uns)[R3a++];
40e7: b2,3b,17            ldb   R17,[R3a++]      R17 = [R3a++]; 
40ea: e0,39,03            djnz  R39,40f0         R39--;
                                                 if (R39 != 0) goto 40f0; 
40ed: 91,02,2c            orb   R2c,2            R2c |= 2; }
40f0: 28,10               scall 4102             Sub50();
40f2: e0,38,ef            djnz  R38,40e4         R38--;
                                                 if (R38 != 0) goto 40e4; 
40f5: c8,3a               push  R3a              push(R3a);

So TWO OVERLAPPING LOOPS, relying on R38, and R39 to do some type of decode.....

I GIVE UP !!! I can't even see a way to handle this in a static analysis,
as it's dependent upon the outside registers (R39 and R38) which could be set
almost ANYWHERE....

Ok, Fine, I'll look at emulating subroutine calls - OK.... a proper stack structure to keep up

but then in A9L and others, there's quite a lot of THIS....

Code: Select all


81d2: 01,30               clrw  R30              R30 = 0;
81d4: ef,d7,f9            call  7bae             SaveTCode1(77);       # trouble code 77
81d7: 77                  #args
81d8: 91,01,2b            orb   R2b,1 
81db: cc,00               pop   R0               R0 = pop();           # shortcut to grandcaller
81dd: 27,6e               sjmp  814d             goto 814d; } 
81df: f0                  ret                    return;

that pop effectively drops a call level ( = shortcuts a subroutine return) so it too would need to be carefully handled.

[edited a few times for typos and mistakes .....]
Last edited by tvrfan on Tue Jan 30, 2018 4:16 pm, edited 3 times in total.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by tvrfan » Mon Jan 29, 2018 3:57 pm

So, what OS do you guys use ?

I am developing in 64 bit linux now, but can supply 32 or 64 bit Windows versions....

What do you prefer ?

NB this version is CONSOLE based, as that's the easiest for linux, so you will have to type the filename in ....
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by tvrfan » Mon Jan 29, 2018 6:23 pm

I have posted the latest source code to github under project 'EEC-IV-disassembler'.

It may well have bugs.....

Enjoy !!

(tip to motorhead1991 who suggested it.....)
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by jsa » Mon Jan 29, 2018 7:42 pm

Hi tvrfan,

Great hearing from you again and the progress you have made.

Yes the old V0.2 SAD tripped over the whole block of code related to 40f8 and 40df in CARD.
I had pencilled in 8bytes worth of arguments for 40df and 2bytes worth for 40f8.

I'm on Win 7 x64 here if you would, please.
Cheers

John

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

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

Re: Why auto disassembly is tough

Post by tvrfan » Mon Jan 29, 2018 8:04 pm

For info on the source code - I have compiled it with Code:Blocks and also CodeLite, which both have Windows and Linux versions, and support exactly the same source code for console programs - so you should be able to compile it if you wish (and make changes if you dare).

I added a 'sad.ini' file too, which allows you to have bins,listings,directives etc in separate directories.

I will build and post executable versions very soon....
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by motorhead1991 » Mon Jan 29, 2018 10:20 pm

tvrfan wrote:
Mon Jan 29, 2018 6:23 pm
I have posted the latest source code to github under project 'EEC-IV-disassembler'.

It may well have bugs.....

Enjoy !!

(tip to motorhead1991 who suggested it.....)
I'd be more than happy to fork that into the OpenEEC-Project and add you to the org. I'd even be happy to help you with git 😁
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

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

Re: Why auto disassembly is tough

Post by tvrfan » Tue Jan 30, 2018 3:55 am

Probably finger trouble on my part, but it kept saying "OpenEEC-Project not found" ..... so I created a new one.

Happy to link together or whatever works....

I must also state that the code is development and so has bits of code commented out and such... and I didn't tidy it up as I would normally.
This means the _msgs file is much larger, as it prints a lot of stuff.... but did it so that if someone wants to use it to improve things...go for it.

I will be trying a different approach after this - a crossover of emulate and static branch I think....unless I get a Eureka moment....

I see Codelite has a github plugin (extension) for direct checkins etc - will check this out as well.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by motorhead1991 » Tue Jan 30, 2018 11:00 am

tvrfan wrote:
Tue Jan 30, 2018 3:55 am
Probably finger trouble on my part, but it kept saying "OpenEEC-Project not found" ..... so I created a new one.

Happy to link together or whatever works....

I must also state that the code is development and so has bits of code commented out and such... and I didn't tidy it up as I would normally.
This means the _msgs file is much larger, as it prints a lot of stuff.... but did it so that if someone wants to use it to improve things...go for it.

I will be trying a different approach after this - a crossover of emulate and static branch I think....unless I get a Eureka moment....

I see Codelite has a github plugin (extension) for direct checkins etc - will check this out as well.
You should get an email. I'm half tempted to use my README merged with yours (or on a separate branch), but didn't want to go further without talking to you first.
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

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

Re: Why auto disassembly is tough

Post by tvrfan » Tue Jan 30, 2018 1:54 pm

No Worries - to be honest, I saw your PM and thought "Yes, I should do that and allow everyone to see where I'm at".
I need to add documentation, and probably split up the tree into something like 'source', 'built' (executable) and 'doc'
I'll be looking at doing this next, now I've jumped off the cliff and given the code away.

If it helps more tuners understand, then that's a good thing.

Happy if you want to add stuff to readme....

I will also add some code examples for multibanks in this blog. They don't use POP, but use indexed stack instructions so they can get the calling bank out. (caller has to do a pushp to make this work). Here's an example....Yes, SAD does handle this one.

Code: Select all

882fd: a3,20,02,3e        ldw   R3e,[R20+2]      R3e = [STACK+2];                   # get PSW 
88301: a3,20,04,26        ldw   R26,[R20+4]      R26 = [STACK+4];                   # get return addr 
88305: f2                 pushp                  push(PSW);                         # push current state
88306: fa                 di                     disable ints;
88307: 18,02,3f           shrb  R3f,2            R3f /= 4;                          # get caller's bank
8830a: c4,11,3f           stb   R3f,R11          BANK_SEL = R3f;                    # set caller's bank
8830d: b2,27,2a           ldb   R2a,[R26++]      R2a = [R26++];
88310: b2,27,2b           ldb   R2b,[R26++]      R2b = [R26++];                     # get caller's arguments
88313: b1,11,11           ldb   R11,11           BANK_SEL = 11;                     # restore bank 
88316: f3                 popp                   PSW = pop();                            # restore state
88317: c3,20,04,26        stw   R26,[R20+4]      [STACK+4] = R26;                   # write return address  (+ 2) 
8831b: f0                 ret                    return;
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by motorhead1991 » Tue Jan 30, 2018 3:56 pm

tvrfan wrote:
Tue Jan 30, 2018 1:54 pm
No Worries - to be honest, I saw your PM and thought "Yes, I should do that and allow everyone to see where I'm at".
I need to add documentation, and probably split up the tree into something like 'source', 'built' (executable) and 'doc'
I'll be looking at doing this next, now I've jumped off the cliff and given the code away.

If it helps more tuners understand, then that's a good thing.

Happy if you want to add stuff to readme....

I will also add some code examples for multibanks in this blog. They don't use POP, but use indexed stack instructions so they can get the calling bank out. (caller has to do a pushp to make this work). Here's an example....Yes, SAD does handle this one.

Code: Select all

882fd: a3,20,02,3e        ldw   R3e,[R20+2]      R3e = [STACK+2];                   # get PSW 
88301: a3,20,04,26        ldw   R26,[R20+4]      R26 = [STACK+4];                   # get return addr 
88305: f2                 pushp                  push(PSW);                         # push current state
88306: fa                 di                     disable ints;
88307: 18,02,3f           shrb  R3f,2            R3f /= 4;                          # get caller's bank
8830a: c4,11,3f           stb   R3f,R11          BANK_SEL = R3f;                    # set caller's bank
8830d: b2,27,2a           ldb   R2a,[R26++]      R2a = [R26++];
88310: b2,27,2b           ldb   R2b,[R26++]      R2b = [R26++];                     # get caller's arguments
88313: b1,11,11           ldb   R11,11           BANK_SEL = 11;                     # restore bank 
88316: f3                 popp                   PSW = pop();                            # restore state
88317: c3,20,04,26        stw   R26,[R20+4]      [STACK+4] = R26;                   # write return address  (+ 2) 
8831b: f0                 ret                    return;
Done and done. I believe this will benefit everyone in the end, those of us that are new to disassembly, and those who've been doing it forever 😁.

Git can get kinda quirky in a hurry, so if you're playing with some new code use an experimental branch (or don't push it upstream). It gets frustrating having to change code that's been pushed already.
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

ender11
Gear Head
Posts: 58
Joined: Fri Jan 06, 2012 10:14 am
Location: Krasnoyarsk, Russia

Re: Why auto disassembly is tough

Post by ender11 » Wed Jan 31, 2018 8:45 pm

Nice!
observation:
"struct 225e 2281 :Y :W N" worked on SAD 0.2
"struct 225e 2281 :Y W N" working on SAD 1.0
"struct 225e 2281 Y W N" crashing SAD 1.0
"sym 0083 "Pip_irq" T 0" without semicolon crashing SAD 1.0
well, looks like "struct" directive changed it's syntax.

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

Re: Why auto disassembly is tough

Post by tvrfan » Wed Jan 31, 2018 11:12 pm

ender11 wrote:
Wed Jan 31, 2018 8:45 pm
Nice!
observation:
"struct 225e 2281 :Y :W N" worked on SAD 0.2
"struct 225e 2281 :Y W N" working on SAD 1.0
"struct 225e 2281 Y W N" crashing SAD 1.0
"sym 0083 "Pip_irq" T 0" without semicolon crashing SAD 1.0
well, looks like "struct" directive changed it's syntax.
No, syntax hasn't changed, but I made the mistake of 'tidying up' the code, and it's a bug wot I caused.....
CHECK - Having 'struct' (and others too, eg tab) option letters without a colon in front will crash it....

I'll fix and update Core.cpp ASAP....

< a little time later>

Oh damn, I see that the levels (split by colon) don't always work right either ... and all because I simplified it with the infamous sscanf.....
Last edited by tvrfan on Thu Feb 01, 2018 12:00 am, edited 1 time in total.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

ender11
Gear Head
Posts: 58
Joined: Fri Jan 06, 2012 10:14 am
Location: Krasnoyarsk, Russia

Re: Why auto disassembly is tough

Post by ender11 » Wed Jan 31, 2018 11:59 pm

confirmed, deleted spaces between : and W and everything worked.
two other things: 'C' style listing looks weird for me:

Code: Select all

 ##PIP Low handler

2990: 34,50,0c            jnb   B4,R50,299f      if (First_PIP = 1)  {              SVA 3[First_PIP 4 4]1, 2[14 50]1, 1[91 8299f]2,
2993: 08,02,58            shrw  R58,2            R58 /= 4;                          SVA 2[0 58]2, 1[4 2]2,
2996: 88,58,54            cmpw  R54,R58                                             SVA 2[0 54]2, 1[0 58]2,
2999: db,04               jc    299f             if (R54 > R58)  {                  SVA 1[91 8299f]2,
299b: 91,01,8e            orb   R8e,1            Last_HSI |= 1;                     SVA 2[Last_HSI 0 8e]1, 1[1 1]1,
299e: f0                  ret                    return; } }
SVA 1? is it for testing purposes?
and another issue - 1 vector table is not recognized (calling routine is), so some chunks are not disassembled. In 0GGA binary at 0x6DA6.

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

Re: Why auto disassembly is tough

Post by tvrfan » Thu Feb 01, 2018 12:45 am

Oh Damn, I forgot those too. They were for my internal code debug and are "Symbol, Value, Address" for each operand, with an extra op [0] for indexed and indirect opcodes (it's an easy trick to assemble indirect addresses etc in there, and keep originals ..)

OK, I've fixed the colon problem, and will go back and drop that extra SVA comment right now.....
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by motorhead1991 » Thu Feb 01, 2018 12:51 am

tvrfan wrote:
Thu Feb 01, 2018 12:45 am
Oh Damn, I forgot those too. They were for my internal code debug and are "Symbol, Value, Address" for each operand, with an extra op [0] for indexed and indirect opcodes (it's an easy trick to assemble indirect addresses etc in there, and keep originals ..)

OK, I've fixed the colon problem, and will go back and drop that extra SVA comment right now.....
Need some help with git there, tvrfan? If you have a chat client set up, chances are I'm on it and can show you some tricks

Or TeamVIewer, which also works :D

If nothing else, we can use the OpenEEC copy as the master. I don't mind copying the necessary stuff in, or showing you how to do it.
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

ender11
Gear Head
Posts: 58
Joined: Fri Jan 06, 2012 10:14 am
Location: Krasnoyarsk, Russia

Re: Why auto disassembly is tough

Post by ender11 » Thu Feb 01, 2018 1:32 am

here is what I see in _msg.txt:

Code: Select all


-----------Signatures---------[28]--(unprocessed)
 ofst   end  k p    name  pars
22000 22003  2 0    INIT      0,22169,    0,    1,    0,    0,    0,    0,    0,    0,    0,    0,    0,    0,    0,    0,
824e2 824e8  0 0   vect3      0,    0,   90,    0,    e,    0,    0,    4,824e9,    0,    0,    0,    0,    0,    0,    0,
827f7 827f7  0 0  IGNINT      0,    0,    0,    0,    0,    0,    0,    0,    0,    0,    0,    0,    0,    0,    0,    0,
834a1 834a5  0 0    sbp1      0,    0,    0,   a1,    0,    0,834ac,    0,    0,    0,    0,    0,    0,   20,    0,    0,
83517 8351b  0 0    sbp1      0,    0,    0,   a1,    0,    0,83522,    0,    0,    0,    0,    0,    0,   20,    0,    0,
8351c 83521  0 0    sbp1      0,    0,    0,   a1,    0,    0,    0,    0,    0,    0,    0,    0,    0,   20,   10,    0,
8351f 83521  0 0    sbp1      0,    0,    0,   a1,    0,    0,    0,    0,    0,    0,    0,    0,    0,   10,    0,    0,
835f2 835f4  0 0    sbp1      0,    0,    0,   27,    0,    0,    0,    0,    0,    0,    0,    0,    0,   40,    0,    0,
86bbe 86bc2  0 0   vect3      0,    0,   3a,    0,86db8,    0,    0,    4,8b83b,    0,    0,    0,    0,    0,    0,    0,
86bcb 86bcf  0 0   vect3      0,    0,   3a,    0,86da6,    0,    0,    4,8a63b,    0,    0,    0,    0,    0,    0,    0,
872b7 872c8  0 0   VParM      0,    1,    1,    1,    1,   3a,    0,    0,   3b,   16,    0,    0,    0,   3a,   42,   3c,
87461 87477  0 0   FPar2      0,    1,    0,    4,   1a,   1b,   1c,   1d,    0,    0,    0,    0,    0,    0,    0,   18,
874a6 874bf  0 0   1ENC3      0,    0,    0,   70,   3a,   f0,    0,    0,   42,   3e,    0,    0,    0,    0,    0,    0,
87ec8 87ed2  0 0   vect3      0,    0,    0,    0, 1ff2,    0,    0,    4,87ecf,    0,    0,    0,    0,    0,    0,    1,


it looks to me, that vector table is detected, but somehow skipped(?)
something in my _dir file blocking processing, guess what...
guessed: I used
sub 6b14 "Do_SelfTest"
directive, and it prevented disassembler from processing signature.

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

Re: Why auto disassembly is tough

Post by tvrfan » Fri Feb 02, 2018 2:20 pm

What's your binary ?

SAD is still development code, so it's probably a bug....or possibly something I commented out to fix up later and forgot...

I was trying to get it to 'release' stage, but it's been way to long already since the last release, so took the 'screw it' approach, as this is just
as good for finding bugs !
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by jsa » Fri Feb 02, 2018 9:33 pm

tvrfan wrote:
Mon Jan 29, 2018 8:04 pm
so you should be able to compile it if you wish (and make changes if you dare).

I will build and post executable versions very soon....
Ok got it to compile with code::blocks. No I don't dare......yet.....

The older SAD's you compiled had a version number in the exe file properties, the one I just compiled with the revised V1 source does not.
So, with multiple people compiling it, from various source code, how is versioning metadata set to show in the compiled exe?
Cheers

John

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

ender11
Gear Head
Posts: 58
Joined: Fri Jan 06, 2012 10:14 am
Location: Krasnoyarsk, Russia

Re: Why auto disassembly is tough

Post by ender11 » Sun Feb 04, 2018 7:41 am

my binary is 0GGA SD202.
well, this behavior is normal - giving sub definition without args drops "special sub" attribute from this sub. how to give names to special subs then?
another question - have you considered to give a small write-up on the internal working of your disassembler? once I wanted to change listing output format a little, but completely lost in code :shock:

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

Re: Why auto disassembly is tough

Post by tvrfan » Sun Feb 04, 2018 1:58 pm

I did post a complete PDF with last release - I need to put some changes in before repost.

As to 'SUB' command, it should stop any renaming if declared in a directive file, but still allow params etc. so that's a bug.
I did have to mark commands so that a user can override the code when it goes wrong.
In the meantime, do a SYM <address> < name> command with the sub name and start of subr.
- that will work (internally that's what a 'SUB' does anyway).

Documentation is another job to do .... an old one posted here (it's the same except for some detail stuff, have kept same interface)
SAD8065_4.pdf
(96.65 KiB) Downloaded 183 times
jsa - version number -> "last one + 0.1 !!" As this is dev code, I never did have a proper version - I would probably call this version 3,
so 3.01 ??
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by jsa » Mon Feb 05, 2018 1:51 am

tvrfan wrote:
Sun Feb 04, 2018 1:58 pm

Documentation is another job to do .... an old one posted here (it's the same except for some detail stuff, have kept same interface)

SAD8065_4.pdf

jsa - version number -> "last one + 0.1 !!" As this is dev code, I never did have a proper version - I would probably call this version 3,
so 3.01 ??
I have attached a copy of the help with some notes about filename length and command "name" lengths.

I have also struck through the r on subr, where they occur in the file.

3.01, no worries. How to get it to show that in the executable's properties and in the header content of the output files?

As dev code, it appears to be a signification step forward from previous, thank you for the hard work involved.
Attachments
SAD8065_4a.pdf
Annotated
(104.73 KiB) Downloaded 116 times
Cheers

John

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

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

Re: Why auto disassembly is tough

Post by tvrfan » Mon Feb 05, 2018 8:32 pm

I have attempted to tidy up the Disassembler project in Github, and have renamed the branch to dev_3.01_src, and taken source files out of 'master' (=top level). Have added documentation pdf and tidied up the readme file. My project is linked to the main OpenEEC github project, which now has a couple of binaries and listings in it (and I'll add some more soon).

Next job is to build binaries and upload them to Github.

jsa - [windows properties header] In Borland IDE, this was a build option, I can't see it in Codelite, there's vague references to a 'resources' file, but that's normally for GUI stuff.... I guess it *should* be in the project build options somewhere, but.....no i haven't found it either....Yet.

https://github.com/tvrfan/EEC-IV-disassembler for mine,
https://github.com/OpenEEC-Project for motorhead's 'master' with bins etc.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by jsa » Mon Feb 05, 2018 9:17 pm

I have found autoversioning in Code::Blocks
Defined version.h in Main.cpp.
Found where I might add some text for output files in core.cpp, but know insufficient about c++ to have the version variable actually output.
Attachments
version.h
Pretty much the default autoversion file from code blocks
(841 Bytes) Downloaded 91 times
Cheers

John

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

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

Re: Why auto disassembly is tough

Post by motorhead1991 » Mon Feb 05, 2018 9:29 pm

jsa wrote:
Mon Feb 05, 2018 9:17 pm
I have found autoversioning in Code::Blocks
Defined version.h in Main.cpp.
Found where I might add some text for output files in core.cpp, but know insufficient about c++ to have the version variable actually output.
We should be able to hard code it via our own header, I think. I haven't looked at the code that closely yet.

Hell, we can really get trick with an MD5sum script that auto updates the header on command.

EDIT:
OpenEEC is all caught up. I'll have to show you a more elegant way to do a mass exodus of code :biggrin:
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

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

Re: Why auto disassembly is tough

Post by tvrfan » Tue Feb 06, 2018 12:13 am

was doing an A9L printout to post, and discovered bugs in the structure printout. Will issue a 3.02 shortly.....
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by motorhead1991 » Tue Feb 06, 2018 12:50 am

Simplifying UNIX c++ building with a makefile. Give it a try ;)
sad_compile.png
sad_compile.png (192.28 KiB) Viewed 12607 times
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

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

Re: Why auto disassembly is tough

Post by jsa » Tue Feb 06, 2018 1:24 am

motorhead1991 wrote:
Mon Feb 05, 2018 9:29 pm

Hell, we can really get trick with an MD5sum script that auto updates the header on command.
Ok lead the way.
Cheers

John

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

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

Re: Why auto disassembly is tough

Post by motorhead1991 » Tue Feb 06, 2018 1:37 am

So, MD5 doesn't change between compiles, but a code revision should alter that. When tvr is ready, I'll try it.
md5.png
md5.png (119.12 KiB) Viewed 12601 times
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

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

Re: Why auto disassembly is tough

Post by motorhead1991 » Wed Feb 07, 2018 2:11 am

Hey tvrfan, you can save yourself some trouble by letting the commit messages do the talking. Also, chek my latest commits on OpenEEC, and see what you can do with them if you get bored.
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

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests