BlackBox Framework Center

My proposal for an extended ocf importer is available in branch issue-#142.
For testing download the build from http://blackboxframework.org/unstable/i ... a1.729.zip.

You can click on a code file under Info->Repository,
or you can open an ocf file using File->Open.

The decoded instructions are grouped by procedure.
The procedure heading is a link to the procedure's detail view.
The detail view displays the code of a single procedure merged with its source code.
The source code is again a link to the related module.

Note: The compiler stores only the start position of a statement and in case of a
compound statement this is after the leading keyword (e.g. IF, WHILE).
It would require a lot of additional coding to move this position to the start
of the leading keyword. It can also not be changed easily in the compiler because then
the trap handler would be confused.

- Josef

I tested this version
http://blackboxframework.org/unstable/i ... a1.729.zip
From my point of view, all works fine.

Can we vote for this issue?

Ivan Denisov wrote:I tested this version
http://blackboxframework.org/unstable/i ... a1.729.zip
From my point of view, all works fine.

Can we vote for this issue?

Do we have a diffs file?
I tried going to redmine and could not find the way to a diffs even though on
other issues I was able to do that. I do not remember the sequence of steps
needed to see a diffs file.

In the process of searching I mistakenly changed the topic type to "documentation"
and then changed it back to "feature".

How do I find a diffs file for issue-#142?
-Doug

DGDanforth wrote:Do we have a diffs file?

http://redmine.blackboxframework.org/pr ... 65730f0320

I think, that we should discuss this:
http://community.blackboxframework.org/ ... p=810#p809

I suggest to use this realization of decoder by Trurl
http://oberoncore.ru/bbcc/subs/dev/decoder

Anyway we need to fix Unicode issue here. The names of Unicode procedure names shown wrong way.

Josef, I think we need to correct your realization for it shows correct addresses or to switch to the ready one.

The Unicode issue needs to be fixed, of course.

Regarding the other extensions:
It is of course possible to decode all sections of an ocf file
but it needs additional code. Since so far we never needed to look into the
fixup table etc this is not yet included. I tried to keep it simple.
Note: when we change the compiler we change only the instructions that
are generated, not the way the loader handles the fixups.

If there is an agreement that all sections of an ocf file should be decoded
we can switch to the original ominc decoder that I recently got access to
(thanks to Bernhard). (You see, BTW, a decoder is used by anybody
working on a compiler ).
The ominc decoder consists of 3 modules and does not contain the source merge feature
and is not integrated with the converters.
Giving up the source merge feature for more or less unneeded extensions
is a bad deal for me. So it would either require additional work to combine the features
or It would also be an option to provided the original ominc decoder as an AppStore package.

Instructions that need fixups can not be displayed "correctly" because the fixups are done
after loading the module. They refer to addresses only known at runtime, that's why
they need to be "fixed up" by the loader.
The only thing that may be possible in some cases is to add the target as a comment.
With the source merge feature, however, you see the target anyway from the source.

- Josef

Josef, maybe for this version of the disassembler we can hide addresses? We should not show wrong information, we can show only the instructions without addresses for this case...

I will look into the ominc/trurl sources but it may take a couple of days.

- Josef