I had to delete all of my personal BB files and then restore from my backup.
I have lost 2 days of modifications but those were not critical.
I am running on build 719.
-Doug
What's next?
- DGDanforth
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Re: What's next?
JosefJosef Templ wrote:I would like to have a disassembler for the i386 code generated by the BlackBox compiler.
Work on the compiler is harder than necessary if you don't see what the compiler generates.
Naturally, this would be an extension of DevBrowser.ShowCodeFile, which currently only shows the header
of a code file but not its full content.
Such a disassembler is quite simple, in principle. Basically a loop over an opcode decoder
and a couple of CASE statements that translate the opcode to the mnemonics together with the operands.
All we need is a specification of the overall object file format but this can be reverse engineered from the compiler
unless it is available somewhere.
I have a disassembler for 8086 & 80386 written in Turbo Pascal 3.0 from 1985. It disassembles com files by starting with the offset of 100 hex. Currently I translate it to Component Pascal. Do you know the starting point or the structure (header) of the ocf file?
- Helmut
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: What's next?
At ETH we didn't have a lot of fancy tools for the Oberon system but a disassemblerDGDanforth wrote:Would that also make it easier to support non INTEL processors?Josef Templ wrote:I would like to have a disassembler for the i386 code generated by the BlackBox compiler.
Work on the compiler is harder than necessary if you don't see what the compiler generates.
Naturally, this would be an extension of DevBrowser.ShowCodeFile, which currently only shows the header
of a code file but not its full content.
Such a disassembler is quite simple, in principle. Basically a loop over an opcode decoder
and a couple of CASE statements that translate the opcode to the mnemonics together with the operands.
All we need is a specification of the overall object file format but this can be reverse engineered from the compiler
unless it is available somewhere.
- Josef
was always built first when porting Oberon to a new architecture.
So, I think the answer is yes.
It may also help Ivan in understanding the differences between a 32-bit and a 64-bit version.
You can also understand it as closing a gap in the features offered by Info->Repository.
When you click on a code file, it displays the header of that file but not the code.
FYI: In the meantime I have looked up the sources of an Oberon distribution for Windows and found a nice
i386 disassembler that was easy to port to BlackBox. I already have a running prototype internally.
- Josef
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: What's next?
Sorry for in inconvenience, Doug, I have to add red warning for this case.DGDanforth wrote:Ivan,
I am VERY unhappy.
I reverted back to build 719 which was fine.
I then compile Cairo successfully, no errors.
I then did the HostPorts change as suggested and rebooted BB.
I could not open BB because it said there was a missing dll.
I deleted all BB 1.7 files and reinstalled from the zip719.
Same problem. Missing cairo dll. How can that possibly be?
You should read the Quick-Start file more carefully in future. Be hones, you just click all commanders?
There is the section Pre-install Requirements:. You should to get necessary libraries and put them into BlackBox folder first. BlackBox can not use CairoHostPorts without these libraries!
All you need to start BlackBox for this case is to delete Host/Code/Ports.odc from your working directory.DGDanforth wrote:I then removed the /USE option in my shortcut and that allowed
me to start BB. Thank God!
I conclude that something has been put into my /USE directory by Cairo
that causes BB on startup to attempt to look for the Cairo dlls. How can that be?
I am stumped! I am also dead in the water without being able to access my menus.
Not happy at all! Thanks Cairo. You have been deleted.
===
In addition I can't compile my files. It says "disk full?"
So something very bad has been done to my BB environment by Cairo.
Because you are working with 2D graphics intensively CairoHostPort will give you many benefits. It draws all the lines with anti-grain rendering so applications became looks more professional than simple WinApi drawing. So I am recommenced you to install libraries and try again.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: What's next?
Most of the work is already done.Zinn wrote: I have a disassembler for 8086 & 80386 written in Turbo Pascal 3.0 from 1985. It disassembles com files by starting with the offset of 100 hex. Currently I translate it to Component Pascal. Do you know the starting point or the structure (header) of the ocf file?
- Helmut
If you are interested I can send you my prototype, which is derived from
Decoder.Mod of ftp://ftp.ssw.uni-linz.ac.at/pub/Oberon/.
- Josef
Re: What's next?
Yes, I am interested in your prototype. It is like a journey back to the old days. There I wrote assembly programs for SC/MP, 8080, Z80, 8086 and Z8000. I didn't believe that we need again a Disassembler. I didn't work with this low level since I use Oberon.
- Helmut
- Helmut
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: What's next?
Using my i386 decoder prototype I discovered another compiler bug.
See attached file.
By comparing the two versions of the procedure Test.Do it is easy to see
the difference and the bug. It is the same kind of bug as issue-#128 but
related to comparison, not to assignment.
- Josef
See attached file.
By comparing the two versions of the procedure Test.Do it is easy to see
the difference and the bug. It is the same kind of bug as issue-#128 but
related to comparison, not to assignment.
- Josef
- Attachments
-
- Test.pdf
- (10.21 KiB) Downloaded 157 times
Re: What's next?
Josef's i386 decoder is grandiose. This tool is a dream. It is perfectly integrated into the BlackBox framework and easy to use.
You just select your module name e.g. ObxHello0 and press the commander (!)DevBrowser.ShowCodeFile
It disassembly the file Obx/Code/Hello0.ocf and display the result.
Another way is to use the menu File -> Open -> Obx/Code/Hello0.ocf -> Read File As: Code File (*.ocf) -> OK
and you get the same result.
- Helmut
You just select your module name e.g. ObxHello0 and press the commander (!)DevBrowser.ShowCodeFile
It disassembly the file Obx/Code/Hello0.ocf and display the result.
Another way is to use the menu File -> Open -> Obx/Code/Hello0.ocf -> Read File As: Code File (*.ocf) -> OK
and you get the same result.
- Helmut
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: What's next?
Well, structurally, it is simply an extension of the output generated by DevBrowser.ReadHeader, so itZinn wrote:Josef's i386 decoder is grandiose. This tool is a dream. It is perfectly integrated into the BlackBox framework and easy to use.
You just select your module name e.g. ObxHello0 and press the commander (!)DevBrowser.ShowCodeFile
It disassembly the file Obx/Code/Hello0.ocf and display the result.
Another way is to use the menu File -> Open -> Obx/Code/Hello0.ocf -> Read File As: Code File (*.ocf) -> OK
and you get the same result.
- Helmut
reuses all the existing infrastructure for the command and the importer.
If there are no objections, I will create an issue for this and present the tool.
- Josef
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: What's next?
There are objections! Why we should put all this stuff to BlackBox basic distribution!?!? All this extensions easily implemented as the extensions.
Josef, prepare subsystem and publish it in CPC or the Center experimental repository.
Josef, prepare subsystem and publish it in CPC or the Center experimental repository.