MIPS h asm constraint in GCC 4.4, and TI-mode 128 bit types

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I noted this change in the GCC 4.4 notes:

"""
The MIPS port no longer recognizes the h asm constraint. It was
necessary to remove this constraint in order to avoid generating
unpredictable code sequences.

One of the main uses of the h constraint was to extract the high part
of a multiplication on 64-bit targets. For example:

    asm ("dmultu\t%1,%2" : "=h" (result) : "r" (x), "r" (y));

You can now achieve the same effect using 128-bit types:

    typedef unsigned int uint128_t __attribute__((mode(TI)));
    result = ((uint128_t) x * y) >> 64;
"""

I am currently using exactly the sort of asm construct given in the
note to access dmultu.

Can anyone tell me at what point was this mode(TI) business supported,
and on which platforms? It seems to be accepted by GCC 4.3.3 on
x86-64. But I cannot seem to find much about it in the info pages for
that version - it seems analogous to the TC and XC modes mentioned in
5.10 Additional Floating Types, and TI mode is mentioned in
conjunction with full-vector SSE2 access, but that doesn't tell me
much (firstly since SSE2 doesn't have a 64x64->128 multiply
instruction, and of course since MIPS does not have SSE2 anyway).

If this works consistently across platforms that would be
exceptionally useful for me, as currently I use inline asm to access
the native 64-bit multiply on various platforms (x86-64 mulq, IA-64
xmpy.hu, PPC mulhdu, Alpha umulh, MIPS dmultu), and if all can be
consolidated using this TI construct that certainly makes my life
simpler.

Thanks,
  Jack

[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux