Err, I know a WHOLE lot more than python. (not to be rude or anything, but I do) And I was planning to do this in C++. I've set up the google project, and was going to start discussing how this was going to work, and meant to contact you, but totally forgot.

I know you know more than Python, but I wasn't sure if you knew C++ or not. Python and C++ seemed to be the two languages under discussion, so I limited myself to mentioning those.

oh, okay.

I don't "know" C++ to the level that I consider "knowing" a language is, but I can read/write it.

I am quite offended now, but a disassembler is really easy! The GUI is also all mine, I read several books and tutorials on wxPython and consider myself quite experienced in wx. Disassembling is quite easy, I consider Tokenization for gods :S

@C++-Talkers: I know C++, am reading another book on it for Prizm Suite.

And from my point of view, tokenization is no harder than disassembly, hence my concern.

Personally, I find writing and testing code much more helpful per unit time than reading about a language.

I need to know the basics don't I? (such as loops, conversions, variables), stuff I need to be very comfortable with.

True, but you said you already knew C++, so that would be stuff you already know. Plus, after you learn ten or fifteen languages, there isn't that much new syntax to learn, just new quirks and tricks.

*bump* Anyway, Graphmastur (I believe) has been working on a Java disassembler, and I would like to develop one in C++ or Python at some point. I know that the Linux program "objdump" can dump x86 ELF binaries into text ASM; does anyone know if there is an SH3 objdump port?

I recently found a program that will take Java bytecode, and give you an XML file that contains all the instructions, names of variables, inputs to routines, outputs, and more. Could this be something you are looking for? The program / project is XMLVM.

Awesome project, but I'm afraid you have the causal relationship a bit backwards. Graphmastur is using Java to disassemble SH3 binaries into SH3 assembly.

Seems like a waste of effort to write object code analysis tools when a GNU toolchain is perfectly capable of understanding the SH3.

Not sure what gdb would think of sh3 (probably if built with the right features enabled it would be fine), but a bit of googling showed that a correctly configured objdump gave a perfectly serviceable disassembly, so I suspect all that would be required would be massaging the Prizm's addon files into something you could make the GNU tools understand.

If you don't like that, Renesas' HEW I'm sure provides a simulator of some sort, and it's pure idiocy to ship a simulator without some sort of disassembly capability, so you could probably find some way to use HEW to do the same thing.

Woo, I'm glad to hear that objdump would do the trick. As you say, we'd just have to massage the file format into something the toolchain wouldn't laugh at.

Did someone ask for a GNU sh3 toolchain http://jonimoose.net/prizm/sh3-unknown-elf/

Yay for Jonimus and his epic work. It looks like the main obstacle standing between gcc and the Prizm, and the Prizm and gdb/objdump, is a better understanding of the Add-In format, which I believe Qwerty is hard at work on.

Hopefully that translation will be easy enough to take care of. Looking at IDA pro for disassembling may be worth it as well.

I'm a little cautious about that course of action thanks to BrandonW's discussions of the program over the years, but I'm certainly open to giving it a try.

As I understand it, converting an add-in to just code is quite simple - just remove the first 0x7000 bytes as well as the last 4 bytes. Doing it the other way around is much harder because we have to mess with the checksums.

That's not precisely true, because the ELF format that is widely used on Linux systems has its own header, and for standard tools to not throw a fit, it would be a good idea to add that header to our programs. Or, alternatively, teach objdump, gcc's postprocessor, and gdb what the header looks like.

Oh, okay... So it seems like extracting the code from the add-in is easy, but converting it into something that the programs understand is trickier. Still, I believe that the add-in format is documented well enough to do this (it's on the wiki).

Um, not quite. The only real work I've been doing that relates to the Prizm has been on my libs and a secret project.