64-bit compiler

Usage of the framework, compiler and tools
rko
Posts: 5
Joined: Tue Jul 12, 2016 4:34 pm

64-bit compiler

Post by rko »

hi,
i would love to use blackbox for a project - but i need to know if there is a 64 bit version in the works and when it will be available.

thanks in advance
User avatar
Ivan Denisov
Posts: 362
Joined: Tue Sep 17, 2013 12:21 am
Location: Krasnoyarsk, Russia

Re: 64-bit compiler

Post by Ivan Denisov »

Today there is no 64 version of BlackBox, and nobody is working on it. This issue will be discussed accurately after releasing of 1.7 final.
The reason for this is the complex question about the garbage collection mechanism.
As you know BlackBox uses automatic garbage collection. However it is effective for some limited amount of RAM.
If we have to increase the RAM we need to switch to some other algorithms of garbage collection.
We do not want to make the mistakes already done by Java etc.
rko
Posts: 5
Joined: Tue Jul 12, 2016 4:34 pm

Re: 64-bit compiler

Post by rko »

thanx for you fast answer.
too bad, but maybe i have a chance to use it in a later project. everybody wants to ensure 64 bit these days.
so i stick around and hope for the best.
rko
User avatar
Ivan Denisov
Posts: 362
Joined: Tue Sep 17, 2013 12:21 am
Location: Krasnoyarsk, Russia

Re: 64-bit compiler

Post by Ivan Denisov »

Are you working with some big data problems or with a huge databases? Which tasks force you to load more than 4 Gb into the RAM ?
rko
Posts: 5
Joined: Tue Jul 12, 2016 4:34 pm

Re: 64-bit compiler

Post by rko »

big medical databases.
but the "managers" insist on 64 bit and/or the possibility of 64 bit - if needed or not. this seems to be a trend in ALL companies i know.
so i keep watching for 64 bit version.
X512
Posts: 72
Joined: Sat Feb 07, 2015 2:51 pm

Re: 64-bit compiler

Post by X512 »

This managers are bad managers. 64 bit is not critically required everywhere.
big medical databases.
Do you use SQL database? If so, only database engine requires lots of memory. Usually it is possible to run SQL database engine in separate process. Blackbox has ODBC interface. I don't think that database client requires a lot of memory.
For 64 bit Windows it is possible to use near 4GB of memory for 32 bit processes. I have managed to allocate near 4GB in BlackBox.
It is possible to allocate more than 4GB of physical memory and map part of it in process address space.
rko
Posts: 5
Joined: Tue Jul 12, 2016 4:34 pm

Re: 64 it compiler

Post by rko »

that's all correct - but 64 bit is the new fad. other than that, wee need to keeps tons of patients etc in memory.
if the managers are bad - maybe so, but they pay.
User avatar
Robert
Posts: 177
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: 64 it compiler

Post by Robert »

X512 wrote:For 64 bit Windows it is possible to use near 4GB of memory for 32 bit processes. I have managed to allocate near 4GB in BlackBox.
It is possible to allocate more than 4GB of physical memory and map part of it in process address space.
Can you explain in a bit more detail how to do this?

Regards, Robert
User avatar
Robert
Posts: 177
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: 64 it compiler

Post by Robert »

Ivan Denisov wrote:Today there is no 64 version of BlackBox, and nobody is working on it. This issue will be discussed accurately after releasing of 1.7 final.
The reason for this is the complex question about the garbage collection mechanism.
I asked Oms about a 64-bit version in 2004. They did a brief investigation and identified a few tasks that were ok in principle, but some were quite large so would obviously have a significant cost.

But they also identified a problem with no obvious solution. Cuno Pfister wrote
Exception handling rules for 64-bit systems have changed. Debug information in not kept on the procedure activation stack anymore, but in a separate structure (like on Windows CE). Unfortunately this data structure is built upon start of the application, and cannot be extended later. As an effect, no further code (like usual for all BlackBox modules) can be loaded dynamically at run-time.
This either means that the entire application has to be statically linked and run in a separate process outside the development environment. Or, the compiler would have to generate code for NIL checking and the like (which comes free at the moment). This is awkward and incurs some performance penalty, but might be worth it in order to keep the possibility for dynamic loading.
X512
Posts: 72
Joined: Sat Feb 07, 2015 2:51 pm

Re: 64 it compiler

Post by X512 »

Robert wrote:But they also identified a problem with no obvious solution. Cuno Pfister wrote
Exception handling rules for 64-bit systems have changed. Debug information in not kept on the procedure activation stack anymore, but in a separate structure (like on Windows CE). Unfortunately this data structure is built upon start of the application, and cannot be extended later. As an effect, no further code (like usual for all BlackBox modules) can be loaded dynamically at run-time.
This either means that the entire application has to be statically linked and run in a separate process outside the development environment. Or, the compiler would have to generate code for NIL checking and the like (which comes free at the moment). This is awkward and incurs some performance penalty, but might be worth it in order to keep the possibility for dynamic loading.
I investigated and found that Cuno Pfister probably means SEH (preferred exception handling mechanism in Windows) change in 64 bit version of Windows. In 32 bit version of Windows SEH is implemented as linked list of exception handlers usually allocated in stack. SEH is not debug information, it is runtime information. In BlackBox, Kernel.InstallExcp inserts exception handler to head of list and Kernel.RemoveExcp removes handler from list.
According to http://www.osronline.com/article.cfm?article=469 in 64 bit version of Windows SEH is implemented as static table in executable headers that makes implementation of Kernel.InstallExcp and Kernel.RemoveExcp impossible, at least using SEH. But exception handler is installed only in 2 places of Kernel module: Kernel.Init and Kernel.Try. Because of kernel is always statically linked and no other modules requires installing SEH exception handler (in BlackBox, custom exception handlers are handled by Kernel.Try), it is possible to add SEH static table generation for Kernel module in DevLinker.

I think that most complex task of porting BlackBox to 64 bit is fixing address arithmetic in various modules. Lots of modules use INTEGER as address (that should be replaced by LONGINT) and use magic constants as offsets. Kernel use lots of magic constants expecting that pointer size is 4 bytes. Higher level modules also use magic constants, for example Views.Overwritten. Finding all places that depend on pointer size would be difficult task. Not fixing any of such places can cause random crashes, memory corruption and another instability.
Post Reply