[ft-devel] integer suffix abuse
Hi All, I think we abuse the suffix L in integer constants. I understand the desire to make sure that very common 0x1L is 32-bit to represent a unit in 16.16 fixed-point representation. On modern 64-bit systems that actually becomes an unnecessary 64-bit constant. Perhaps the suffix was used with 16-bit systems in mind, but 0x1 cannot fit into 16-bit integer and will always be 32-bit even on 16-bit systems. Am I missing something? Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] integer suffix abuse
Hmm, therefore, should we remove all constants using L suffix directly, and use such constants as the macros which is defined with appropriate suffix under the cpp-conditionals for 16-bit, 32-bit and 64-bit systems? Regards, mpsuzuki Alexei Podtelezhnikov wrote: Hi All, I think we abuse the suffix L in integer constants. I understand the desire to make sure that very common 0x1L is 32-bit to represent a unit in 16.16 fixed-point representation. On modern 64-bit systems that actually becomes an unnecessary 64-bit constant. Perhaps the suffix was used with 16-bit systems in mind, but 0x1 cannot fit into 16-bit integer and will always be 32-bit even on 16-bit systems. Am I missing something? Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] integer suffix abuse
I very much doubt this does any harm; modern compilers will do the right thing. It won't do any harm to get rid of the L suffixes, but it is unlikely to make any difference at all to compiled size or performance on any platforms that matter. Best regards, Graham On 24/06/2015 17:24, suzuki toshiya wrote: Hmm, therefore, should we remove all constants using L suffix directly, and use such constants as the macros which is defined with appropriate suffix under the cpp-conditionals for 16-bit, 32-bit and 64-bit systems? Regards, mpsuzuki Alexei Podtelezhnikov wrote: Hi All, I think we abuse the suffix L in integer constants. I understand the desire to make sure that very common 0x1L is 32-bit to represent a unit in 16.16 fixed-point representation. On modern 64-bit systems that actually becomes an unnecessary 64-bit constant. Perhaps the suffix was used with 16-bit systems in mind, but 0x1 cannot fit into 16-bit integer and will always be 32-bit even on 16-bit systems. Am I missing something? Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] integer suffix abuse
On Wed, Jun 24, 2015 at 1:12 PM, Tom Bishop, Wenlin Institute wen...@wenlin.com wrote: I would have guessed that with a 64-bit compiler the resulting executable code would be the same with or without L. (The definitions of types like FT_Fixed and FT_Long would make more difference.) Surprisingly, changing all 0x1L to 0x1 in FreetypeAmalgam.c really does produce a few different assembly language instructions (using Xcode). (See below for the diff.) That is reassuring. 64-bit gcc produces exact same code with and without L in large numbers. Can you regenerate unified diff (-u) so that we can see line numbers? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] integer suffix abuse
On Jun 24, 2015, at 11:52 AM, Alexei Podtelezhnikov apodt...@gmail.com wrote: Hi All, I think we abuse the suffix L in integer constants. I understand the desire to make sure that very common 0x1L is 32-bit to represent a unit in 16.16 fixed-point representation. On modern 64-bit systems that actually becomes an unnecessary 64-bit constant. Perhaps the suffix was used with 16-bit systems in mind, but 0x1 cannot fit into 16-bit integer and will always be 32-bit even on 16-bit systems. Am I missing something? Is your main concern that the executable code might be larger/slower than necessary, or that the source code is unnecessarily enlarged/cluttered by L suffixes? I would have guessed that with a 64-bit compiler the resulting executable code would be the same with or without L. (The definitions of types like FT_Fixed and FT_Long would make more difference.) Surprisingly, changing all 0x1L to 0x1 in FreetypeAmalgam.c really does produce a few different assembly language instructions (using Xcode). (See below for the diff.) Best wishes, Tom diff test_L.u8 test_no_L.u8 2c2 # Generated at 12:13:05 PM on Wednesday, June 24, 2015 --- # Generated at 12:30:21 PM on Wednesday, June 24, 2015 39068,39070c39068 movl%eax, %ecx movl$65536, %eax## imm = 0x1 movl%eax, %edx --- movl$65536, %ecx## imm = 0x1 39073,39075c39071,39074 cmovneq %rdx, %rcx movq-144(%rbp), %rdx movq%rcx, (%rdx) --- cmovnel %ecx, %eax movslq %eax, %rdx movq-144(%rbp), %rsi movq%rdx, (%rsi) 39077,39079c39076,39078 movq-144(%rbp), %rcx addq$8, %rcx movq%rcx, -144(%rbp) --- movq-144(%rbp), %rdx addq$8, %rdx movq%rdx, -144(%rbp) 39109,39111c39108 movl%eax, %ecx movl$65536, %eax## imm = 0x1 movl%eax, %edx --- movl$65536, %ecx## imm = 0x1 39114,39116c39111,39114 cmovneq %rdx, %rcx movq-144(%rbp), %rdx movq%rcx, (%rdx) --- cmovnel %ecx, %eax movslq %eax, %rdx movq-144(%rbp), %rsi movq%rdx, (%rsi) 39118,39120c39116,39118 movq-144(%rbp), %rcx addq$8, %rcx movq%rcx, -144(%rbp) --- movq-144(%rbp), %rdx addq$8, %rdx movq%rdx, -144(%rbp) 39142,39144c39140 movl%eax, %ecx movl$65536, %eax## imm = 0x1 movl%eax, %edx --- movl$65536, %ecx## imm = 0x1 39147,39149c39143,39146 cmovneq %rdx, %rcx movq-144(%rbp), %rdx movq%rcx, (%rdx) --- cmovnel %ecx, %eax movslq %eax, %rdx movq-144(%rbp), %rsi movq%rdx, (%rsi) 39151,39153c39148,39150 movq-144(%rbp), %rcx addq$8, %rcx movq%rcx, -144(%rbp) --- movq-144(%rbp), %rdx addq$8, %rdx movq%rdx, -144(%rbp) 168324c168321 .loc1 144104 30 ## FreeTypeAmalgam.c:144104:30 --- .loc1 144104 29 ## FreeTypeAmalgam.c:144104:29 202116,202117c202113 movl%ecx, %esi movq$-65536, %rdi ## imm = 0x --- movl$4294901760, %edx ## imm = 0x 202121,202122c202117,202119 cmovlq %rdi, %rsi movq%rsi, -40(%rbp) --- cmovll %edx, %ecx movslq %ecx, %rax movq%rax, -40(%rbp) 240482c240479 .loc1 75753 22 ## FreeTypeAmalgam.c:75753:22 --- .loc1 75753 21 ## FreeTypeAmalgam.c:75753:21 Wenlin Institute, Inc. SPC (a Social Purpose Corporation) 文林研究所社会目的公司 Software for Learning Chinese E-mail: wen...@wenlin.com Web: http://www.wenlin.com Telephone: 1-877-4-WENLIN (1-877-493-6546) ☯ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] integer suffix abuse
On Jun 24, 2015, at 11:52 AM, Alexei Podtelezhnikov apodt...@gmail.com wrote: Hi All, I think we abuse the suffix L in integer constants. I understand the desire to make sure that very common 0x1L is 32-bit to represent a unit in 16.16 fixed-point representation. On modern 64-bit systems that actually becomes an unnecessary 64-bit constant. Perhaps the suffix was used with 16-bit systems in mind, but 0x1 cannot fit into 16-bit integer and will always be 32-bit even on 16-bit systems. Am I missing something? Is your main concern that the executable code might be larger/slower than necessary, or that the source code is unnecessarily enlarged/cluttered by L suffixes? I would have guessed that with a 64-bit compiler the resulting executable code would be the same with or without L. (The definitions of types like FT_Fixed and FT_Long would make more difference.) Surprisingly, changing all 0x1L to 0x1 in FreetypeAmalgam.c really does produce a few different assembly language instructions (using Xcode). (See below for the diff.) Best wishes, Tom diff test_L.u8 test_no_L.u8 2c2 # Generated at 12:13:05 PM on Wednesday, June 24, 2015 --- # Generated at 12:30:21 PM on Wednesday, June 24, 2015 39068,39070c39068 movl%eax, %ecx movl$65536, %eax## imm = 0x1 movl%eax, %edx --- movl$65536, %ecx## imm = 0x1 39073,39075c39071,39074 cmovneq %rdx, %rcx movq-144(%rbp), %rdx movq%rcx, (%rdx) --- cmovnel %ecx, %eax movslq %eax, %rdx movq-144(%rbp), %rsi movq%rdx, (%rsi) 39077,39079c39076,39078 movq-144(%rbp), %rcx addq$8, %rcx movq%rcx, -144(%rbp) --- movq-144(%rbp), %rdx addq$8, %rdx movq%rdx, -144(%rbp) 39109,39111c39108 movl%eax, %ecx movl$65536, %eax## imm = 0x1 movl%eax, %edx --- movl$65536, %ecx## imm = 0x1 39114,39116c39111,39114 cmovneq %rdx, %rcx movq-144(%rbp), %rdx movq%rcx, (%rdx) --- cmovnel %ecx, %eax movslq %eax, %rdx movq-144(%rbp), %rsi movq%rdx, (%rsi) 39118,39120c39116,39118 movq-144(%rbp), %rcx addq$8, %rcx movq%rcx, -144(%rbp) --- movq-144(%rbp), %rdx addq$8, %rdx movq%rdx, -144(%rbp) 39142,39144c39140 movl%eax, %ecx movl$65536, %eax## imm = 0x1 movl%eax, %edx --- movl$65536, %ecx## imm = 0x1 39147,39149c39143,39146 cmovneq %rdx, %rcx movq-144(%rbp), %rdx movq%rcx, (%rdx) --- cmovnel %ecx, %eax movslq %eax, %rdx movq-144(%rbp), %rsi movq%rdx, (%rsi) 39151,39153c39148,39150 movq-144(%rbp), %rcx addq$8, %rcx movq%rcx, -144(%rbp) --- movq-144(%rbp), %rdx addq$8, %rdx movq%rdx, -144(%rbp) 168324c168321 .loc1 144104 30 ## FreeTypeAmalgam.c:144104:30 --- .loc1 144104 29 ## FreeTypeAmalgam.c:144104:29 202116,202117c202113 movl%ecx, %esi movq$-65536, %rdi ## imm = 0x --- movl$4294901760, %edx ## imm = 0x 202121,202122c202117,202119 cmovlq %rdi, %rsi movq%rsi, -40(%rbp) --- cmovll %edx, %ecx movslq %ecx, %rax movq%rax, -40(%rbp) 240482c240479 .loc1 75753 22 ## FreeTypeAmalgam.c:75753:22 --- .loc1 75753 21 ## FreeTypeAmalgam.c:75753:21 Wenlin Institute, Inc. SPC (a Social Purpose Corporation) 文林研究所社会目的公司 Software for Learning Chinese E-mail: wen...@wenlin.com Web: http://www.wenlin.com Telephone: 1-877-4-WENLIN (1-877-493-6546) ☯ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] integer suffix abuse
I think we abuse the suffix L in integer constants. I understand the desire to make sure that very common 0x1L is 32-bit to represent a unit in 16.16 fixed-point representation. On modern 64-bit systems that actually becomes an unnecessary 64-bit constant. Perhaps the suffix was used with 16-bit systems in mind, but 0x1 cannot fit into 16-bit integer and will always be 32-bit even on 16-bit systems. As far as I know, the `L' suffix simply gives an `at least' size of 32bit. It does *not* enforce a 64bit value. To do this, you need the `LL' suffix. Consequently, having `L' is harmless on 32bit and 64bit compilers, and essential on 16bit compilers (you get warnings without it). Admittedly, the latter is virtually extinct, and no-one is testing FreeType compilation with such a compiler anymore, but please have in mind that some parts of the TrueType specification actively use 16bit integer overflow. Similarly, FreeType uses `short int' here and there, and IMHO it makes sense to have `L' for such situations. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] integer suffix abuse
On Jun 24, 2015, at 2:36 PM, Alexei Podtelezhnikov apodt...@gmail.com wrote: On Wed, Jun 24, 2015 at 1:12 PM, Tom Bishop, Wenlin Institute wen...@wenlin.com wrote: I would have guessed that with a 64-bit compiler the resulting executable code would be the same with or without L. (The definitions of types like FT_Fixed and FT_Long would make more difference.) Surprisingly, changing all 0x1L to 0x1 in FreetypeAmalgam.c really does produce a few different assembly language instructions (using Xcode). (See below for the diff.) That is reassuring. 64-bit gcc produces exact same code with and without L in large numbers. Can you regenerate unified diff (-u) so that we can see line numbers? Here it is (I hope!). -Tom diff -u test_L.u8 test_no_L.u8 --- test_L.u8 2015-06-24 12:31:44.0 -0400 +++ test_no_L.u82015-06-24 12:31:32.0 -0400 @@ -1,5 +1,5 @@ # Assembly output for FreeTypeAmalgam.c -# Generated at 12:13:05 PM on Wednesday, June 24, 2015 +# Generated at 12:30:21 PM on Wednesday, June 24, 2015 # Using Debug configuration, x86_64 architecture for Wenlin target of Wenlin project .section__TEXT,__text,regular,pure_instructions @@ -39065,18 +39065,17 @@ Ltmp3912: LBB176_452: ## in Loop: Header=BB176_5 Depth=1 xorl%eax, %eax - movl%eax, %ecx - movl$65536, %eax## imm = 0x1 - movl%eax, %edx + movl$65536, %ecx## imm = 0x1 .loc1 50377 4 ## /Users/tbishop/wenlin/freetype_amalg/FreeTypeAmalgam.c:50377:4 cmpq$0, -400(%rbp) - cmovneq %rdx, %rcx - movq-144(%rbp), %rdx - movq%rcx, (%rdx) + cmovnel %ecx, %eax + movslq %eax, %rdx + movq-144(%rbp), %rsi + movq%rdx, (%rsi) .loc1 50378 4 ## /Users/tbishop/wenlin/freetype_amalg/FreeTypeAmalgam.c:50378:4 - movq-144(%rbp), %rcx - addq$8, %rcx - movq%rcx, -144(%rbp) + movq-144(%rbp), %rdx + addq$8, %rdx + movq%rdx, -144(%rbp) Ltmp3913: .loc1 50380 5 ## /Users/tbishop/wenlin/freetype_amalg/FreeTypeAmalgam.c:50380:5 jmp LBB176_515 @@ -39106,18 +39105,17 @@ Ltmp3916: LBB176_457: ## in Loop: Header=BB176_5 Depth=1 xorl%eax, %eax - movl%eax, %ecx - movl$65536, %eax## imm = 0x1 - movl%eax, %edx + movl$65536, %ecx## imm = 0x1 .loc1 50388 4 ## /Users/tbishop/wenlin/freetype_amalg/FreeTypeAmalgam.c:50388:4 cmpq$0, -408(%rbp) - cmovneq %rdx, %rcx - movq-144(%rbp), %rdx - movq%rcx, (%rdx) + cmovnel %ecx, %eax + movslq %eax, %rdx + movq-144(%rbp), %rsi + movq%rdx, (%rsi) .loc1 50389 4 ## /Users/tbishop/wenlin/freetype_amalg/FreeTypeAmalgam.c:50389:4 - movq-144(%rbp), %rcx - addq$8, %rcx - movq%rcx, -144(%rbp) + movq-144(%rbp), %rdx + addq$8, %rdx + movq%rdx, -144(%rbp) Ltmp3917: .loc1 50391 5 ## /Users/tbishop/wenlin/freetype_amalg/FreeTypeAmalgam.c:50391:5 jmp LBB176_515 @@ -39139,18 +39137,17 @@ Ltmp3920: LBB176_460: ## in Loop: Header=BB176_5 Depth=1 xorl%eax, %eax - movl%eax, %ecx - movl$65536, %eax## imm = 0x1 - movl%eax, %edx + movl$65536, %ecx## imm = 0x1 .loc1 50399 4 ## /Users/tbishop/wenlin/freetype_amalg/FreeTypeAmalgam.c:50399:4 cmpq$0, -416(%rbp) - cmovneq %rdx, %rcx - movq-144(%rbp), %rdx - movq%rcx, (%rdx) + cmovnel %ecx, %eax + movslq %eax, %rdx + movq-144(%rbp), %rsi + movq%rdx, (%rsi) .loc1 50400 4 ## /Users/tbishop/wenlin/freetype_amalg/FreeTypeAmalgam.c:50400:4 - movq-144(%rbp), %rcx - addq$8, %rcx - movq%rcx, -144(%rbp) + movq-144(%rbp), %rdx + addq$8, %rdx + movq%rdx, -144(%rbp) Ltmp3921: .loc1 50402 5 ## /Users/tbishop/wenlin/freetype_amalg/FreeTypeAmalgam.c:50402:5 jmp LBB176_515 @@ -168321,7 +168318,7 @@ cmpq$65536, -64(%rbp) ## imm = 0x1 jle LBB1002_10 ## BB#9:## in Loop: Header=BB1002_5 Depth=2 - .loc1 144104 30 ## /Users/tbishop/wenlin/freetype_amalg/FreeTypeAmalgam.c:144104:30 + .loc1 144104 29 ## /Users/tbishop/wenlin/freetype_amalg/FreeTypeAmalgam.c:144104:29 movq$65536, -64(%rbp) ## imm = 0x1 Ltmp17140: LBB1002_10: ##
Re: [ft-devel] integer suffix abuse
On Jun 24, 2015, at 4:00 PM, Alexei Podtelezhnikov apodt...@gmail.com wrote:
Here it is (I hope!). -Tom
Alright, your version of FreeTypeAmalgam.c is not this one:
https://github.com/vinniefalco/FreeTypeAmalgam
It looks like only two pieces of code affected:
about 30 lines here from FreeTypeAmalgam.c:50372 to /FreeTypeAmalgam.c:50402
and
and around line FreeTypeAmalgam.c:144809
Can you look up what it corresponds to in the real code? Thanks!
Yes, here's 50372 thru 50402:
{
FT_Fixed cond = args[0] args[1];
FT_TRACE4(( and\n ));
args[0] = cond ? 0x1L : 0;
args++;
}
break;
case cff_op_or:
{
FT_Fixed cond = args[0] || args[1];
FT_TRACE4(( or\n ));
args[0] = cond ? 0x1L : 0;
args++;
}
break;
case cff_op_eq:
{
FT_Fixed cond = !args[0];
FT_TRACE4(( eq\n ));
args[0] = cond ? 0x1L : 0;
args++;
}
break;
And here's 144801 thru 144810:
/* we need to scale the values by 1.0/temp_scale */
if ( temp_scale != 0x1L )
{
temp[0] = FT_DivFix( temp[0], temp_scale );
temp[1] = FT_DivFix( temp[1], temp_scale );
temp[2] = FT_DivFix( temp[2], temp_scale );
temp[4] = FT_DivFix( temp[4], temp_scale );
temp[5] = FT_DivFix( temp[5], temp_scale );
temp[3] = temp[3] 0 ? -0x1L : 0x1L;
}
Tom
Wenlin Institute, Inc. SPC (a Social Purpose Corporation)
文林研究所社会目的公司
Software for Learning Chinese
E-mail: wen...@wenlin.com Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
