[ft-devel] 16bit and LP64 model patch set (3)

[mpsuzuki]

Hi,

On Wed, 4 Feb 2009 19:35:39 +0900
address@hidden wrote:
>I'm sorry for no activity to improve the first patch set
>by Werner's comment, I spent most times to finish this
>second (and next third) patch set.

This is the third (and final) patch set for LP64 platform,
including about 30 fragments. This patch set needs a discussion
about coding style of FT2.

At present, FT2 uses the type FT_Long for the variable
holding 32-bit value (and not required to be exact 32-bit).
In C89 specification, long integer is the only and most
appropriate type for this purpose. Also, some naming
convensions in FT2 respects it - for example, FT_NEXT_LONG()
loads exactly 32-bit from memory buffer, and the result
is casted to long integer (not to FT_Int32).

However, on recent 64-bit platforms, the most popular
architechture would be LP64: integer is 32-bit, long is
64-bit. Therefore, the sources using FT_Long reserves
64-bit storage but use 32-bit only. If we allocate an
array for FT_Long to store 32-bit value in FT2, the half
of allocated memory is useless.

In addition, on LP64 platforms, FT_Int32 != FT_Long.
There are many part where FT_Long variables interplay
with FT_Int32 variables (e.g. FT_UInt32 x = FT_NEXT_LONG( p ) ),
thus "gcc -Wshorten-64-to-32 -arch ppc64 -arch x86_64"
on Mac OS X generates so many warning against shortening
implicit casts.

The easiest idea would be:

        I1) replace internal cast to long in FT_NEXT_LONG()
        by internal cast to FT_Int32. it can reduce the
        shortening implicit cast.

        I2) as far as possible, replace FT_Long/FT_ULong
        by FT_Int32/FT_UInt32.

I guess I1 won't cause serious problems, but I2 is
not good idea. It is possible to asume C99-conforming
ILP64 platform whose short is 16-bit, int/long are
64-bit, int32_t is available, and loading/storing
32-bit values is slower than loading/storing 64-bit
values.

# For example, the earlier DEC Alpha processors could
# access the memory only in the unit of 64-bit, although
# Digital UNIX was LP64 model. If anybody familiar with
# 64-bit MIPS processors, please let me know the unit
# of memory access.

To keep from forcing exact 32-bit types to non-essential 
parts, in this patch set, I used "FT_Fast" type which
was introduced for the most appropriate type to hold at-
least-32-bit value (which corresponds to C99 int_fast32_t). 
Also I introduced the macros which cast the result to
FT_Fast, FT_NEXT_FAST() etc.

However, looking at the patched source, it is very very
ugly. Mixing FT_Int, FT_Long, FT_Int32, FT_Fast is hell,
all FT2 developers won't to maintain such source. I think
the clarification of coding style regarding with 64-bit
platform (which types should be used for each purpose) is
required first, and rewriting the type definitions should
be worked in next.

So, I want to hear the comments and ideas about the issue:
"what is the best coding style to hold 32-bit value, to
leave the optimization room for the developers/compilers?"

Regards,
mpsuzuki

mps_16bit_64bit_set03.tar.bz2
Description: Binary data