Hi,
After a discussion with David, Id like to propose a rework of the Windows target
triples. The current set of Windows triples are somewhat less uniform than
their Linux counterparts. With multiple ABIs and environments on Windows, they
are also slightly awkward. Obviously, certain ones might be nice to keep around
for compatibility (e.g. the mingw triple).
Just to ensure that everyone has the same understanding, the canonical format
for a triple is: arch-vendor-os-environment .
We have the following environment on Windows:
As far as I know, everyone conforms to the MS C ABI.
- There is the MS C++ ABI which is still being developed.
- There is the IA-64 ABI which is incompatible with msvcprt.
- There is the MinGW sub environment which supplies additional UNIX-y functions
and uses IA-64 ABI for C++.
The Windows environment is uniformly (COFF)/PE.
As for the OS, Windows is slightly generic. Windows 9x, Windows NT, and Windows
CE are all slightly different. However, given that Microsoft has taken a
unifying strategy with Windows NT, I *think* sticking to Windows for the OS
should be okay. That said, I could be convinced to use winnt or windowsnt.
So, one way to clearly define a naming scheme for this space would be something
along the lines of:
{armv7,i686,x86_64}-windows-{ia,mingw,ms}pe
This allows us to uniformly take any of the combination IA-64 or MS C++ ABI + MS
C ABI or the MinGW environment (which is IA-64 ABI and its supplementary
libraries).
I understand that this may be controversial since it can potentially break
existing code bases, but I think that the result of this is worth it.
--
Saleem Abdulrasool
abdulras (at) fb (dot) com
I like this direction in general, but: On Thu, Feb 27, 2014 at 7:40 PM, Saleem Abdulrasool <abdulras at fb.com> wrote:> {armv7,i686,x86_64}-windows-{ia,mingw,ms}pe >First a correction, I assume you mean: {armv7,i686,x86_64}-<vendor>-windows-{ia,mingw,ms}pe I think these are the wrong ABI names. And if the environments are uniformly PE, I don't think we should bother with it. I would suggest: ...-windows-{msvc,gnu,itanium} MSVC is obvious. Itanium is obvious. GNU -> mingw's oddity. Rationale: The "Min" isn't relevant to the ABI. The "W" is redundant. The "G" is the only relevant part, and it stands for GNU. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140227/d1ad1a6b/attachment.html>
On Feb 27, 2014, at 7:48 PM, Chandler Carruth <chandlerc at google.com> wrote:> I like this direction in general, but:Excellent!> On Thu, Feb 27, 2014 at 7:40 PM, Saleem Abdulrasool <abdulras at fb.com> wrote: > {armv7,i686,x86_64}-windows-{ia,mingw,ms}pe > > First a correction, I assume you mean: {armv7,i686,x86_64}-<vendor>-windows-{ia,mingw,ms}peThat is indeed what I meant.> I think these are the wrong ABI names. And if the environments are uniformly PE, I don't think we should bother with it.I should have been more clear, the currently supported environments are PE. There are versions of Windows which use other formats, and so I would prefer to retain the PE.> I would suggest: > > ...-windows-{msvc,gnu,itanium} > > MSVC is obvious. > Itanium is obvious. > GNU -> mingw's oddity. > > Rationale: > The "Min" isn't relevant to the ABI. The "W" is redundant. The "G" is the only relevant part, and it stands for GNU.The rational is entirely valid. You raise an excellent point that I failed to consider, MinGW is really "Minimalist GNU on Windows”. I find ia (or ia64) to be nicer, but, Id be happy enough with itanium. Would you be willing to agree to: {armv7,i686,x86_64}-<vendor>-windows-{ia,gnu,ms}pe -- Saleem Abdulrasool abdulras (at) fb (dot) com
Saleem, Thanks to open the Pandora's box! I am certain "Win32" should be common word to represent Win32 API (ABI in some context). Then, I preferer -win32- rather than -windows-. If we could use *-win32, I hope it might be neutral as possible. That said, I don't have concrete plan what *-win32 should be. In other words, I think it'd be worse that "*-pc-win32" represents whole msvc things. I could make the matrix later. This is a random note. * i686-pc-cygwin (gcc-4.x) - PE/COFF - Win32 compatible. Win32 API(s) could be available with <windows.h>. - Doesn't use thiscall. - Doesn't use msvcrt. Using newlib delivered. - Uses GNU libstdc++ and libsupc++. - Uses dw2 eh. * i686-pc-mingw32 (<4.6) - Uses msvcrt.dll. (malloc is not 16-byte aligned). Other versions of msvcrt are optional. - Uses some supplemental libs that incapable in msvcrt.dll. - Uses libgcc - Uses GNU libstdc++ and libsupc++ provided by g++ (lib/gcc/i686-pc-mingw32) - Doesn't use thiscall. - dw2 is available older version of mingw32 was available only sjlj. * *-w64-mingw32 (>=4.6) - Uses msvcrt.dll even on x86_64 (!!!) - EH is optional, x64-comptatible eh (aka seh) may be available. - multilib is available in development environment. - Uses thiscall (for i686) - Uses GNU libstdc++. * x86_64-pc-cygwin - LP64 - Investigating :p I wonder if we could provide neutral *-win32 for our project, or naked *-win32 might be used as non-C++ environments... (Consider with compiler-rt, libcxxabi and libcxx) ...Takumi 2014-02-28 12:40 GMT+09:00 Saleem Abdulrasool <abdulras at fb.com>:> Hi, > > After a discussion with David, Id like to propose a rework of the Windows target triples. The current set of Windows triples are somewhat less uniform than their Linux counterparts. With multiple ABIs and environments on Windows, they are also slightly awkward. Obviously, certain ones might be nice to keep around for compatibility (e.g. the mingw triple). > > Just to ensure that everyone has the same understanding, the canonical format for a triple is: arch-vendor-os-environment . > > We have the following environment on Windows: > > As far as I know, everyone conforms to the MS C ABI. > - There is the MS C++ ABI which is still being developed. > - There is the IA-64 ABI which is incompatible with msvcprt. > - There is the MinGW sub environment which supplies additional UNIX-y functions and uses IA-64 ABI for C++. > > The Windows environment is uniformly (COFF)/PE. > > As for the OS, Windows is slightly generic. Windows 9x, Windows NT, and Windows CE are all slightly different. However, given that Microsoft has taken a unifying strategy with Windows NT, I *think* sticking to Windows for the OS should be okay. That said, I could be convinced to use winnt or windowsnt. > > So, one way to clearly define a naming scheme for this space would be something along the lines of: > > {armv7,i686,x86_64}-windows-{ia,mingw,ms}pe > > This allows us to uniformly take any of the combination IA-64 or MS C++ ABI + MS C ABI or the MinGW environment (which is IA-64 ABI and its supplementary libraries). > > I understand that this may be controversial since it can potentially break existing code bases, but I think that the result of this is worth it. > > -- > Saleem Abdulrasool > abdulras (at) fb (dot) com > > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Win32 is not an ABI. If one were to compile an NT driver, they wouldn't be targeting win32. They would be targeting windows. On Fri Feb 28 2014 at 12:03:32 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote:> Saleem, > > Thanks to open the Pandora's box! > > I am certain "Win32" should be common word to represent Win32 API (ABI > in some context). > Then, I preferer -win32- rather than -windows-. > If we could use *-win32, I hope it might be neutral as possible. > That said, I don't have concrete plan what *-win32 should be. > > In other words, I think it'd be worse that "*-pc-win32" represents > whole msvc things. > > I could make the matrix later. This is a random note. > > * i686-pc-cygwin (gcc-4.x) > - PE/COFF > - Win32 compatible. Win32 API(s) could be available with <windows.h>. > - Doesn't use thiscall. > - Doesn't use msvcrt. Using newlib delivered. > - Uses GNU libstdc++ and libsupc++. > - Uses dw2 eh. > > * i686-pc-mingw32 (<4.6) > - Uses msvcrt.dll. (malloc is not 16-byte aligned). Other versions > of msvcrt are optional. > - Uses some supplemental libs that incapable in msvcrt.dll. > - Uses libgcc > - Uses GNU libstdc++ and libsupc++ provided by g++ > (lib/gcc/i686-pc-mingw32) > - Doesn't use thiscall. > - dw2 is available older version of mingw32 was available only sjlj. > > * *-w64-mingw32 (>=4.6) > - Uses msvcrt.dll even on x86_64 (!!!) > - EH is optional, x64-comptatible eh (aka seh) may be available. > - multilib is available in development environment. > - Uses thiscall (for i686) > - Uses GNU libstdc++. > > * x86_64-pc-cygwin > - LP64 > - Investigating :p > > I wonder if we could provide neutral *-win32 for our project, or naked > *-win32 might be used as non-C++ environments... > (Consider with compiler-rt, libcxxabi and libcxx) > > ...Takumi > > > 2014-02-28 12:40 GMT+09:00 Saleem Abdulrasool <abdulras at fb.com>: > > Hi, > > > > After a discussion with David, Id like to propose a rework of the > Windows target triples. The current set of Windows triples are somewhat > less uniform than their Linux counterparts. With multiple ABIs and > environments on Windows, they are also slightly awkward. Obviously, > certain ones might be nice to keep around for compatibility (e.g. the mingw > triple). > > > > Just to ensure that everyone has the same understanding, the canonical > format for a triple is: arch-vendor-os-environment . > > > > We have the following environment on Windows: > > > > As far as I know, everyone conforms to the MS C ABI. > > - There is the MS C++ ABI which is still being developed. > > - There is the IA-64 ABI which is incompatible with msvcprt. > > - There is the MinGW sub environment which supplies additional UNIX-y > functions and uses IA-64 ABI for C++. > > > > The Windows environment is uniformly (COFF)/PE. > > > > As for the OS, Windows is slightly generic. Windows 9x, Windows NT, and > Windows CE are all slightly different. However, given that Microsoft has > taken a unifying strategy with Windows NT, I *think* sticking to Windows > for the OS should be okay. That said, I could be convinced to use winnt or > windowsnt. > > > > So, one way to clearly define a naming scheme for this space would be > something along the lines of: > > > > {armv7,i686,x86_64}-windows-{ia,mingw,ms}pe > > > > This allows us to uniformly take any of the combination IA-64 or MS C++ > ABI + MS C ABI or the MinGW environment (which is IA-64 ABI and its > supplementary libraries). > > > > I understand that this may be controversial since it can potentially > break existing code bases, but I think that the result of this is worth it. > > > > -- > > Saleem Abdulrasool > > abdulras (at) fb (dot) com > > > > > > > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140228/a74c8e40/attachment.html>
On Feb 27, 2014, at 11:59 PM, NAKAMURA Takumi <geek4civic at gmail.com> wrote:> Saleem, > > Thanks to open the Pandora's box!Agreed that this is probably pandora’s box, but, I think that addressing this now will help with the addition of Windows on ARM.> I am certain "Win32" should be common word to represent Win32 API (ABI > in some context). > Then, I preferer -win32- rather than -windows-. > If we could use *-win32, I hope it might be neutral as possible. > That said, I don't have concrete plan what *-win32 should be.I agree that Windows is less precise, but that ambiguity is slightly on purpose. Win32 is not the OS, its more the set of APIs. Using windows permits us the ability to handle various different scenarios related to Windows (consider the case of Windows drivers where the Windows Kernel APIs are targeted rather than the WIN32 APIs).> In other words, I think it'd be worse that "*-pc-win32" represents > whole msvc things. > > I could make the matrix later. This is a random note. > > * i686-pc-cygwin (gcc-4.x) > - PE/COFF > - Win32 compatible. Win32 API(s) could be available with <windows.h>. > - Doesn't use thiscall. > - Doesn't use msvcrt. Using newlib delivered. > - Uses GNU libstdc++ and libsupc++. > - Uses dw2 eh. > > * i686-pc-mingw32 (<4.6) > - Uses msvcrt.dll. (malloc is not 16-byte aligned). Other versions > of msvcrt are optional. > - Uses some supplemental libs that incapable in msvcrt.dll. > - Uses libgcc > - Uses GNU libstdc++ and libsupc++ provided by g++ (lib/gcc/i686-pc-mingw32) > - Doesn't use thiscall. > - dw2 is available older version of mingw32 was available only sjlj. > > * *-w64-mingw32 (>=4.6) > - Uses msvcrt.dll even on x86_64 (!!!) > - EH is optional, x64-comptatible eh (aka seh) may be available. > - multilib is available in development environment. > - Uses thiscall (for i686) > - Uses GNU libstdc++. > > * x86_64-pc-cygwin > - LP64 > - Investigating :pMinGW32-W64 is a rework of MinGW32. AFAIK, it has entirely superseded MinGW32, so the “gnu” environment would represent both of these. MinGW32-W64 is a fork of cygwin. The “gnu” environment would cover cygwin as well. If they have diverged significantly, cygnus vs gnu could be used to differentiate them.> I wonder if we could provide neutral *-win32 for our project, or naked > *-win32 might be used as non-C++ environments... > (Consider with compiler-rt, libcxxabi and libcxx)The windows-msvc would cover the pure C case. If you are using libc++/libc++abi then you need a C++ ABI. That would be covered by the windows-itanium target.> ...Takumi > > > 2014-02-28 12:40 GMT+09:00 Saleem Abdulrasool <abdulras at fb.com>: >> Hi, >> >> After a discussion with David, Id like to propose a rework of the Windows target triples. The current set of Windows triples are somewhat less uniform than their Linux counterparts. With multiple ABIs and environments on Windows, they are also slightly awkward. Obviously, certain ones might be nice to keep around for compatibility (e.g. the mingw triple). >> >> Just to ensure that everyone has the same understanding, the canonical format for a triple is: arch-vendor-os-environment . >> >> We have the following environment on Windows: >> >> As far as I know, everyone conforms to the MS C ABI. >> - There is the MS C++ ABI which is still being developed. >> - There is the IA-64 ABI which is incompatible with msvcprt. >> - There is the MinGW sub environment which supplies additional UNIX-y functions and uses IA-64 ABI for C++. >> >> The Windows environment is uniformly (COFF)/PE. >> >> As for the OS, Windows is slightly generic. Windows 9x, Windows NT, and Windows CE are all slightly different. However, given that Microsoft has taken a unifying strategy with Windows NT, I *think* sticking to Windows for the OS should be okay. That said, I could be convinced to use winnt or windowsnt. >> >> So, one way to clearly define a naming scheme for this space would be something along the lines of: >> >> {armv7,i686,x86_64}-windows-{ia,mingw,ms}pe >> >> This allows us to uniformly take any of the combination IA-64 or MS C++ ABI + MS C ABI or the MinGW environment (which is IA-64 ABI and its supplementary libraries). >> >> I understand that this may be controversial since it can potentially break existing code bases, but I think that the result of this is worth it. >> >> -- >> Saleem Abdulrasool >> abdulras (at) fb (dot) com >> >> >> >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu https://urldefense.proofpoint.com/v1/url?u=http://llvm.cs.uiuc.edu/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=CchYc4lrV44%2BZqxZADw0BQ%3D%3D%0A&m=WR6HDEoM%2FRJivypqKu8UMSJ3E6UIfOwCb3WXdmZj65g%3D%0A&s=a6333230f7222d44c2d4683c14795046a9bb074f94dff58d9156200245d4f02d >> https://urldefense.proofpoint.com/v1/url?u=http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=CchYc4lrV44%2BZqxZADw0BQ%3D%3D%0A&m=WR6HDEoM%2FRJivypqKu8UMSJ3E6UIfOwCb3WXdmZj65g%3D%0A&s=d32328e604ef1f1744d93d7063b8f165a2c6d341abd8110a25ade496754d1f11-- Saleem Abdulrasool abdulras (at) fb (dot) com
This mostly all makes sense to me. If someone feels strongly about changing "win32" to "windows", they can do that, but we have to keep accepting win32 as a synonym. I'd accept it even when used with new ISAs like armv7. The way we have multiple Windows-ish OSs is probably silly, and should be unpacked to something like -win32-gnu, -win32-msvc, and -win32-itanium. Internally we should map -mingw32 to -win32-gnu and -win32 to -win32-msvc. I may be biased in favor of the second mapping, but it's what we've been doing for a few months now. I'm not sure if we should attempt to map cygwin to -win32-cyg(win)?. It's really a different beast. For the PE portion, I agree we should split it with a dash if its going to be there. And if we do that, we can pull ELF and MachO out of the Environment enum and make a new one for object file format. The object file format should be populated implicitly with the canonical format for the OS, and can be overridden if present. On Thu, Feb 27, 2014 at 11:59 PM, NAKAMURA Takumi <geek4civic at gmail.com>wrote:> Saleem, > > Thanks to open the Pandora's box! > > I am certain "Win32" should be common word to represent Win32 API (ABI > in some context). > Then, I preferer -win32- rather than -windows-. > If we could use *-win32, I hope it might be neutral as possible. > That said, I don't have concrete plan what *-win32 should be. > > In other words, I think it'd be worse that "*-pc-win32" represents > whole msvc things. > > I could make the matrix later. This is a random note. > > * i686-pc-cygwin (gcc-4.x) > - PE/COFF > - Win32 compatible. Win32 API(s) could be available with <windows.h>. > - Doesn't use thiscall. > - Doesn't use msvcrt. Using newlib delivered. > - Uses GNU libstdc++ and libsupc++. > - Uses dw2 eh. > > * i686-pc-mingw32 (<4.6) > - Uses msvcrt.dll. (malloc is not 16-byte aligned). Other versions > of msvcrt are optional. > - Uses some supplemental libs that incapable in msvcrt.dll. > - Uses libgcc > - Uses GNU libstdc++ and libsupc++ provided by g++ > (lib/gcc/i686-pc-mingw32) > - Doesn't use thiscall. > - dw2 is available older version of mingw32 was available only sjlj. > > * *-w64-mingw32 (>=4.6) > - Uses msvcrt.dll even on x86_64 (!!!) > - EH is optional, x64-comptatible eh (aka seh) may be available. > - multilib is available in development environment. > - Uses thiscall (for i686) > - Uses GNU libstdc++. > > * x86_64-pc-cygwin > - LP64 > - Investigating :p > > I wonder if we could provide neutral *-win32 for our project, or naked > *-win32 might be used as non-C++ environments... > (Consider with compiler-rt, libcxxabi and libcxx) > > ...Takumi > > > 2014-02-28 12:40 GMT+09:00 Saleem Abdulrasool <abdulras at fb.com>: > > Hi, > > > > After a discussion with David, Id like to propose a rework of the > Windows target triples. The current set of Windows triples are somewhat > less uniform than their Linux counterparts. With multiple ABIs and > environments on Windows, they are also slightly awkward. Obviously, > certain ones might be nice to keep around for compatibility (e.g. the mingw > triple). > > > > Just to ensure that everyone has the same understanding, the canonical > format for a triple is: arch-vendor-os-environment . > > > > We have the following environment on Windows: > > > > As far as I know, everyone conforms to the MS C ABI. > > - There is the MS C++ ABI which is still being developed. > > - There is the IA-64 ABI which is incompatible with msvcprt. > > - There is the MinGW sub environment which supplies additional UNIX-y > functions and uses IA-64 ABI for C++. > > > > The Windows environment is uniformly (COFF)/PE. > > > > As for the OS, Windows is slightly generic. Windows 9x, Windows NT, and > Windows CE are all slightly different. However, given that Microsoft has > taken a unifying strategy with Windows NT, I *think* sticking to Windows > for the OS should be okay. That said, I could be convinced to use winnt or > windowsnt. > > > > So, one way to clearly define a naming scheme for this space would be > something along the lines of: > > > > {armv7,i686,x86_64}-windows-{ia,mingw,ms}pe > > > > This allows us to uniformly take any of the combination IA-64 or MS C++ > ABI + MS C ABI or the MinGW environment (which is IA-64 ABI and its > supplementary libraries). > > > > I understand that this may be controversial since it can potentially > break existing code bases, but I think that the result of this is worth it. > > > > -- > > Saleem Abdulrasool > > abdulras (at) fb (dot) com > > > > > > > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140228/256d4837/attachment.html>
Seemingly Similar Threads
- [LLVMdev] Code generation support in llvm for windows phone
- [LLVMdev] Code generation support in llvm for windows phone
- [LLVMdev] Code generation support in llvm for windows phone
- [LLVMdev] Support for Windows Phone 8.1
- [LLVMdev] Code generation support in llvm for windows phone