Re: [ft-devel] manual pages for freetype2-demos
Werner LEMBERG w...@gnu.org writes: I'm not too happy that distributions like Debian publish all of the FreeType demo programs (for example, `ftgamma' has essentially no real use); maybe this can be improved somehow. Why? As a Debian user, I'm often glad that the FT demo progs are there, because they can be useful. Maybe ftgamma isn't so useful, but if it's not actively _harmful_, why go to the bother of making an exception? Users can just ... not run it. Thanks, -Miles -- Custard, n. A vile concoction produced by a malevolent conspiracy of the hen, the cow, and the cook. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] using pkg-config
2013/9/17 Behdad Esfahbod beh...@behdad.org: It also used to the case that pkg-config didn't handle cross-compilation properly (I haven't checked this in a while), which seems like it would be an issue for freetype. Works just fine for cross-compiling. I do that every day. It does? How does it work? At least with standard autoconf practices, pkg-config doesn't even seem to notice if you're cross-compiling, and just gives info for the cross-compilation host, which is usually incorrect... This isn't entirely surprising, as pkg-config doesn't use the compiler like most autoconf tests, and so won't automatically reflect changes in the toolchain used. The pkg-config autoconf macros could conceivably detect this situation (and do... what, I don't know, but they could at least disable pkg-config), but don't appear to even try. E.g. if you use the following basic configure.ac file: AC_INIT([t1], [0.0], [Miles Bader mi...@gnu.org]) AC_CONFIG_HEADERS([config.h]) AC_PROG_CC PKG_PROG_PKG_CONFIG have_libpng=no PKG_CHECK_MODULES([libpng], [libpng], [have_libpng=yes], [:]) if test $have_libpng = yes; then AC_DEFINE([HAVE_LIBPNG], [1], [Define if libpng is installed]) fi AC_CONFIG_FILES([Makefile]) AC_OUTPUT and then try to cross-compile with it: ./configure --host=x86_64-w64-mingw32 ... then the wrong thing will happen, and the build will fail. By contrast, a traditional library check using AC_CHECK_LIB will behave as expected. So at the least, it looks like some sort of special care is needed either on the part of the configure script or on the part of the user, to deal with pkg-config during cross-compilation. Thanks, -miles -- Cat is power. Cat is peace. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] using pkg-config
Werner LEMBERG w...@gnu.org writes: Does it make sense to completely switch to pkg-config? All of the above libraries provide .pc files. However, I wonder whether there are situations where there usage of pkg-config is problematic. A certain burden is that pkg-config itself must be installed (or pkgconf, which does the same in a probably better way). Is this a hassle on some platforms? My impression is that although on mainstream linux distros it's a pretty good bet pkg-config is available, it's far from universal if you care about the fringes -- and freetype looks very much like the sort of library that tends to care more about the fringes than usual. It also used to the case that pkg-config didn't handle cross-compilation properly (I haven't checked this in a while), which seems like it would be an issue for freetype. It's not very hard to try both in turn, e.g.: have_libfoo=no PKG_CHECK_MODULES([luafoo], [luafoo], [have_luafoo=yes], [:]) if test $have_libfoo = no; then AC_CHECK_LIB([foo], [somefun], [have_luafoo=yes]) fi if test $have_libfoo = yes; then ...do stuff for libfoo... fi Should fallback gracefully to traditional checking if pkg-config isn't installed.. [When libraries are installed in funny places it can be a little more annoying without pkg-config, but AFAIK, libpng usually isn't one of those libraries...] -miles -- Innards, n. pl. The stomach, heart, soul, and other bowels. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype-devel post from john...@tiscali.co.uk requires approval
Werner LEMBERG w...@gnu.org writes:
After a bit more consideration I suspect it's simply the '0' in
while (0) that's causing all the warnings.
Is this really true? Can you check that explicitly? The `do{...}
while(0)' construction is extremely useful and so common that it
would make the MSVC warning completely useless.
Indeed so common that it can be called idiomatic in this usage (and
has been as long as I can remember).
Given it's idiomatic nature, it's pretty surprising that any widely
used compiler warns about it, even at maximum warning settings
-miles
--
Somebody has to do something, and it's just incredibly pathetic that it
has to be us. -- Jerry Garcia
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Get_PS_Font_Private in CFF driver
Werner LEMBERG w...@gnu.org writes: Behdad Esfahbod (on behalf of Google) contributed support for color embedded bitmaps (eg. color emoji). https://color-emoji.googlecode.com/git/specification/v1.html Only bitmaps? The blog entry doesn't mention any limitation to embedded bitmaps, and I was thinking that meant full vector fonts, only with color layers... [Hopefully this will increase the breadth of emoji support out there, with some real designers giving it a go, and we won't have to put up with the painfully twee emoji on many platforms (e.g., the horrible ipad/iphone emoji... ugh..urg..urgh)] Thanks, -miles -- Politeness, n. The most acceptable hypocrisy. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
Werner LEMBERG w...@gnu.org writes: What are the void* pointers typically expected to point to...? Property data structures. As I suppose these void* values are often pointers to some malloced memory in many cases, how is it expected that resource management of that memory is done...? I.e., when the a list gets destroyed because a FT library is destroyed, who's responsible for cleaning up the pointed-to property data? FreeType. If there is ever a need to pass a new string to the library (for which I currently don't have a use case), the data will be copied. Wait how does that work? That suggests that freetype will copy any structure passed in into malloced memory or something; otherwise, one couldn't pass in any dynamically calculated values. But since (AFAICT) the property mechanism is generic, the type of the data structure wouldn't be known except to the eventual caller of FT_Property_Get. Given this, how can FT_Property_Set know the size of the data structure passed in, to malloc/copy it? Thanks, -miles -- Love is the difficult realization that something other than oneself is real. [Iris Murdoch] ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
2012/8/22 Werner LEMBERG w...@gnu.org: But since (AFAICT) the property mechanism is generic, the type of the data structure wouldn't be known except to the eventual caller of FT_Property_Get. Given this, how can FT_Property_Set know the size of the data structure passed in, to malloc/copy it? The property mechanism has a generic interface to accept any data structures so that it stays extensible, but the data structures themselves aren't generic; they are always controlled by FreeType. Sure. I'm just confused how FT_Property_Set figures out the length, presuming it's FT_Property_Set that does the copying (I'm guessing it would have to be, as the caller of FT_Property_Set is outside of freetype, and the actual point of use of the data structure, which obviously would know the type, is too late). Thanks, -miles -- Cat is power. Cat is peace. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] controlling FreeType modules
What are the void* pointers typically expected to point to...? As I suppose these void* values are often pointers to some malloced memory in many cases, how is it expected that resource management of that memory is done...? I.e., when the a list gets destroyed because a FT library is destroyed, who's responsible for cleaning up the pointed-to property data? property tends to bring to mind simple things like numeric or string settings. Strings could I suppose passed directly; how about numbers? -Miles -- 97% of everything is grunge ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] optimal configuration to render fonts using gamma correction
Francesco Abbate francesco@gmail.com writes: So the problem is still standing about why fonts looks washed with gamma correction. More important too, what is the better method to render fonts ? Disable gamma corrections ? What do you mean by washed out? _What's_ washed out? Regardless of what curve your grey-levels use, white should be white, and black should be black, and fonts are mostly black and white [I guess you want to do any blending in a linear space (non-gamma-corrected), but obviously whatever you hand off to the display system should be in whatever space the display system expects...] -miles -- We are all lying in the gutter, but some of us are looking at the stars. -Oscar Wilde ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] optimal configuration to render fonts using gamma correction
I wrote earlier: [I guess you want to do any blending in a linear space ^ and interpolation too, of course! (non-gamma-corrected), but obviously whatever you hand off to the display system should be in whatever space the display system expects...] -- Apologize, v. To lay the foundation for a future offense. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] display broken
Alexei Podtelezhnikov apodt...@gmail.com writes: Well, I've read that that Apple is going to sell iBooks with `retina displays' soon, with really impressive DPI values, and I suspect that other companies will provide similar things, which is good! Let me steer this discussion away from commerce and back to freetype. With DPI = 326 on IPhone 4S and DPI = 264 on IPad, would you agree that hinting and subpixel rendering becomes less critical, whereas the speed of the rasterizer needs to be revisited? I'm not sure what less critical means... Freetype obviously still has to do good hinting and subpixel rendering, even on a high res display. [My cellphone has about the same display resolution as an iphone 4 (about 310 DPI), and although this makes large characters look really smooth, they also took advantage of the resolution by using _really freaking small_ characters in some situations, and really freaking small CJK characters still need decent hinting or whatever even at these resolutions...] -Miles -- We are all lying in the gutter, but some of us are looking at the stars. -Oscar Wilde ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Aftermath.
suzuki toshiya mpsuz...@hiroshima-u.ac.jp writes: Anyway, such discussion is out of the scope of the people saying i don't get why I feel as some people asking for a bread (or fermented paste) in the miller's market. Anyway, I'm sure all the relevant arguments were well-covered in the _previous_ flamewar on this topic... -miles -- Acquaintance, n. A person whom we know well enough to borrow from, but not well enough to lend to. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] trying to install
Werner LEMBERG w...@gnu.org writes: /bin/sh: ./configure: Permission denied Looks like incorrect file permissions. The file `builds/unix/configure' must be executable. Try chmod 755 builds/unix/configure Another way is to just invoke the configure file as a shell script, e.g.: sh ./configure -miles -- Defenceless, adj. Unable to attack. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType licenses again
Werner LEMBERG w...@gnu.org writes: I strongly dislike that. I don't consider a font which has been processed with FreeType (or ttfautohint) a `redistribution in binary form'. The FTL has never been meant to apply on such cases. Additionally, I want to make the bytecode created by ttfautohint freely available. Hmm isn't this exactly the same as with any other compiler? Obviously gcc, for instance, very intentionally does not add any licensing restrictions to object files it outputs; how does it handle the issue in its license? I know there's the GCC Runtime Library Exception to handle the (more straight-forward) case of the runtime library; is the issue explicitly addressed anywhere? -Miles -- `To alcohol! The cause of, and solution to, all of life's problems' --Homer J. Simpson ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType licenses again
hmm http://www.gnu.org/licenses/gcc-exception-faq.html -- Quack, n. A murderer without a license. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint 0.6 has been released
Werner LEMBERG w...@gnu.org writes: Today in the morning, while still dozing, I had a great idea how to largely simplify hinting of composite glyphs, and which solves the Roboto issue at the same time. Heh, you have your best coding ideas while half-asleep too eh...? :} -miles -- Monday, n. In Christian countries, the day after the baseball game. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] .gitignore in release tarballs
Marek Kasik mka...@redhat.com writes: our building system warned me that there are .gitignore files distributed in release tarballs of freetype. Could you remove them in upcoming releases? Why should .gitignore files be removed from release tarballs? They're part of the source code. A build system that warns about them would seem to be broken. -Miles -- Next to fried food, the South has suffered most from oratory. -- Walter Hines Page ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Registration of a set of trickyfonts by NEC
suzuki toshiya mpsuz...@hiroshima-u.ac.jp writes: BTW, during the production of sample PDF, I found that OpenOffice.org generates wrong checksum for embedded TTF, so the tricky font detection by the checksum cannot solve the problem :-( Could you compare against _both_ the real checksum and the bogus OpenOffice.org checksum, and recognize both? [Maybe just add separate entries for the bogus OpenOffice.org version of these fonts...] -Miles -- The automobile has not merely taken over the street, it has dissolved the living tissue of the city. Its appetite for space is absolutely insatiable; moving and parked, it devours urban land, leaving the buildings as mere islands of habitable space in a sea of dangerous and ugly traffic. [James Marston Fitch, New York Times, 1 May 1960] ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] a hidden gem: the autohint warper code
Werner LEMBERG w...@gnu.org writes: What is improvable, however, is the algorithm to decide which stems are `main features', and which features (e.g. serifs) must be handled specially. In particular, handling of diagonal stems might be improved. BTW, that's what sort of worried me about the recent hacks to the CJK autohinter: It seemed to work OK in the case posted, because the major skeleton strokes of the characters were grid-aligned, and the non-aligned (and thus less visible) strokes seemed well-chosen. But is that somehow guaranteed...? It seems like the result not aligning important strokes when minor strokes _were_ aligned would result in _less_ readable results than simply grid-aligning everything (as I guess happens now)... -Miles -- [|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that will make every christian in the world foamm at the mouth? [iddt] nurg, that's the goal ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] a hidden gem: the autohint warper code
Werner LEMBERG w...@gnu.org writes: Below you can find two links to images (from David Turner, who is testing and evaluating the warping stuff again). Please compare. http://img848.imageshack.us/img848/9311/wikigitwarpoff.png http://img852.imageshack.us/img852/3342/wikigitwarpon.png Interestingly, David thinks that the autohinter warping produces much worse results, while I consider exactly the opposite... Hmm Interestingly, it's not the shapes I notice so much, but that the _spacing_ in the hinting = on image looks vastly better. The spacing in the off image is downright awful. Not sure why this is so, but I'm guessing that the off image is using up extra columns of pixels for almost-unnoticeable fringes at the sides of characters, and the result is that there appears to be extra colums of whitespace inserted at those points... -Miles -- Scriptures, n. The sacred books of our holy religion, as distinguished from the false and profane writings on which all other faiths are based. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] out-dated text on freetype developer page
The developer page on the freetype website says this: If you are behind a Firewall which disables port 9418, you might try the slower HTTP protocol: git clone http://git.sv.nongnu.org/r/freetype/freetype2.git git clone http://git.sv.nongnu.org/r/freetype/freetype2-demos.git; [ http://www.freetype.org/developer.html#anongit ] ... however, I don't think it's true anymore that using http: is slower -- savannah now supports the git smart http protocol (which I guess just channels the ordinary git-protocol over an http channel), which is basically the same speed as git:. So I'd recommend removing the word slower from that description. Thanks, -Miles -- A zen-buddhist walked into a pizza shop and said, Make me one with everything. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
JustFillBug mozbug...@yahoo.com.au writes: At 11pt, the bottom of the last few chars will clearly show the effect. I attached an pic with anti-alias off. anti-aliased version also shows the effect. The with blue and no blue renderings are surely different, in terms of vertical alignment at the bottom, but it's not clear to me which is actually _best_... the no blue rendering looks more even though. What are the rules about vertical alignment with CJK fonts? [Especially at low resolutions, where many characters end up having wide flat bottoms even if they're not flat at high resolutions.] In particular, these two characters: 置者 look a bit unbalanced in the with blue rendering, but look nicer to me in the no blue rendering because at least their flat bottoms are aligned. Thanks, -miles -- Barometer, n. An ingenious instrument which indicates what kind of weather we are having. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: About Gsub table in opentype.
Behdad Esfahbod beh...@behdad.org writes: Interesting. I had totally forgotten about libotf. I hope now that new harfbuzz is in a usable state Kenichi abandons the libotf and helps with harfbuzz. Do they do the same thing? From the description it sounds like libotf is much smaller and more focused, and might be more appropriate for someone that only wants to get file info (which seems to have been the case for the original poster on this thread). Maybe you're thinking of libm17n; that looks closer to harfbuzz in functionality. [BTW, is harfbuzz actually used anywhere yet? I can't seem to find it in Debian...] -Miles -- Barometer, n. An ingenious instrument which indicates what kind of weather we are having. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_MulFix assembly
James Cloos cl...@jhcloos.com writes:
The C version does away-from-zero rounding.
MB Do you have test cases that show this? I tried using random inputs,
MB but even up to billions of iterations, I can't seem to find a set of
MB inputs where my function yields different results from yours.
The C version saves the two signs, takes the absolute values,
multiplies, scales and then sets the sign.
When I tested, I used dd(1) to generate a quarter-gig file from urandom
(I used a fixed file so that it would be reproducable), mmap(2)ed that
to an int[], and went through two at a time. The C and my initial asm
versions produced different results whenever the second int was -1 (ie
0x) and the first matched: (a 0 (a 0x == 0x8000)).
In other words, multiplying something like 7.5 by -1/65536.
An example of that test's output was:
7AFA8000, , 8505, 8506, 0
In that example, 8505 is what the C version generates.
Hm, are you sure that's not backwards? When I tried the git C version[*],
as well as your most recent FT_MulFix_x86_64, it returned 0x8506...
The following C version:
typedef signed int FT_Int;
typedef signed long FT_Long;
typedef signed long FT_Int64; /* on x86-64 */
FT_Long
FT_MulFix_C_new( FT_Long a,
FT_Long b )
{
return (((FT_Int64)a * (FT_Int64)b) + 0x8000) 16;
}
... generates this code:
imulq %rsi, %rdi
leaq32768(%rdi), %rax
sarq$16, %rax
It seems to yield exactly the same results as the offical C version[*],
both for your test case:
$ ./t 0x7AFA8000 0x
0x7afa8000 x 0x =
C: 0x7fff8506
C_new: 0x7fff8506
asm: 0x7fff8506
... and also for billions of random inputs.
Is there something I'm missing...?
[*] Fetched from:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/base/ftcalc.c
Thanks,
-Miles
--
Liberty, n. One of imagination's most precious possessions.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_MulFix assembly
James Cloos cl...@jhcloos.com writes:
Since FT's C version uses longs, though, this:
int another (long a, long b) {
long r = (long)a * (long)b;
long s = r 31;
return (r + s + 0x8000) 16;
}
That's not correct though, is it? The variable s should be the all
sign portion of the multiplication, but since the two inputs have 32
significant bits (never mind the types), the product will have 64
significant bits. So r 31 won't be all-sign, it'll be a bunch of
... other bits. :)
However, changing the shift to 63:
FT_Long
FT_MulFix_C_new2( FT_Long a,
FT_Long b )
{
FT_Int64 prod = (FT_Int64)a * (FT_Int64)b;
FT_Int64 sign = prod 63;
return ((prod + sign + 0x8000) 16);
}
... does seem to yield correct results:
$ ./t 0x7AFA8000 0x
0x7afa8000 x 0x =
C: 0x8505
C_new: 0x8505
C_nw2: 0x8505
C_ano: 0x8505
asm: 0x8505
C is the old C, C_new was my previous attempt, C_nw2 is the above
FT_MulFix_C_new2 function, C_ano is the another function, and
asm was your final asm version.
[another yields misleadingly correct results in this case, because of
the particular argument values given; in other cases, it gives
incorrect results.]
-miles
--
Discriminate, v.i. To note the particulars in which one person or thing is,
if possible, more objectionable than another.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] freetype.com
phil song phils...@techtrex.com writes: Excuse me ,I don't understand why we need tell the slashdot.org people? It's just a quick way to generate a lot of publicity about monotype's dirty tricks... -Miles -- We are all lying in the gutter, but some of us are looking at the stars. -Oscar Wilde ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_MulFix assembly
James Cloos cl...@jhcloos.com writes:
__asm__ __volatile__ (
movq %1, %%rax\n
imul %2\n
addq %%rdx, %%rax\n
addq $0x8000, %%rax\n
sarq $16, %%rax\n
: =a(result)
: g(a), g(b)
: rdx );
The above code has a latency of 1+5+1+1+1 = 10 clocks on an amdfam10 cpu.
...
Is the amd64 version desired, given how little benefit it has?
If this is being used in a context where it might benefit from more
scheduling, etc, perhaps it would help to let the compiler generate the
non-imul insns (since it's pretty good at those)?
E.g. something like:
static __inline__ long
FT_MulFix_x86_64 (long a, long b)
{
register long mr1, mr2;
__asm__ (imul %3\n : =a (mr1), =d (mr2) : a (a), g (b));
return ((mr1 + mr2) + 0x8000) 16;
}
-miles
--
Omochiroi!
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_MulFix assembly
Incidentally, you wrote:
The assembly generated by the C code is 45 lines and 158 octets long,
contains six conditional jumps, three each of explicit compares and
tests, and still benchmarks are just as fast. Out-of-order processing
wins out over hand-coded asm. :-/
... but when I follow your original suggestion, and just do the following:
typedef long s64;
typedef unsigned int u32;
static __inline__ u32
FT_MulFix_x86_64 (u32 a, u32 b)
{
return (((s64)a * (s64)b) + 0x8000) 16;
}
The compiler generates the following assembly:
mov %esi, %eax
mov %edi, %edi
imulq %rdi, %rax
addq$32768, %rax
shrq$16, %rax
The movs there are obviously a bit silly (compiler bug?), but that
output seems reasonably close to the asm() version, and obviously much
more schedulable since the compiler knows what the insns do...
[I tried it with gcc-4.x for a few different xs, and the results are the
same, and optimization flags don't seem to make much difference either.]
-Miles
--
Scriptures, n. The sacred books of our holy religion, as distinguished from
the false and profane writings on which all other faiths are based.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_MulFix assembly
Miles Bader mi...@gnu.org writes: The compiler generates the following assembly: mov %esi, %eax mov %edi, %edi imulq %rdi, %rax addq$32768, %rax shrq$16, %rax The movs there are obviously a bit silly (compiler bug?), but that output seems reasonably close to the asm() version, and obviously much more schedulable since the compiler knows what the insns do... [...Actually the redundant movs, while they may be a compiler bug, seem to be caused by the way I structured my test program; in a more realistic circumstance I don't see them.] -miles -- Abstainer, n. A weak person who yields to the temptation of denying himself a pleasure. A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_MulFix assembly
On Tue, Sep 7, 2010 at 4:28 AM, James Cloos cl...@jhcloos.com wrote: MB == Miles Bader mi...@gnu.org writes: MB The compiler generates the following assembly: MB mov %esi, %eax MB mov %edi, %edi MB imulq %rdi, %rax MB addq $32768, %rax MB shrq $16, %rax That does not match the C code though; it rounds negative values wrong. The C version does away-from-zero rounding. Do you have test cases that show this? I tried using random inputs, but even up to billions of iterations, I can't seem to find a set of inputs where my function yields different results from yours. Thanks, -Miles -- Cat is power. Cat is peace. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
David Turner [EMAIL PROTECTED] writes: I had correct compilation, without warnings with all the following compilers though: MingW (GCC) Visual C++ 6 Visual C++ 7 Borland C++ 5.5 OpenWatcom C++ (don't remember version) Win32-LCC (don't remember version) I also tried several proprietary compilers at work (including one using the EDG frontend, well known for being highly standard compliant), with the same results -- correct compilation, no warning. I used the most strict warning mode/option I could find with all of them. -Miles -- Is it true that nothing can be known? If so how do we know this? -Woody Allen ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
David Turner [EMAIL PROTECTED] writes: this will generate an error with certain compilers/pre-processors if __LP64__ is not defined. generally speaking #if X is not a portable statement, except if you ensure that the macro is always defined beforehand. Is this true according to the C standard, or a problem with any non-obsolete compilers? [I ask because such usage is widespread, and although gcc has a warning for it, it doesn't get turned on even with -ansi -pedantic -Wall -Wextra, you have to enable it explicitly.] -Miles -- Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] cff_get_name_index crash
Sean McBride [EMAIL PROTECTED] writes: Neither are currently included in glibc (and some effort with google seems to indicate this is likely to stay this way for the foreseeable future) Really? Oh well, that sucks. :) If you're interested in this sort of thing, it's probably a good idea to read up on the _reason_ why the glibc maintainer won't include them. -Miles -- The car has become... an article of dress without which we feel uncertain, unclad, and incomplete. [Marshall McLuhan, Understanding Media, 1964] ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
