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

Post Reply
mpaton
BIN Hacker
Posts: 376
Joined: Mon Jun 23, 2008 1:39 pm

Re: Why auto disassembly is tough

Post by mpaton » Tue Sep 25, 2018 10:38 pm

So that means you're not going to support any more than 4 banks? :wink:

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

Re: SAD 3.08 released

Post by jsa » Wed Sep 26, 2018 12:33 am

tvrfan wrote:
Mon Sep 24, 2018 6:52 pm
Just released 3.08.
......
I have a couple of bins which seem to have two code banks (not allowed!!) but from names, may be a dump of original followed by modded version, so I have changed SAD to print first code bank found.
Thank you for the new version release.

Any of those oddball two code bank bins have something other than 8 and 1 for calibration pointers and _maybe_ number of tunes or something?

Code: Select all

2020: 08                  byte    8
2021: 01                  byte    1
Cheers

John

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

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

Re: Why auto disassembly is tough

Post by sailorbob » Wed Sep 26, 2018 1:44 am

I believe the 4TAB ecu has an 88k rom so I suspect both of the bin files you have are not correct.

ranga83
Gear Head
Posts: 53
Joined: Thu Jan 03, 2013 8:33 am

Re: Why auto disassembly is tough

Post by ranga83 » Wed Sep 26, 2018 7:38 am

the 4tab_el_spark is a modified 4tab with the el falcon spark tables. and yes, it has bank 8 loaded into it twice, not sure why they did that but obviously wasn't ford that did it. my copy also has junk in the filler instead of "ff"

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

Re: Why auto disassembly is tough

Post by tvrfan » Wed Sep 26, 2018 2:20 pm

mpaton wrote:
Tue Sep 25, 2018 10:38 pm
So that means you're not going to support any more than 4 banks? :wink:
Actually, I've written the code so that it should handle ALL 16 banks, so there !!
Well, yeah, OK, code does check for 0,1,8,9 in a few places, but for all addressing, it's full 20 bits, 16 banks capable.
Anyone got a (8065) bin with >4 banks ??

Frankly, it would be SO much nicer if EVERYONE STUCK TO A STANDARD FILE FORMAT and HAD THE BANKS IN THE SAME ORDER.
But like many things in life ....it's obviously too much to ask for.

[Hmmm.. irrelevant, but I can't seem to get smilies to work correctly ...Yes, side panel says they are on, but won't work]
Last edited by tvrfan on Wed Sep 26, 2018 3:09 pm, edited 1 time in total.
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

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

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

Re: Why auto disassembly is tough

Post by tvrfan » Wed Sep 26, 2018 2:28 pm

Seriously but -

I've collected quite a few bins for my test set, I've got over 100 now. About time I did that really, as I'm still discovering new code tricks in them.

There are a couple where whoever did the dump had faulty hardware/connection, as it always has one of the bits set (so not useable),
A few where the filler has a value other than 0xff, or has a recurring pattern, but the real code and data are OK.
At least one where both the front 0x2000 and end filler area has a recurring pattern of values but again the main block is fine....
A couple with missing or extra bytes at the front....

and I've tried to cater for all of these ...
Last edited by tvrfan on Wed Sep 26, 2018 3:08 pm, edited 1 time in total.
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

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

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

Re: SAD 3.08 released

Post by tvrfan » Wed Sep 26, 2018 2:35 pm

jsa wrote:
Wed Sep 26, 2018 12:33 am

Thank you for the new version release.

Any of those oddball two code bank bins have something other than 8 and 1 for calibration pointers and _maybe_ number of tunes or something?

Code: Select all

2020: 08                  byte    8
2021: 01                  byte    1
I've not seen anything other than the 8 (regs) and 1 (set) yet. Earlier bins have no formal structure at all, and this setup at either 2020 or 2060 seems to be a de facto Ford standard. It's even in the handbook in the memory map.

Anyone got anything different ?
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

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

mpaton
BIN Hacker
Posts: 376
Joined: Mon Jun 23, 2008 1:39 pm

Re: Why auto disassembly is tough

Post by mpaton » Wed Sep 26, 2018 10:17 pm

tvrfan wrote:
Wed Sep 26, 2018 2:20 pm

