I know, I know, I already have more programs than I can possibly finish in 80 lifetimes. So with the stunningly complicated program flow that is Doors CS, and the growing headache of balancing a few mind-numbingly long source files with a folder full of smaller, more specific files, it would really help me to have something that could print out the program flow of the whole shell. I'd like to make it output postscript files (something I learned how to do in compilers), in which each page is a source file. It should run through, storing each label, and tracking branches ([jp|jr] [z|nz|p|m|c|nc] and call/ret) and creating a diagram of labels and flow. Any thoughts on this, including ideal implementation? The easiest thing would be to make it a python program; any objections?

yes

Any specific objections that involve suggestions of a better and alternate way of writing this project?

I'm sure you're already aware that mapping program flow perfectly is impossible The best you could hope for is to generate a graph of possible flow, but that shouldn't be too hard if you parse the source for potentially branching instructions. I'd think that more important would be writing a good OpenGL renderer to display + explore the graph visually, and some form of cycle detection.

No, not literal program flow, that would be an emulator. I mean possible program flow, without of course awareness of push/ret types of jumping or other sp and smc manipulation. I thought about a 3D view, but I almost feel like that would make me more confused. How about something to generate a TBM build of your program's branch flow?

Edit: OK, here's a start! Parses through the given file, recursing into #included files as necessary. No storage of labels and branches and calls yet, just counting:


Code:

............................................no.

I would use PHP as the language and output a pdf, html, or image. I personally have no use for this as I do not know asm but I think that that would be an easy way to do it. PHP would also offer easy ways to make it command line, web based or both with only separate input converting tools (take the argc/argv or the request data and put into a common format).

Clearly you have not used Python. Python lets you do all the things you mentioned, except faster and better. Python can also be command line or web (I'm making it command-line for now) and is more widely supported as an end-user interpreted language than PHP: in other words, more people can natively run .py than .php.

In other news, I have the basic PS output (I'm using PS because it's an easy-to-output form that Adobe Pro 8 can open like PDF, or almost any computer can print it directly), so now I need to figure out how exactly I want to represent program flow.

What about self modifying code? What if you had jp $0000 and you overwrote 0000 with the address you want to jump to?

Right, as I said, there's no simple way to handle it, so I'm simply making it clear that it will not understand SMC. Since my primary goal in writing this is to help me develop Doors CS more quickly, it's not a big hardship; only some of the more finicky CALCnet2 stuff takes place in RAM, and that's disabled at the moment.

You should make it sophisticated enough to look for sp manipulation and at least generate some output saying that the program flow can't be traced any further along that branch. You could probably do something similar with call/pop/push/ret matching techniques to try and check for stack imbalances and use that to check for untraceable ret(s) (make this one command-line configurable since some programs probably have lopsided pop/push references in code due to odd loop designs).


I didn't say 3D, I said OpenGL. Any reasonably complex program (and certainly DCS) is gonna be a flipping jungle when displayed in a static format. You'll want to be able to explore branches interactively when working on a specific portion of the project, and since program flow is more of a directed graph than a tree you'll want to check your data structure for cycles or when you try to render it you'll hit huge problems. Store non-branching chunks of code as nodes, and each edge is associated with a branch instruction and colored based on the what type of instruction it is. Render 2D boxes with code inside and edges coming off each branch instruction. Better yet, EACH line of code is a node, and branch instructions have multiple edges coming out, whereas non-branching only have one.


I like it. We can take screenshots and call it "modern art"

I think you should post the DoorsCS source code. I might try to write something similar just for the hell of it. Elf seems to have some ideas too that he could try.

i have an old version, but it will work just as well for the sake of testing code. I sent you and elfprince the link.

bloody 'ell, I don't want to code a menace like that. I just want to tell you how to do it. Actually, I very well might give it a shot. We'll see.

Haha, totally understood, but if you and Kllrnohj do decide to give me a run for my money, I'd be happy to see when you two are able to come up with.