ADis disassembler

[matthey]

I don't have web space anymore and it would be good to have a thread for bug reports so I am posting my latest ADis enhancements here (full source included). I have fixed a few bugs recently. The most recent version is ADis 1.4beta34 which needs more testing.

[PeterK]

Thank you for your great job improving ADis again and again, Matthew !

I will update my current version soon and report any new problems here now. I really like the FD file support and the resolution of function and data tables in libraries that you introduced to ADis.

[matthey]

Thanks Peter for your kind words as well as your icon.library. You might know about these never ending adopt a projects. There are those of us left who feel obligated to fix bugs at least. Thanks to Thomas Klein for his bug report which helped me find the very old bug where RTR did not work on the 68000. I also added some support for code ending in TRAP so it would be good to test with executables containing TRAP and/or RTR (not common Amiga code).

[meynaf]

I made some quick test of ADis and a lot of code got output as DC directives.
Is there a way to manually force some area to be code or data ?

[matthey]

Originally Posted by meynaf

I made some quick test of ADis and a lot of code got output as DC directives.
Is there a way to manually force some area to be code or data ?

ADis by design, follows the path of the PC (enters branch taken path for branches also) from entry points (only the start of an executable by default). Libraries (including devices, resources and gadgets) need the -l command line to enter the library functions as code (it would be possible to auto detect libraries and automatically do this but at least one tester is against this). If the code has unusual entry points or dead code, then -dc <hex_offset> should make it disassemble as long as the end of code can be found like an RTS. Data can be specified with a -dd <hex_offset>. ADis ? will give a list of options which is more useful than the docs at this point. ADis is unusual compared to a normal top down disassembler but then it can often detect code, strings and data with better accuracy than most disassemblers. It is better for system friendly code than hardware banging code.

[kamelito]

@Meynaf

Sherlock can do this but I don't know if there's a version available somewhere.
Fabien Campagne, the author has submitted bugs to PhxAss, maybe "Phx" do have it's email.
http://obligement.free.fr/articles/sherlock.php

Update Sherlock might be in there



Kamelito

[phx]

Originally Posted by kamelito

Fabien Campagne, the author has submitted bugs to PhxAss, maybe "Phx" do have it's email.

Indeed, I remember the name. But the last contact might have been 15-20 years ago. I no longer have any mail or address from him.

[matthey]

ADis has flags for (b)yte, (w)ord, (l)ongword, (s)igned, (R)eloc, (S)tring, (T)able and (C)ode. Without a code flag you get data. ADis sets the appropriate flags which it knows but currently only has user settable flags for code and data. The flags can be added to each disassembled line with a -a8 command line switch. Internally, ADis is quite flexible and the source is in good shape. It just lacks the interface and a GUI to become a better Resource. I have thought about turning it into a disassembler/debugger with GUI but I'm not motivated with the current state of the Amiga. Only Amiga makes it impossible.

[meynaf]

Originally Posted by matthey

ADis by design, follows the path of the PC (enters branch taken path for branches also) from entry points (only the start of an executable by default).

This method can't work 100%. Differentiating code from data is sometimes hard enough even for a human.
When doing an ST-to-Amiga port, i use a script (running on my own disassembler) which tells who's who. Perhaps an option you can consider.

Originally Posted by matthey

If the code has unusual entry points or dead code, then -dc <hex_offset> should make it disassemble as long as the end of code can be found like an RTS.

In my case there would be hundreds of -dc on the command line.

Originally Posted by matthey

It is better for system friendly code than hardware banging code.

Apparently it doesn't like damned ixemul apps...

Originally Posted by matthey

Only Amiga makes it impossible.

I can just disagree here. At least you can resource a program that can be modified, reassembled and will work. Try that on x86 !

[matthey]

Originally Posted by meynaf

This method can't work 100%. Differentiating code from data is sometimes hard enough even for a human.
When doing an ST-to-Amiga port, i use a script (running on my own disassembler) which tells who's who. Perhaps an option you can consider.

Right. Small amounts of data can often be code or data and without more info, it is difficult to determine. I have done about everything I can for ADis to make a good guess in these cases.

Originally Posted by meynaf

In my case there would be hundreds of -dc on the command line.

It would probably be good to add an option to disassemble what is left after following the path of the PC from entry points. It is very good at identifying dead code right now though. No label at the top of data that ends in an RTS probably means the code is dead if all the entry points were given. It is amazing how much dead code is in C programs.

Originally Posted by meynaf

Apparently it doesn't like damned ixemul apps...

Nobody likes ixemul apps do they? Ixemul is one big hack. I hate to waste code and time for hacks but there is enough code out there that ADis could do a better job.

Originally Posted by meynaf

I can just disagree here. At least you can resource a program that can be modified, reassembled and will work. Try that on x86 !

ADis can disassemble over 50% of system friendly programs and reassemble the unmodified result with them working. It is just that ixemul programs are not system friendly.

[meynaf]

Originally Posted by matthey

Nobody likes ixemul apps do they? Ixemul is one big hack. I hate to waste code and time for hacks but there is enough code out there that ADis could do a better job.

ADis can disassemble over 50% of system friendly programs and reassemble the unmodified result with them working. It is just that ixemul programs are not system friendly.

Sure but what can i do about it when all i have is that ixemul program without full source ?
If i had a non-ixemul version of that thing or even full source that i can compile, i'd have used that. After all i just wanted to asm-optimize it, so i tried ADis but i saw that manual disassembly is still needed.

Anyway, in that example it stopped the disassembly after some indirect JSR calls. Perhaps not the right thing to do ?

[matthey]

Originally Posted by meynaf

Anyway, in that example it stopped the disassembly after some indirect JSR calls. Perhaps not the right thing to do ?

Probably not. Are the JSR call locations in another section or out of the program completely?

[matthey]

Originally Posted by meynaf

Anyway, in that example it stopped the disassembly after some indirect JSR calls. Perhaps not the right thing to do ?

Probably not. Are the JSR call target locations in another section or out of the program completely?

[meynaf]

Originally Posted by matthey

Probably not. Are the JSR call target locations in another section or out of the program completely?

They appear to be library calls, but with A0 instead of A6. The JSR goes to some stub, which does a JMP -$xx(A0).
You can just follow the link i gave in the previous post and see by yourself...

[matthey]

Originally Posted by meynaf

They appear to be library calls, but with A0 instead of A6. The JSR goes to some stub, which does a JMP -$xx(A0).
You can just follow the link i gave in the previous post and see by yourself...

I'll look into it. Disassembly should not stop at a JSR unless there is code that is not recognized below it. If it is 68020+ code, do you use -m2 for 68020, -m6 for 68060 (all 68k instructions) or -m to detect your Amiga CPU and disassemble for that target?

Have you tried asking Lorence Lombardo for the source or a libnix compile? He has done many Unix flavor ports but probably needs feedback to know which ones people like and should be worked on more.

Edit: The source is in the archive you linked and the original vorbis player. I just compiled using GCC with -noixemul.

[meynaf]

Originally Posted by matthey

I'll look into it. Disassembly should not stop at a JSR unless there is code that is not recognized below it. If it is 68020+ code, do you use -m2 for 68020, -m6 for 68060 (all 68k instructions) or -m to detect your Amiga CPU and disassemble for that target?

The only option i used was -o. Everything else was by default.

Originally Posted by matthey

Have you tried asking Lorence Lombardo for the source or a libnix compile? He has done many Unix flavor ports but probably needs feedback to know which ones people like and should be worked on more.

His mail address appears to be no longer valid.

Originally Posted by matthey

Edit: Some of the source code is in the archive you linked. It looks like the majority of it is missing and appears to be a mistake.

It uses the tremor library so perhaps it can compile with just that. However i'm not very good at making C to compile properly. Having a version that compiles and works under MaxonCPP would allow me to asm hand-optimize it part by part. Do you think someone would help if i just ask in a new thread ?

[matthey]

Originally Posted by meynaf

The only option i used was -o. Everything else was by default.

Ok, it looks like the code is compiled for 68020 and some versions need the FPU so you need to throw the appropriate -m switch.

Originally Posted by meynaf

It uses the tremor library so perhaps it can compile with just that. However i'm not very good at making C to compile properly. Having a version that compiles and works under MaxonCPP would allow me to asm hand-optimize it part by part. Do you think someone would help if i just ask in a new thread ?

I was able to compile it with -noixemul. I can help you. What options do you want?

68020 CPU I presume?
No FPU, 68881, 68040, 68060?
_MC68020_ASSEM_ ?
_LOW_ACCURACY_ ?

[meynaf]

Originally Posted by matthey

I was able to compile it with -noixemul. I can help you. What options do you want?

68020 CPU I presume?
No FPU, 68881, 68040, 68060?
_MC68020_ASSEM_ ?
_LOW_ACCURACY_ ?

I want to be able to mix that code with handwritten asm, i.e. regular hunk object format (= not GCC).

Whether it's compiled for 68000 or 68020+ does not matter much (but no FPU ; else i wouldn't have chosen the tremor lib, obviously).