Actually, I've written the code so that it should handle ALL 16 banks, so there !!
Well, yeah, OK, code does check for 0,1,8,9 in a few places, but for all addressing, it's full 20 bits, 16 banks capable.
Anyone got a (8065) bin with >4 banks ??
I'm sure many people do, possibly even yourself if you have an ECU with flash ROM in it.
Try enabling the flashing pin................

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

Re: Why auto disassembly is tough

Post by tvrfan » Thu Sep 27, 2018 2:35 pm

mpaton wrote:
Wed Sep 26, 2018 10:17 pm
I'm sure many people do, possibly even yourself if you have an ECU with flash ROM in it.
Try enabling the flashing pin................
I only ever had a couple of older actual EEC-IV boxes as part of classic car and engine swaps/kits from several years ago.
Boxes were all UK/European ones, from before I moved to New Zealand.
Other than that, I've only ever had file images, and the [auto] disassembler idea became more of a 'brain challenge' thing (and still is).

If someone wants to send me a file image with Flash, I'll always be interested.....
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

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

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

Re: Why auto disassembly is tough

Post by motorhead1991 » Sat Oct 06, 2018 5:58 pm

tvrfan wrote:
Wed Sep 26, 2018 2:28 pm
Seriously but -

I've collected quite a few bins for my test set, I've got over 100 now. About time I did that really, as I'm still discovering new code tricks in them.

There are a couple where whoever did the dump had faulty hardware/connection, as it always has one of the bits set (so not useable),
A few where the filler has a value other than 0xff, or has a recurring pattern, but the real code and data are OK.
At least one where both the front 0x2000 and end filler area has a recurring pattern of values but again the main block is fine....
A couple with missing or extra bytes at the front....

and I've tried to cater for all of these ...
I can send you the 3 that I have if you like - EFI-MA35 and EFI-SD20a (2 out of the 3 of those are on Github)
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: 523
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: Why auto disassembly is tough

Post by jsa » Fri Oct 19, 2018 2:13 am

A piece of CARD.

Code: Select all

6cbd: c3,6e,96,3e         stw   R3e,[R6e+96]     LWord = R3e;
6cc1: a3,6e,96,38         ldw   R38,[R6e+96]     R38 = LWord;
6cc5: a0,a2,3a            ldw   R3a,Ra2          R3a = HWord;                     # Ra2*65536
6cc8: 0c,01,38            shrdw R38,1            LR38 >>= 1;       ## R38 /= 2    # (LWord+(HWord*65536))/2
                                                                                  # LWord/2 + HWord*32768
6ccb: 68,38,3a            sb2w  R3a,R38          R3a -= R38;                      # HWord*32768/65536 - LWord/2
                                                                                  # HWord/2 - LWord/2
6cce: c3,6e,74,3a         stw   R3a,[R6e+74]     Result = R3a;
Cheers

John

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

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

Re: Why auto disassembly is tough

Post by sailorbob » Fri Oct 19, 2018 6:12 am

This is just a bit of cute coding by Ford, in this particular instance using SHRDW has saved using SHRW twice (i.e. separately on 0x38 and 0x3A) as the value is 0x38 is not double word sized and the lowermost bits of 0x3A are zero.

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

Re: Why auto disassembly is tough

Post by jsa » Fri Oct 19, 2018 2:17 pm

Indeed, bit0 of R3A would have to be clear for the math to work like that.

Seems an obfuscated way to find the difference between 2 unsigned words and giving the result as a signed word. Hints at SHRW not working on a signed value if the order was subtraction then shift.

Presents a fair challenge for tvrfan to have SAD automaticly resolve.
Last edited by jsa on Fri Oct 19, 2018 3:51 pm, edited 1 time in total.
Cheers

John

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

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

Re: Why auto disassembly is tough

Post by sailorbob » Fri Oct 19, 2018 2:53 pm

It's not obfuscation, just a neat way of saving 8 state times. I doubt you could automate commenting this out in the disassembly due to its subtlety.

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

Re: Why auto disassembly is tough

Post by jsa » Fri Oct 19, 2018 3:47 pm

Hmmm subtlety. Hidden in plain sight. Obfuscation. All tarred with the same brush to some degree, I say :biggrin: .

Yes those wait states. Hats off to whoever developed that approach. How many other reasons are there to ensure 10 bit values are at the top of the word?
Cheers

John

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

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

Re: Why auto disassembly is tough

Post by tvrfan » Fri Oct 19, 2018 6:23 pm

