[tdf-discuss] Re: Will win64 native build exist on 3.5.0 or at least 3.5.x releases?

Here is a report I wrote after working on x64 Windows LO compilation
during Novell Hack Week back in February. No further work has been
done. Everything done is in git.

I worked on making LibreOffice build as x64 (AMD64) code on Windows. I
used the same compiler suite as normally when building current
LibreOffice, i.e.  Microsoft's Visual C++ 2008, just the x64 toolchain
instead of the x86 one.

My goal was not to produce a complete installable build just in one
week, but to show that it can be done and get so far that at least
some tests run successfully, and there I succeeded.

Porting LibreOffice to a new platform consists of some trivial tasks
like defining new LibreOffice internal codenames and whatnot for the
platform, one hard bit: Porting the so-called C++-UNO bridge to the
platform, and then a bunch of unexpected less hard stuff.

Porting the C++-UNO bridge requires knowing the platform calling
convention and exception handling in minute details. Dynamic
generation of code for short "trampolines" is involved, so some
assembly knowledge is required. Also a small amount of "normal"
(non-dynamically-generated) assembly code.

The x64 Windows calling convention is luckily quite clean, simple and
thus IMHO elegant. Dare I say that it is more elegant than the AMD64
System V ABI used on Linux, with its complex rules on how to allocate
registers for parameters.

Sure, thanks to the simplicity, it uses much fewer registers for
parameter passing than the Linux one. There are always a maximum of
four parameters passed in registers, either integer or floating point
ones. One parameter always takes one register, parameters larger than
64 bits are always passed through pointers.

The exception handling mechanism used by MSVC on x64 is complex, but
luckily it is roughly similar to that on x86 Windows.

In addition to the trivial tasks and the C++-UNO bridge, there were of
course a bunch of minor changes needed here and there to get the code
to compile. After all, x64 Windows is different from all (?) other
64-bit platforms in that the long type is 32 bits. The LibreOffice
codebase is famous for its age and messiness, and consistent use of
sane integral types is not one of its strong points.

For instance, there is an infamous legacy type in LibreOffice's
"solar" layer called ULONG which surprisingly isn't typedeffed as
(effectively) unsigned long, as one might suspect from its name, but
as uintptr_t.

That type is then mostly used as if it was unsigned long anyway, for
instance there were a few assumptions that unsigned long literals like
42UL are of ULONG type. Of course, on other 64-bit platforms it
doesn't matter, as both unsigned long and uintptr_t are 64 bits
anyway, but this broke the compilation in a couple of places. There
were a mass of warnings, obviously, as the code converts liberally
back and forth between integral types . It remains to be seen then
once the actual LibreOffice application is running on x64 Windows how
many of those warnings actually cause run-time issues.

So what did I then achieve, concretely? 

1) most (maybe all even, I haven't verified exactly) of LibreOffice
compiles as x64 Windows code.

2) The extensive C++-UNO bridge test in "testtools" runs fine as long
as one comments out the exception handling testing.

What remains to be done? 

1) The exception handling part of the C++-UNO bridge. I worked on this
last night and think it should be achievable. I have found good
3rd-party documentation on how it works, open source code even, and
understand basically what the existing code for 32-bit Windows is
doing, and what the x64 one should do.

2) Enabling also Java and the Mozilla bits in the build. I disabled
them for now when building, didn't want to get stuck on those parts.

3) Verifying that the whole monster then actually runs.

4) Building an actual installer for it. Hopefully the
installer-building mechanism doesn't even need to be aware that it is
building an installer for 64-bit code.

How useful is this work? That is a hard question. 

As such, running LibreOffice as a 32-bit process "should be enough for
everybody". It's hard to imagine a situation where one would need to
manipulate gigabyte-sized documents in LibreOffice. On Windows there
isn't the same concern as on Linux where one wants to avoid needing to
have both 32- and 64-bit libraries installed; at least so far all
64-bit Windows editions provide the full set of system libraries as
both 64- and 32-bit.

But it was a *very* interesting thing to hack on. And it might
eventually be a nice feature for LibreOffice, at least among the
slightly clueless who think 64-bit code is inherently better than
32-bit code on a 64-bit OS. And who knows, maybe some day Intel or AMD
produce x64 CPUs that don't have 32-bit mode any more, and there are
corresponding Windows editions that are 64-bit only.




-- 
Unsubscribe instructions: E-mail to discuss+help@documentfoundation.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted