ADis disassembler

[matthey]

Originally Posted by meynaf

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

The whole C src is available if you follow the directions on compiling.

Originally Posted by meynaf

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.

It is good to look at the differences but larger disassemblies can have some differences. Vasm can have a few differences also. By default, vasm respects instruction sizes which is more logical. Leave off the sizes and the peephole optimizer goes to work. PhxAss has inconsistent default behavior and quirkiness in comparison.

Originally Posted by meynaf

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

Strange. The default is -d1 which is in between and close to the original ADis output (last version by Martin Apel). I think a few users would be happy if I made -d0 the default but it does make dissassemblies larger too.

Originally Posted by meynaf

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

The docs I was reading for PhxAss must be old then. Optimizing branches in both directions is very convenient. DevPac couldn't do it.

Originally Posted by meynaf

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

It looks like you can remove some dead code:

_ov_test_callbacks(), _ov_test(), _ov_test_open(), _ov_streams(), _ov_seekable(), _ov_bitrate(), _ov_bitrate_instant(), _ov_serialnumber(), _ov_raw_total(), _ov_pcm_seek_page(), _ov_pcm_seek(), _ov_time_seek(), _ov_time_seek_page(), _ov_raw_tell(), _ov_time_tell(), _ov_comment(), _ogg_page_packets(), _ogg_sync_pageout(), unnamed lab_4130 function, _vorbis_comment_query(), _vorbis_comment_query_count(), _oggpack_bytes(), _oggpack_bits(), _vorbis_lsp_to_curve(), unnamed lab_fbbe function

Only remove the code and not the data they refer to as some of these functions have been inlined. GCC leaves the original code for functions it inlines unless they are declared as private. Some of this code is test and debug too. It should be possible to save a few kb here. The way ADis disassembles, it is possible to identify this. Strip the symbols, disassemble and see which functions have no labels at the top.

Originally Posted by meynaf

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

I have made an effort to allow smaller disassemblies which is more important for people with limited memory. Adding multiple data per line would require extra formatting when outputting -a options and more care not to overflow the line buffer. I would rather not add more complexity here but it would be a nice option if it was simple and easy.

[meynaf]

Originally Posted by matthey

It is good to look at the differences but larger disassemblies can have some differences. Vasm can have a few differences also. By default, vasm respects instruction sizes which is more logical. Leave off the sizes and the peephole optimizer goes to work. PhxAss has inconsistent default behavior and quirkiness in comparison.

It's just a different way of seeing things. PhxAss with "opt 0" will leave everything "as is". Else there is no reason to refrain from optimizing.

Originally Posted by matthey

Strange. The default is -d1 which is in between and close to the original ADis output (last version by Martin Apel). I think a few users would be happy if I made -d0 the default but it does make dissassemblies larger too.

Seems -d1 is the best result for my own use.

Originally Posted by matthey

The docs I was reading for PhxAss must be old then.

