Re: Win64 progress at almost 50%; the challenging Win64<->UNO bridge looms

[Damjan Jovanovic <da...@apache.org>]

I've now committed a preliminary Win64<->UNO bridge I've developed.

It compiles and links but haven't tested it yet.

On Thu, Dec 6, 2018 at 8:40 AM Damjan Jovanovic <da...@apache.org> wrote:

> The main/bridges module has been ported to gbuild.
>
> It consists of 3 deliverables, java_uno.jar and its JNI code in a java_uno
> C++ library which comprise the Java<->UNO bridge, and then an <ABI>_cppu
> library (eg. msci_cppu, gcc3_cppu) which comprises the C++<-> UNO bridge.
> Blissfully, there are no header files delivered to solver, all are used
> internally within main/bridges only.
>
> We only care about the C++<->UNO bridge at this stage; Java isn't used
> during AOO startup and any problems in it can be fixed later.
>
> The source for this C++ bridge is in main/bridges/source/cpp_uno.
> main/bridges/source/cpp_uno/shared
> is code shared across all platforms, while:
> main/bridges/source/cpp_uno/<ABI>-<OS>-<CPU>
> is the platform-specific code.
>
> The shared code is 9 files and 1562 lines in total, and exports 3
> functions:
> SAL_DLLPUBLIC_EXPORT sal_Bool SAL_CALL component_canUnload(TimeValue *
> pTime) SAL_THROW_EXTERN_C;
> SAL_DLLPUBLIC_EXPORT void SAL_CALL uno_initEnvironment(uno_Environment *
> pCppEnv);
> SAL_DLLPUBLIC_EXPORT void SAL_CALL uno_ext_getMapping(uno_Mapping **
> ppMapping, uno_Environment * pFrom, uno_Environment * pTo)
> SAL_THROW_EXTERN_C();
>
> These are called by higher layers of UNO and eventually reach the
> platform-specific code somehow; I am still investigating that part.
>
>
>
> On Tue, Dec 4, 2018 at 7:18 AM Damjan Jovanovic <da...@apache.org> wrote:
>
>> Thank you Patricia.
>>
>> Yes knowing some x86_64 assembly would help, but don't go too far, it's
>> only about 2000 lines of code on other platforms. I don't know much of it
>> myself yet; just that the 32 bit registers grow to 64 bits and have an
>> additional name starting with "R" for the 64 bit version (eg. the 32 bit
>> EAX has a corresponding 64 bit RAX, EIP and RIP, etc.).
>>
>> The Win64 ABI has similarities to the *nix ABI (
>> https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions)
>> and we already have the *nix ABI implemented, so we might be able to reuse
>> some of it. We can certainly copy its x86_64 assembly as needed ;).
>>
>> The code is all in main/bridges. I want to port that module to gbuild
>> first, so I have a good understanding of its general structure.
>>
>> A LibreOffice developer blogged about his porting experience at
>> http://tml-blog.blogspot.com/2011/03/
>> Apparently exception handling was the hardest part.
>>
>>
>>
>>
>> On Sun, Dec 2, 2018 at 10:39 PM Patricia Shanahan <pa...@acm.org> wrote:
>>
>>> I have many years of professional assembly language programming
>>> experience. I have learned several assembly languages, but not one for
>>> Win64. I also have a good general understanding of stack management and
>>> call/return from compiler and operating system work.
>>>
>>> Would it be useful for me to start learning the appropriate assembly
>>> language and stack management? If so, I would like pointers to the
>>> assembler and ABI etc. conventions.
>>>
>>> On 12/1/2018 12:22 AM, Damjan Jovanovic wrote:
>>> > Hi
>>> >
>>> > At least 81 modules (44.26%) successfully build on Win64 now, up from
>>> 67
>>> > (36.61%) before.
>>> >
>>> > At present the build breaks in main/bridges, which I can hack past, but
>>> > then modules like cli_ure and i18npool break, probably because they
>>> need
>>> > the missing Win64 UNO bridge.
>>> >
>>> > This Win64 <-> UNO bridge has to call arbitrary methods, translate
>>> > arbitrary exceptions, etc. between UNO and C++. It has to be written
>>> > predominantly in assembly language, and needs to implement the
>>> platform's
>>> > calling convention, deal with its ABI, RTTI, etc. - quite a challenge.
>>> >
>>> > Wish me luck, or join and help?
>>> >
>>> > Damjan
>>> >
>>>
>>> ---
>>> This email has been checked for viruses by AVG.
>>> https://www.avg.com
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>