Defining vect doesn't disassemble the found subs

[DerbyWS]

I'm running through my collection of unique strategy files, and I noticed that the vect lists aren't always defined and some code gets missed because of it, so I've been working on matching up all of the vect lists in each file and adding them to a dir file per strategy and just realized that new code gets marked as a sub, but doesn't actually get disassembled. I assume this isn't the expected behavior?

SAD version: SAD Version 4.0.14.1 (27 Feb 2025)
Also validated the same issue exists in: SAD Version 4.0.13 (01 Feb 2025)
Strategy: ATAF2

DIR file:

vect 182b6 182DB : K 0
vect 182f0 18303 : K 9
vect 18422 184E9 : K 8

Example of a sub marked but not disassembled:

   Sub_0882c:
0882c: f2,b3,d8,26,46,71,7f,46,c7,d8,26,46,2a,3f,e2,09  ???  
0883c: ea,09,e0,06,a7,08,10,2a,2a,ca,09,e2,09,ac,0b,a7  ???  
0884c: 08,80,28,bd,ef,d3,04,f3,f0  ???  

Which is called this string of subs:
vect @ 184e2: -> Sub_87487 87489: -> Sub_874f2 87545: -> Sub_0882c

Second example in the same file:
vect @ 184e0: -> Sub_8f332 8f334: -> Sub_930a4 930d1: -> Sub_93373 93a72: -> Sub_93a76 93b6f: -> Sub_08c14

Both items above are in the msg file like any other sub, no warnings or errors that I see, so it seems like they should have processed. Also, I went back and found that even with no dir file it does the same thing.

sym 0882c  "Sub_0882c"
sym 08c14  "Sub_08c14"

Adding them to the dir file seems to not change anything when done like this:

sub 0882c
sub 08c14

Adding it as code seems to have forced it to display what it could work out. I guess it's flagging the code as invalid which is why it refused to disassemble the code by default.
dir file

code 0882c 08c9e
code 08c14 08c9d

   Sub_0882c:
0882c: f2                 pushp                  push(PSW);
0882d: b3,d8,26,46        ldb   R46,[Rd8+26]     R46 = [108a6];
08831: 71,7f,46           an2b  R46,7f           B7_R46 = 0;
08834: c7,d8,26,46        stb   R46,[Rd8+26]     [108a6] = R46;
08838: 2a,3f              scall 08a79            Sub_08a79 (
0883a: e2,09                    #arg 1              9e2,
0883c: ea,09                    #arg 2              9ea,
0883e: e0                       #arg 3              e0,
0883f: 06                       #arg 4              6,
08840: a7,08                    #arg 5              8a7,
08842: 10                       #arg 6              10 );
08843: 2a,2a              scall 08a6f            Sub_08a6f ();
08845: ca,09              push  [R8++]           push([INT_Mask++]);
08847: e2                 !INV! 
08849: ac,0b,a7           ldzbw Ra7,Rb           wRa7 = HSI_Sample;
0884c: 08,80,28           shrw  R28,R80          R28 = R28 >> R80;
0884f: bd,ef,d3           ldsbw Rd3,ef           swRd3 = ef;
08852: 04                 !INV! 
08854: f0                 ret                    return;

Side note, I used notepad++ and a regex to find these. Most files I've been working with have around 15 matches, this one had 25 so it stood out as different. With those two subs disassembled it would be 13 left which would be ball park like the other files.

^[0,8,9].*\?\?\?.*$

I know the work around is to define the sub, but for my usage I don't need to name it or anything, just need it disassembled for reference since it's a lot more work defining every sub manually this way, hoping that it's just a small bug to make my work a lot easier (got 470 files to do this for lol). Actually this reminds me, this would break my current script because it expects all marked subs to be disassembled, I better add a check for ??? lines.

SAD has come a long ways, it's been such a great tool to use while learning these computers (EEC-V era).

It seems like the latest version of SAD hits almost everything automatically now. I've found that it does miss the last line of some vect lists when it does find them, I suspect it doesn't check the code for the actual if statement difference for the length (aka if (R26 <= 24) vs if (Rcf < c8) from the same file). I can make a separate issue detailing that bug but for the most part it's a very minor issue, it just misses one vect item at the end sometimes.

The exact bin file is ATAF2A7 which can be downloaded directly from Ford. ATAF3 appears to have the exact same situation going on in it (probably the same code).

https://www.motorcraftservice.com/diagnostic/Support?channelId=50&categoryId=288

Choose USA for the country, click Calibration Files link, paste file name in the text box and download. If you get the asp file, retry till the page either says the file isn't found or you get a zip file.

[tvrfan]

Oops, sorry, missed this report entirely. I will study this and see what the bug is. Generally if you do a 'sub command' , SAD will scan from the address given, to try to disassemble the code. It's probably that SAD is finding an invalid opcode inside the sub, typically caused by embedded arguments (which frankly are a real PITA to sort out). I am trying to work through the bugs as reported, and yes SAD is still an ongoing project. New bins (as fed to SAD that is) also sometimes show new code 'tricks' which can mess things up. At the moment, changing internals so that each and every opcode and its operands are stored in a master 'database', to support better decoding of argument sizes,loops, if/then and possibly 'else' as well.

to experiment further, you could try CODE matched with the SUB and see what happens.....

[jsa2340]

DIR entries work around the ARG's issue

ARG 0883A  08842: UW N : UW N : O 2 UY : UW N : UY 
ARG 08844  0884E: UW N : UW N : O 2 UY : UW N : UY 

LST output for DIR with the the above entries.

   Sub_0882c:
0882c: f2                 pushp                  push(PSW);
0882d: b3,d8,26,46        ldb   R46,[Rd8+26]     R46 = [108a6];
08831: 71,7f,46           an2b  R46,7f           B7_R46 = 0;
08834: c7,d8,26,46        stb   R46,[Rd8+26]     [108a6] = R46;
08838: 2a,3f              scall 08a79            Sub_08a79 (
0883a: e2,09                    #arg 1              9e2,
0883c: ea,09                    #arg 2              9ea,
0883e: e0                       #arg 3              e0,
0883f: 06                       #arg 4              6,
08840: a7,08                    #arg 5              8a7,
08842: 10                       #arg 6              10 );
08843: 2a,2a              scall 08a6f            Sub_08a6f (
08845: ca,09                    #arg 1              9ca,
08847: e2,09                    #arg 2              9e2,
08849: ac                       #arg 3              ac,
0884a: 0b                       #arg 4              b,
0884b: a7,08                    #arg 5              8a7,
0884d: 80                       #arg 6              80 );
0884e: 28,bd              scall 0890d            Sub_0890d ();
08850: ef,d3,04           call  08d26            Sub_08d26 ();
08853: f3                 popp                   PSW = pop();
08854: f0                 ret                    return;

The skip might be the cause, skip's trip up lookups too.

   Sub_08a6f:                                                        # 2nd call
08a6f: f2                 pushp                  push(PSW);
08a70: c3,d8,f0,00        stw   R0,[Rd8+f0]      [10870] = 0;
08a74: c3,d8,ee,00        stw   R0,[Rd8+ee]      [1086e] = 0;
08a78: 00                 skip                   goto 08a7a;         # SKIP to args loader

   Sub_08a79:                                                        # 1st call
08a79: f2                 pushp                  push(PSW);
08a7a: 10,08              rombk 8
08a7c: ef,96,f5           call  88015            Sub_88015 (         # Variable count Args loader
08a7f: 09                       #arg 1              9 );             # 9 bytes for each

[tvrfan]

Picking out lists of things has been an ongoing problem (for all types, vects/subroutines, tables/functions, values) , because it's not always easy to work out where the start or end of a list is. This is because there are many ways to access a list of things in the code, some lists don't start at zero, and some even have a data element in a subroutine list (you can see several examples of these in A9L bin).
So it's an ongoing issue to try to fix.

[tvrfan]

Other issue - I have done a LOT of work on trying to sort out arguments (subroutine parameters) and hopefully some stuff should get fixed in next release. I ended up rewriting some of the internals to make it easier to scan up and down the opcodes, different (internal) data structures etc.

[DerbyWS]

Yea I totally get the args are a real pain to work out in these. At the time I was building a database of every EEC-V 4 bank computer's subs to cross reference and cross link the code patterns and such. I found some interesting things, but it doesn't seem to be the route to go. Of course SAD is at the center of doing the heavy lifting lol. If I dive down that project again I have some new idea's.

Either case SAD has always been a great tool for what I've been doing and once I get a core concept figured out, I can apply the logic across all bins directly in asm/hex using my own tools.

I'm not sure if SAD uses a different engine per EEC-V type, but maybe 4 bank vs 2 bank vs EEC-IV should be processed using slightly different engines? Not super sure since I've never coded a disassembler before.

[tvrfan]

Update - found problem with automatic detected vector lists in multibank bins where ALTSTACK (0x22) is used as pointer.

SAD uses same analysis technique for all bins, internally treats a single bank bin as a sole bank 8.
cpu type and and multibanks detected by looking at interrupt vectors (0x2010 onwards).

Sad does have the idea of 'signatures' which are code sections to do a particular job, which occur in almost all bins (e.g. function lookup, table lookup)