Actually, there's quite a lot of wait loops in low level coding, everywhere.

Trouble is the CPU is often faster than the hardware it's driving. On the slightly bigger machines I worked on, many of the peripherals used interrupts to communicate, but even then there often had to be a wait between reading/writing commands or data (etc.) Often (IMHO) it's actually to do with the memory sharing/scheduling between CPU and a device.

True Story -

I can remember a project with a high speed comms link (for its day) between dual computer suites.
When we had a project which used the same link between 3 systems, we got the same drivers, and I saw that the previous author of the driver had this weird 'reject next message' flag embedded in the code. Huh ?? After a bit of playing around I and a colleague discovered the hardware needed an extra delay because it wrote to memory data AFTER it generated an interrupt, resulting in it screwing up its CRC check if you read it too quickly (it was actually a HW design error). You could get around it by simply adding in three SHW 16 instructions in the right place in interrupt handler code. We could then show the throughput actually doubled (well 1.9), so that 'reject flag' code was being hit almost every single time to fix the CRC error, and it was only spotted because we were curious about the code. Bugger of it was I had to push hard because the so-called "op system experts" were an arrogant bunch and simply didn't believe me. And that was with a proper operating system too.
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

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

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

Re: Why auto disassembly is tough

Post by tvrfan » Mon Oct 22, 2018 11:19 pm

here's a great one to "do yer 'ead in" as they would say in dear old Blighty (UK slang)

I found this in 22CA whilst trying to get variable arguments to work, and spent AGES looking at it for why SAD wouldn't
pass on the function lookup attributes..... and then the light dawned......

Code: Select all

  
     SUBFunLU1:
86dbc: f2                 pushp                  push(PSW);
86dbd: 91,20,e0           orb   Re0,20           Re0 |= 20;
86dc0: 20,25              sjmp  86de7            goto 86de7;

   SSBFunLU1:
86dc2: f2                 pushp                  push(PSW);
86dc3: 91,20,e0           orb   Re0,20           Re0 |= 20;
86dc6: 00                 skip                   goto 86dc8;

   USBFunLU1:
86dc7: f2                 pushp                  push(PSW);
86dc8: 91,10,e0           orb   Re0,10           Re0 |= 10;
86dcb: 20,1a              sjmp  86de7            goto 86de7;

   SUBFunLU2:
86dcd: f2                 pushp                  push(PSW);
86dce: 91,20,e0           orb   Re0,20           Re0 |= 20;
86dd1: 20,0d              sjmp  86de0            goto 86de0;

   Sub263:
86dd3: f2                 pushp                  push(PSW);
86dd4: 91,20,e0           orb   Re0,20           Re0 |= 20;
86dd7: 00                 skip                   goto 86dd9;

86dd8: f2                 ???   

86dd9: 91,10,e0           orb   Re0,10           Re0 |= 10;
86ddc: 00                 skip                   goto 86dde;

   Sub264:
86ddd: f2                 pushp                  push(PSW);
86dde: 20,00              sjmp  86de0            goto 86de0;

86de0: 28,4e              scall 86e30            Sub265();
86de2: b2,3c,3c           ldb   R3c,[R3c]        R3c = [R3c];
86de5: 00                 skip                   goto 86de7;

   UUBFunLU1:                                                 ## this is the real func lookup subr 
86de6: f2                 pushp                  push(PSW);
86de7: 9b,3a,02,3c        cmpb  R3c,[R3a+2]      
86deb: 3d,e0,04           jb    B5,Re0,86df2     if (B5_Re0 = 1) goto 86df2;
86dee: db,0a              jc    86dfa            if (R3c < [R3a+2])  {
86df0: 20,02              sjmp  86df4            goto 86df4;             ## snipped here
why does SAD find the earlier ones correctly, and not the later ones ?
is it the embedded subr call ? (which is a get parameters, so this has signed/unsigned options for both embedded arguments and via old style registers)
I spent ages fiddling with the code and debug prints to find out why, no joy.......

AND THEN - 86dde - IT JUMPS BY ZERO! - A DUMMY JUMP !!! WTF ?? !!!

I can only guess that the above is probably a 'switch/case' like construct in the (true) source code, and so the compiler sets up a jump table for it, and 86dde is a 'fall through' or something like that, and it didn't get removed by the 'redundant code check' which most compilers have. It doesn't seem like an afterthought patch, but I guess it could be. So need an extra check for this....

I know there was a debate in 'C' coding as to whether 'switch+case' was faster or slower than a list of 'if-then', and that compilers often set up a 'jump table' (just like a pointer list in EEC-IV) for it, so I wonder....

Oh, and it does exactly the same for the Word and Byte lookups .....

So posted this as it's possibly even weirder than the redundant timing/delay opcodes....

So I've got A9L to work as a static analysis (as before) but with controlled emulation passes in subroutines for the embedded arguments, at the moment just gets bare bytes, but it gets the right number ! 22CA was the next candidate as it uses the [STACK+x] method to get arguments, with PSW pushes in there to get the correct bank(s), which is what I'm doing now....

So making some progress -

JSA - I'll possibly use CARD next, as I know it has 'if () then get 4 or 6 args' type code. That's probably the next challenge to sort out.

[edited for typos and made description better]
Last edited by tvrfan on Tue Oct 23, 2018 4:49 pm, edited 1 time in total.
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

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

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

Re: Why auto disassembly is tough

Post by jsa » Tue Oct 23, 2018 1:51 am

:crazy:
Cheers

John

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

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

Re: Why auto disassembly is tough

Post by motorhead1991 » Wed Oct 24, 2018 2:06 am

I think I've seen this in m0m2 actually... Didn't think much of it, since that one is so underdeveloped.
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

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

Re: Why auto disassembly is tough

Post by tvrfan » Thu Oct 25, 2018 2:18 pm

Wouldn't be surprised if it's in a lot of binaries - if it's a compiler thing (which it could well be) then probably a whole family have it.

Sort of interesting on a different level - A9L does appear to have been 'hacked' afterwards (IMHO), with jumps inserted and odd bits which are never called, and ops like R0=popw which shortcuts the ret instruction.

That 22CA though looks quite neat (so far) otherwise.

automatic variable arguments - Did I say I'd got A9L working ? discovered that dreaded bit of code around 728x doesn't work right (It's got jumps to subr and shortcut return tricks) along with 22CA changes... DAMN.... I already had to come up with a trick to detect the pushflags....Oh well, more thinking required....
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

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

User avatar
cgrey8
Administrator
Posts: 10569
Joined: Fri Jun 24, 2005 5:54 am
Location: Acworth, Ga (Metro Atlanta)
Contact:

Re: Why auto disassembly is tough

Post by cgrey8 » Thu Oct 25, 2018 3:18 pm

Just out of curiosity, does disassembling this stuff get easier as the processors get newer?

Expand the thought beyond EEC-V into modern processors. Does Ford still hand-author assembly in these things or have they embraced C/C++ which would make disassembling them, presumably, easier and more predictable since C/C++ has standard calling conventions and optimization techniques are fairly well known for each instruction set.

Or am I just dreaming?
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

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

Re: Why auto disassembly is tough

Post by tvrfan » Thu Oct 25, 2018 7:49 pm

Good question, I'm honestly not sure..

As far as I know.....

Higher level languages ('C' and upwards to things like Java) have some pretty good compilers, and they tend to have optimisation options for each main processor family. They already have a lot of 'code shortcut' optimisation tricks built in first (platform independent, based on logic of the code itself), and then a further pass/set for the actual target hardware (aka linker phase). Many 'base' libraries also have different versions for different CPUs too.

So I'm NOT convinced it's any easier, but yes, a commonly used family will have known optimizations, which might help somewhat.

Apparently, from what I have read, compilers for CPUs like multicore x86 architecture produce actual code in ways that help the CPU itself do its 'predictive branching' tricks to speed things up even further. I understand this is from the way jumps are interleaved/laid out in the final code.

From what I see of EEC-IV and V (and this is just my opinion) the earlier ones look more hand built, and the later ones look more regular, like a compiler output. But even then, where you get time delays/hardware interfaces, the compiler won't know, so probably little bits of hand coded stuff in these too.

From career knowledge of small to mid-sized process control stuff - they are mostly high level code, but often with hand built (as low level code/assembler) interrupt handlers and final stage of drivers for memory mapped devices, timing, and so on. Some were done even on top of a real time OS, in the same way. EEC-IV and V are very much like this setup, with its 'peripherals' (= input/output, specialist chips, etc) having defined memory addresses and timing rules.

I certainly don't claim to be expert here, so that's my best answer.
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

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

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests