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 <dam...@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 <dam...@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 <p...@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-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> >>>
