Some time ago James Cloos proposed...
I tested a wide array of gcc cross compilers as well as clang/llvm.
In each case the machine code this version produces is as good as
the hand-tuned assembly and uses the trick that adding 0x7FFF when
the product is negative causes the same
On Fri, Oct 3, 2014 at 3:27 PM, Alexei Podtelezhnikov
apodt...@gmail.com wrote:
... this patch:
http://cgit.freedesktop.org/~cloos/freetype2/commit/?id=94dc0c20554f3a3d709711f2c43ac65ab7c68afe
Never mind. Right-shifting negative numbers is implementation defined
(ANSI or C11), so it is not
AP == Alexei Podtelezhnikov apodt...@gmail.com writes:
AP Never mind. Right-shifting negative numbers is implementation defined
AP (ANSI or C11), so it is not portable.
Would replacing the 16 with / 65536L be fully portable?
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP:
I've verified that replacing #undef FT_CONFIG_OPTION_FORCE_INT64
with #define in include/freetype/config/ftoption.h does prevent the
#undef FT_LONG64.
But that shouldn't be needed on LP64 archs.
Perhaps the #if FT_SIZEOF_LONG == 8 case should also #define
FT_CONFIG_OPTION_FORCE_INT64 ?
WL == Werner LEMBERG w...@gnu.org writes:
JC Perhaps the #if FT_SIZEOF_LONG == 8 case should also
JC #define FT_CONFIG_OPTION_FORCE_INT64 ?
WL For the dumb guy I am this sounds reasonable :-)
WL What about `make devel; make' which checks ANSI compliance also?
I'll test that out.
WL If
WL If James confirms your statement, I'm going to replace the code as
WL he has suggested in his patch..
It is identical in effect, and the idea comes from the assembly
versions FT_MulFix_arm and FT_MulFix_i386 which are already there
(builds/unix/ ftconfig.in and again in
WL == Werner LEMBERG w...@gnu.org writes:
WL So you say this code always works with any compiler, right?
Anything which supports a 64bit integer which ft's typedefs understand.
Ie, anything where FT_Int64 is typedef'ed and where FT_LONG64 is #defined.
WL We are reaching an area where I'm
On Wed, Apr 6, 2011 at 12:46 AM, Werner LEMBERG w...@gnu.org wrote:
In most circumstances, I fully agree. However, the new code looks
like voodoo to me
If it was a Freetype-specific core piece to be cherished as a mural,
I'd side with Werner. But is it so special?
If I've understood James
If I've understood James correctly, the new code is actually
compiler dependent but the compilers he tested all produce the same
result.
To me the code looks like a welcome
microoptimization/simplification. The result should be the same
regardless of compiler.
Oh, so it's really me who
WL == Werner LEMBERG w...@gnu.org writes:
WL Oh, so it's really me who is dumb :-)
:-)
WL If James confirms your statement, I'm going to replace the code as
WL he has suggested in his patch..
It is identical in effect, and the idea comes from the assembly versions
FT_MulFix_arm and
Please consider pulling the master branch of:
git://anongit.freedesktop.org/~cloos/freetype2.git
to receive the patch below.
Looks good, thanks! Please redo the patch so that the old code gets
saved within a #if 0 ... #endif clause (to stay as a reference), and
add a comment to the new
WL == Werner LEMBERG w...@gnu.org writes:
WL Looks good, thanks!
WL Please redo the patch so that the old code gets saved within a #if 0
WL ... #endif clause (to stay as a reference),
(having the old code in the repo’s history is not enough? :^)
WL and add a comment to the new code
On 04/05/11 17:04, James Cloos wrote:
WL Looks good, thanks!
WL Please redo the patch so that the old code gets saved within a #if 0
WL ... #endif clause (to stay as a reference),
(having the old code in the repo’s history is not enough? :^)
I agree with James. Disabled code only
WL Please redo the patch so that the old code gets saved within a #if 0
WL ... #endif clause (to stay as a reference),
(having the old code in the repo’s history is not enough? :^)
I agree with James. Disabled code only clutters the code base...
In most circumstances, I fully agree.
Please consider pulling the master branch of:
git://anongit.freedesktop.org/~cloos/freetype2.git
to receive the patch below.
I tested a wide array of gcc cross compilers as well as clang/llvm.
In each case the machine code this version produces is as good as
the hand-tuned assembly and uses the
15 matches
Mail list logo