Accuracy must be normal, as the guy says there's not much speed difference. However being able to switch that myself would be good (as I have no clue where the difference lies).
When i tried both "slow int" and "fast int" of the jpeg lib for my picture viewer, i ended up with the slow int dct in asm being faster than the compiled fast int dct

With HisoftC++ 4.0 (= MaxonCPP), in addition to linking with a preassembled .o, I can output an asm source containing the original C statements as comments, and assemble that directly with PhxAss. I think the output of VBCC should be good enough (if it can do that).

Btw, perhaps a more recent lib that the one he used would be fine - i don't want to miss some streams. Where to fetch that (and if it'll compile or not) is another story.

Who knows, perhaps some routine here might end up in the asm compo thread

I already have a FLaC decoder that runs (mostly) real time on 030, I want to see if it's doable for OGG as well.

[matthey]

Originally Posted by meynaf

I want to be able to mix that code with handwritten asm, i.e. regular hunk object format (= not GCC).

The older "unofficial" Amiga versions of GCC can output Amiga hunk executables.

Originally Posted by meynaf

Whether it's compiled for 68000 or 68020+ does not matter much (but no FPU ; else i wouldn't have chosen the tremor lib, obviously).

Accuracy must be normal, as the guy says there's not much speed difference. However being able to switch that myself would be good (as I have no clue where the difference lies).
When i tried both "slow int" and "fast int" of the jpeg lib for my picture viewer, i ended up with the slow int dct in asm being faster than the compiled fast int dct

Ok. Compiled with -m68020 -O2 -fomit-framepointer -noixemul and _MC68020_ASSEM_ and _LOW_ACCURACY_ defines are commented out.

The attached archive has the executable with symbols which help ADis and readability of the disassembly. ADis does a nice job of disassembling but I spotted one little error at $lab_fbbe where it decided code was a string (several bytes in a row which could be text and zero terminated). It would be possible to fix these rare errors (and disassemble dead code) but would require analyzing the data again later on another pass. Disassemble with:

ADis -m2 -d0 -dc fbbe oggv_dec

Then assemble the result and test for errors and compare to the original executable. If there are no problems, I would then use:

ADis -m2 -d2 -dc fbbe oggv_dec

This turns off some instruction sizes which can then be optimized. This includes branch sizes. Vasm can re-optimize these both forward and backwards but PhxAss and most other assemblers can not. The code will usually shrink noticeably as vasm has a much better peephole optimizer than GCC's GAS.

This should give you some pretty code with symbols to hand edit. Let me know if you need anything else.

[meynaf]

Originally Posted by matthey

The older "unofficial" Amiga versions of GCC can output Amiga hunk executables.

I really just hate GCC, both ancient and recent

Originally Posted by matthey

Ok. Compiled with -m68020 -O2 -fomit-framepointer -noixemul and _MC68020_ASSEM_ and _LOW_ACCURACY_ defines are commented out.

Seems good enough.

Originally Posted by matthey

The attached archive has the executable with symbols which help ADis and readability of the disassembly.

You bet it does. Only missing thing is the original C code

Originally Posted by matthey

Disassemble with:

ADis -m2 -d0 -dc fbbe oggv_dec

Then assemble the result and test for errors and compare to the original executable. If there are no problems, I would then use:

ADis -m2 -d2 -dc fbbe oggv_dec

This turns off some instruction sizes which can then be optimized. This includes branch sizes.

I couldn't get an identical exe.
The exe with opt 0 is smaller because phxass won't put debug sections by default in my setting ; relocs are differently sorted and there are a few instructions assembled differently (e.g. 4C03 2800 that becomes 4C03 2802).
But anyway it appears to be working properly ; i checked the output on some example and it's identical.

You may be surprised but PhxAss did a better optimising job on the -d0 version than the -d2

Originally Posted by matthey

Vasm can re-optimize these both forward and backwards but PhxAss and most other assemblers can not.

PhxAss CAN optimise both forward and backward branches.
Else I wouldn't be using it.
In fact it's about as good as vasm as peephole optimizer ; there is just a stupid case it misses. And it's a lot faster

Originally Posted by matthey

The code will usually shrink noticeably as vasm has a much better peephole optimizer than GCC's GAS.

I get a size of 98632. About the size of my actual DM but hopefully with lots of data.

Originally Posted by matthey

This should give you some pretty code with symbols to hand edit. Let me know if you need anything else.

Seems enough this way. Thanks for your help

Just a little suggestion : an option to output more than one value per DC directive. Else large data makes the source really too long.