Page 2 of 2

Re: 64 it compiler

PostPosted: Wed Jul 27, 2016 9:30 pm
by X512
It is also possible to add exception table entry dynamically by using RtlAddFunctionTable. Another method is using vectorized exceptions. So exception handling is not a big problem.

Re: 64 it compiler

PostPosted: Thu Jul 28, 2016 8:52 am
by Robert
Interesting, but I can't pretend to understand this in any detail.

X512 wrote:I think that most complex task of porting BlackBox to 64 bit is fixing address arithmetic in various modules...

Cuno addressed this point:
We'll have to check whether 64-bit pointers in the BlackBox libraries cause problems. Here we could use the compiler to flag conversions between integers and pointers, in order to find all these places systematically. There shouldn't be too many of them, probably the worst part would be the layout-optimized meta information for module Meta.

He also said:
For the Win64 APIs, new header files exist and the interface modules will have to be adapted (different alignments and the like). That's a real headache, and probably the worst problem of all.

Re: 64 it compiler

PostPosted: Sun Aug 14, 2016 8:21 pm
by Ivan Denisov
Using of LLVM should be good way for fast reaching of this goal.

This idea was shared few times in OberonCore board: ... 459#p95459

Also we have no money to invest in the compiler optimization. LLVM can use open-source optimizing compiler.

The problem again with dynamic module loading. If it is possible with LLVM, that would be great luck.

Re: 64 it compiler

PostPosted: Fri Aug 26, 2016 1:49 pm
by X512
Integration LLVM with BlackBox cound be difficult. Not only code, but meta information should be generated. Compiler should generate valid ocf file for BlackBox dynamic (StdLoader) and static (DevLinler) linker. DLLs, ELFs and LLVM internal format can't be used because they are incompatible with BlackBox runtime and don't provide required meta information that is heavily used by framework.

Since LLVM is written in C++ making BlackBox binding would be difficult. Possible solution may be making native backend for existing Component Pascal compiler that generate LLVM code with meta information in format recognized by LLVM. Then pass that module to DLL written in C++ that use LLVM to generate platform specific code and generate BlackBox native module format (ocf, documented in Dev\Spec\ObjFile.odc).

Ivan Denisov wrote:The problem again with dynamic module loading. If it is possible with LLVM, that would be great luck.

If ocf module will be generated, BlackBox native dynamic loader can be used. Other formats are incompatible with BlackBox runtime, because they don't provide required meta information in required format.

Re: 64 it compiler

PostPosted: Sat Feb 04, 2017 5:42 pm
by Romiras
At Reddit user Rusky suggested to look on alternative of LLVM. It called libFirm:
Rusky wrote:It doesn't have the architecture support of GCC or LLVM, but it's a lot simpler and works pretty well. It has an example C99 frontend and a Brainfuck tutorial as well.

Code generation for x86-64

Re: 64 it compiler

PostPosted: Sun Feb 05, 2017 5:04 pm
by rko

Re: 64 it compiler

PostPosted: Wed Oct 11, 2017 8:03 am
by Ivan Denisov

I just found that it has Component Pascal version ... 0.6/source

It uses GPCP compiler. I think, that it can be ported to BlackBox.

Re: 64 it compiler

PostPosted: Mon Jun 24, 2019 5:12 pm
by Mav
Hello again.

I would like to know if this topic was given some further thoughts meanwhile.
I have been a very long time user of Blackbox. I enjoy this a lot even today. I am happy that this community project exists to keep it somewhat alive. I would like to keep using it for as long as it is any viable.
I suppose there are various ideas what kind of development has priority going forward. There always is plenty to be done. I thought I also throw in my own thoughts on this.

Even a low end gaming computer today has 16gb of ram and 2 - 4 gb vram. Mid tier it is 4 - 8 gb vram. High end it is 32 - 64 gb system ram. A workstation even has 16+ gb vram and 128+ gb sys ram.
Since the 4gb address space of 32bit applications is shared across both video and system ram, the situation is further intensified. And the numbers given above are likely to at least double in the next 5 to 10 years.
I understand the argument that for many types of viable applications still, the current limits are sufficient, even if it is becoming a tiny fraction of what a modern machine can offer.

Personally I am in the situation that I do work that is both intense on graphics and general data. Basically I need access to as many resources as a given machine can offer.
I can make do with 4 gb total. But I am increasingly facing the pressure of the question, why I should limit myself like this, when it is a mere 10% of what my current machine can do.
Being able to take full advantage of my hardware would allow me to produce things 10 times as great, in very direct and obvious ways.

There are examples of past developments, where people had a love for an architecture, like the Amiga, for specific reasons of how it is programmable.
Eventually though, since the developments of these lineages stopped, the rift in performance and resources became so vast, that begrudgingly people had no choice than to migrate to a platform they didn't enjoy quite as much.
In a way, this is the situation I find myself in. For me, the question of going 64 bit is crucial now -- and no marketing gag, like it might have been 10 years ago.

Still, I might not be representative for the typical user base of Blackbox, maybe. I wanted to share my story anyway for what it's worth. This is where my personal priorities are right now.
I do understand that going 64 bit is no trivial task. Though it might also be worth noting that this is a type of work that has to be done only once. There is reasonable doubt we will hit another such limit anytime soon.

At any case, thank you so much for the work you put in so far.

Re: 64 it compiler

PostPosted: Fri Jul 19, 2019 8:14 am
by Ivan Denisov
Mav wrote:Hello again.

Thank you for sharing your story.

The 64-bit compiler in the case of open-source project requires experienced people learn and work together for the same aim.
If you have some time or resources to make contribution to this topic, let discuss this.

While there is no ready solution, a lot of work can be done by parallelizing the algorithm and share by separate BlackBox instances, which communicate with each other. Maybe you can improve your application by such approach. You will get not only more RAM, but also more CPU.