64 it compiler

Usage of the framework, compiler and tools

64 it compiler

Postby rko » Tue Jul 12, 2016 4:44 pm

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
rko
 
Posts: 5
Joined: Tue Jul 12, 2016 4:34 pm

Re: 64 it compiler

Postby Ivan Denisov » Tue Jul 12, 2016 6:59 pm

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.
User avatar
Ivan Denisov
 
Posts: 238
Joined: Tue Sep 17, 2013 12:21 am
Location: Krasnoyarsk, Russia

Re: 64 bit compiler

Postby rko » Tue Jul 12, 2016 7:31 pm

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
rko
 
Posts: 5
Joined: Tue Jul 12, 2016 4:34 pm

Re: 64 it compiler

Postby Ivan Denisov » Tue Jul 12, 2016 9:20 pm

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 ?
User avatar
Ivan Denisov
 
Posts: 238
Joined: Tue Sep 17, 2013 12:21 am
Location: Krasnoyarsk, Russia

Re: 64 it compiler

Postby rko » Wed Jul 13, 2016 8:50 am

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.
rko
 
Posts: 5
Joined: Tue Jul 12, 2016 4:34 pm

Re: 64 it compiler

Postby X512 » Wed Jul 20, 2016 3:16 pm

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.
X512
 
Posts: 37
Joined: Sat Feb 07, 2015 2:51 pm

Re: 64 it compiler

Postby rko » Thu Jul 21, 2016 7:17 pm

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.
rko
 
Posts: 5
Joined: Tue Jul 12, 2016 4:34 pm

Re: 64 it compiler

Postby Robert » Tue Jul 26, 2016 12:24 pm

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: 113
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: 64 it compiler

Postby Robert » Tue Jul 26, 2016 12:36 pm

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.
User avatar
Robert
 
Posts: 113
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: 64 it compiler

Postby X512 » Wed Jul 27, 2016 7:34 pm

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.
X512
 
Posts: 37
Joined: Sat Feb 07, 2015 2:51 pm

Next

Return to Common questions

Who is online

Users browsing this forum: No registered users and 1 guest

cron