|To:||Thiemo Seufer <firstname.lastname@example.org>|
|Subject:||Re: About openoffice linux/mips porting|
|From:||Fuxin Zhang <email@example.com>|
|Date:||Tue, 25 Sep 2007 21:55:00 +0800|
|Cc:||"Maciej W. Rozycki" <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org|
|References:||<46F90261.email@example.com> <Pine.LNX.4.64N.firstname.lastname@example.org> <46F90841.email@example.com> <20070925133812.GB2333@networkno.de>|
|User-agent:||Thunderbird 188.8.131.52 (Windows/20070326)|
Good to know the library:) I am not very familiar with the ABI details so the code is more or less only a hack to get the most part work.Hmm, why would anyone need to have asm snippets in a document processing suite? And it looks like the bits are ABI-dependent, so at least three variations (if the changes are endianness-safe) would be required to handle all the ABIs that we support.Openoffice wants to be able to interact with plugins written in many languages, instead of writting a module for each possible combination it chooses the so called bridge: every language interact with a common middle language.So we have now foreign function interfaces for at least OpenOffice, Mozilla, Clisp and GCC's libffi. libffi recently got support for N32/N64 ABIs, and is the only solution which isn't bound to a specific application (as long as GCC is used).Using libffi from Openoffice looks like the best long-term approach to me.
Maybe the occasional crashes of our OOo are related to the bugs.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [PATCH 1/4][MIPS] Add support for BCM47XX CPUs., Ralf Baechle|
|Next by Date:||Re: [PATCH 0/4] Rename BCM947XX into BCM47XX, Maciej W. Rozycki|
|Previous by Thread:||Re: About openoffice linux/mips porting, Thiemo Seufer|
|Next by Thread:||Re: About openoffice linux/mips porting, David Daney|
|Indexes:||[Date] [Thread] [Top] [All Lists]|