Quite old indeed. My doc says it got added in version 3.10 (i'm using version 4.44).

Originally Posted by matthey

Optimizing branches in both directions is very convenient. DevPac couldn't do it.

There are a lot of things DevPac couldn't do

Originally Posted by matthey

Only remove the code and not the data they refer to as some of these functions have been inlined. GCC leaves the original code for functions it inlines unless they are declared as private. Some of this code is test and debug too. It should be possible to save a few kb here. The way ADis disassembles, it is possible to identify this. Strip the symbols, disassemble and see which functions have no labels at the top.

Don't worry, i know how to remove dead code in asm programs
Some of this code might be useful later, though. Like giving extra infos about the stream, or seeking.

Originally Posted by matthey

I have made an effort to allow smaller disassemblies which is more important for people with limited memory. Adding multiple data per line would require extra formatting when outputting -a options and more care not to overflow the line buffer. I would rather not add more complexity here but it would be a nice option if it was simple and easy.

You can :
- make the multiple data per line mutually exclusive with -a options
- output 16 bytes per line (4 longs, 8 words, 16 bytes)
For me it's simple and easy.

[matthey]

Originally Posted by meynaf

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

Some versions of GCC seem to not use a HUNK_END between hunks when compiled with ixemul. I made the ADis hunk loader code more robust so it works now with more ixemul executables (the original ixemul oggv_dec). I added support for HUNK_UNITs with up to 255 hunks so some .o and .lib files disassemble now (vbcc and SAS/C are best bets while GCC uses some non-Amiga standard). Also, some HUNK_OVERLAY hunks were not found before. The new ADis is attached in the first post of this thread. The changes are significant so let me know if I broke anything.

[kamelito]

Is the new version available on the first post ?
Kamelito

[matthey]

Originally Posted by kamelito

Is the new version available on the first post ?
Kamelito

Yes.

[meynaf]

Originally Posted by matthey

Some versions of GCC seem to not use a HUNK_END between hunks when compiled with ixemul.

And the OS accepts that as valid executables ?

Originally Posted by matthey

The changes are significant so let me know if I broke anything.

From what i've seen everything is fine.

Regardless of the version, apparently it easily misses dead code blocks. However an option to automatically detect as code a block that ends with dc.w $4e75 would fix many of these.

During my tests i checked the IRA disassembler and didn't like its output, but it has a nice option to read code addresses from a config file. Shouldn't be difficult : after all they're just extra options (-dc, -dd and perhaps others as well) in a separate file instead of the command line. If you don't know what to do

[matthey]

Originally Posted by meynaf

And the OS accepts that as valid executables ?

Yes. The AmigaOS is very forgiving about unusual executables. Perhaps it was too lenient as the many different variations make it more difficult to write a hunk parser which handles everything the AmigaOS does. ADis still does not handle all executables but I think it is now more forgiving and in better shape to be further improved if necessary.

Originally Posted by meynaf

From what i've seen everything is fine.

Good. The many different variations make testing difficult too.

Originally Posted by meynaf

Regardless of the version, apparently it easily misses dead code blocks. However an option to automatically detect as code a block that ends with dc.w $4e75 would fix many of these.

Yes, this is doable but requires another mini-pass as the data has to be analyzed and then the end of the holes checked for $4e75. Then the code from the newly disassembled code has to be processed. I vaguely remember attempting to add basic support for disassembling what was left once but I don't remember what problems I had.

Originally Posted by meynaf

During my tests i checked the IRA disassembler and didn't like its output, but it has a nice option to read code addresses from a config file. Shouldn't be difficult : after all they're just extra options (-dc, -dd and perhaps others as well) in a separate file instead of the command line. If you don't know what to do

IRA has some very nice processing features even if the output is lacking flexibility. I looked at it before finding ADis but the disadvantages of no FPU support and ugly source code stopped me from using it for my goals. ADis has very nice output features but lacks some of the processing features. D68k is also a very good disassembler. I use them all from time to time.

I began preparing ADis to be able to parse lines from a config file like it does for the command line but it was enough work that I became sidetracked before I finished. It is possible to create an AmigaDOS script which calls ADis with a long command line of options. This allows saving the disassemble config for the file but has a restrictive line length limit. I would like to add support for a config file but it is not a priority. Sorry if I am in more of a bug fix and maintenance mode currently. I have some other projects that need attention too. The source is included if you want to give it a try.

[meynaf]

I've found a case where the code isn't followed but could have been.

The output was something like :

 jmp 2(pc,d2.w)
lab_9946
 rts
 dc.l $4e754e75
 dc.l $60166078
 dc.b "`BS@7@",0
(etc)

instead of jmp lab_9946(pc,d2.w) followed by the code.

[phx]

The reassembler cannot know where the code is, as d2 can have any negative or postive value. Most tables will start with d2=0, but you cannot be sure. And the length is completely unknown.

Usually jump tables have to be marked as such by the user.

[matthey]

Originally Posted by meynaf

instead of jmp lab_9946(pc,d2.w) followed by the code.

Yea, everything phx said. The disassembler does not know the value in d2. The most difficult part would be detecting the end of the table but the start would be a guess too. Supporting many different variations of jump tables is more complex that it first looks (I have had to rework the code several times to make it more flexible and correct). ADis should recognize most compiler generated jump tables but there are too many hand coded assembler jump table variations.

@phx
Have you tested the new version of ADis with some vbcc .lib and .o files? I only tested with a few examples and HUNK_LIB is still not supported although I couldn't find any cases where it was used.