Greetings,

This is very exciting! One nit, though: the target and abi suffixes and identifiers are somewhat inconsistent due to an alternation between win, winabi, and windows. To that end, how about the following:

- _winabi for the (framework-independent) ABI.
- _win32 for cygwin/msys2 targets.
_ _winnt for the midipix target.


Rationale:

- _winbi should implement the x86 software conventions as described in https://learn.microsoft.com/en-us/cpp/build/x64-software-conventions

- _win32 should implement all bits pertaining to the cygwin/msys2 target variant, specifically with respect to long (LP64), wchar_t (short), and _start, main(), and related matters.

- _winnt should implement all bits pertaining to the midipix target variant, specifically with respect to long (LP64), wchar_t (int), and _start, main(), and related matters.


Other thoughts:

- implementation of dllimport/dllexport at the level of the target variant.

- 32-bit support (outside the scope of the amd64 patches): implementation of the stdcall and fastcall calling conventions.

Cheers,
midipix

--

The naming is pretty messy; I just wrote the first thing that came to mind.
I want to keep the target name short, though. amd64_windows is a bit too
long in my opinion. amd64_win32 is a bit misleading, as it makes you wonder
if it really is 64-bit or not. I also feel like calling the "midipix" target
"winnt" is REALLY misleading.

32-bit support doesn't seem to be a priority. I for one think it should die
already.

wchar_t differing in width seems beyond the scope of QBE. Certain targets
using different sizes is a confusing thing that I do not think is a good
idea. (Also, I thought Windows only used UTF-16 for wchar_t?)

How would dllimport/dllexport be any different from already existing
functionality? dllimport is implicit on unknown functions, and the export
keyword already exists. Just instruction your linker to make a shared
library should have you generating a DLL with QBE.

On 04/24/2024 14:29, finxx wrote:
> The naming is pretty messy; I just wrote the first thing that came to mind.
> I want to keep the target name short, though. amd64_windows is a bit too
> long in my opinion. amd64_win32 is a bit misleading, as it makes you wonder
> if it really is 64-bit or not. I also feel like calling the "midipix" target
> "winnt" is REALLY misleading.
> 

Re. amd64_win32 -- I believe that would be in line with x86_64-w64-mingw32, which is one of the binutils/gcc win64 target names. Then again, one has to keep in mind that Win32 predominantly refers to the application api (as opposed to the target abi), as explained for instance here:

- https://learn.microsoft.com/en-us/windows/win32/desktop-programming

> 32-bit support doesn't seem to be a priority. I for one think it should die
> already.
> 

People still are using it, and here's one relatively recent discussion of relevance, where particularly the lab equipment argument is one that often gets overlooked:

- https://github.com/msys2/MINGW-packages/discussions/19326#discussioncomment-7860475

> wchar_t differing in width seems beyond the scope of QBE. Certain targets
> using different sizes is a confusing thing that I do not think is a good
> idea. (Also, I thought Windows only used UTF-16 for wchar_t?)

Windows could mean in this context either win32 (utf-16) or midipix (int); and even without the midipix target, to properly implement L' literals from within QBE you'd need to make the size of wchar_t a target-specific property.

> 
> How would dllimport/dllexport be any different from already existing
> functionality? dllimport is implicit on unknown functions, and the export
> keyword already exists. Just instruction your linker to make a shared
> library should have you generating a DLL with QBE.
> 

Perhaps I'm missing something, however dllimport is not the same thing as extern, and grepping QBE for __imp_ suggests that nothing currently handles it.

--

> People still are using it, and here's one relatively recent discussion of relevance, where particularly the lab equipment argument is one that often gets overlooked:

I can understand if people can't upgrade, but I don't think that a modern peice
of software should be required to accomodate for them. It is fine if you want
to implement it, I just don't think it would be worth it.

> Windows could mean in this context either win32 (utf-16) or midipix (int); and even without the midipix target, to properly implement L' literals from within QBE you'd need to make the size of wchar_t a target-specific property.

This should be a job for the language front-end, not QBE.

> Perhaps I'm missing something, however dllimport is not the same thing as extern, and grepping QBE for __imp_ suggests that nothing currently handles it.

From what I can tell, the only thing dllexport/dllimport does is mangle the
name. Doing so probably isn't worth adding a new keyword for. You couldn't make
it always happen for the windows target, since UCRT doesn't use it.

If dllexport/dllimport do more than just mess with the symbol name, I can't
figure out what.

On 04/24/2024 16:57, finxx wrote:
> > People still are using it, and here's one relatively recent discussion of relevance, where particularly the lab equipment argument is one that often gets overlooked:
> 
> I can understand if people can't upgrade, but I don't think that a modern peice
> of software should be required to accomodate for them. It is fine if you want
> to implement it, I just don't think it would be worth it.
> 
> > Windows could mean in this context either win32 (utf-16) or midipix (int); and even without the midipix target, to properly implement L' literals from within QBE you'd need to make the size of wchar_t a target-specific property.
> 
> This should be a job for the language front-end, not QBE.
> 

It is possible for the language front-end to take care of that, of course, but then the generated qbe will be in the form of an array, not a string literal.

> > Perhaps I'm missing something, however dllimport is not the same thing as extern, and grepping QBE for __imp_ suggests that nothing currently handles it.
> 
> From what I can tell, the only thing dllexport/dllimport does is mangle the
> name. Doing so probably isn't worth adding a new keyword for. You couldn't make
> it always happen for the windows target, since UCRT doesn't use it.
> 

Is it possible that you're referring here to stdcall/fastcall calling conventions (which are only relevant to the 32-bit targets) as opposed to the dllexport/dllimport attributes?

> If dllexport/dllimport do more than just mess with the symbol name, I can't
> figure out what.

Attached is a test program that demonstrates the most important aspects of the winabi, along with the assembly generated by gcc for the msys2-ucrt target. Things to pay attention to in winabi.s are:

1. call foo vs.   call *__imp_bar(%rip)

2. buzz_global (which qbe would define as 'export') has a '.globl' visibility but _no_ -export directive.

3. buzz_export has both the '.globl' visibility and an -export directive.

4. the .def directive

5. the various .seh directives.

--

Actually, looking through the manual, I can't find anything for any target
regarding exporting symbols in the final binary. There is the option that
adding the function to the .drectve be a job for the language frontend,
but this feels like something QBE should handle. I don't want to make a
language design decision, so I won't try and implement it. You should bring
this up outside of this thread in the mailing list and see what Quentin has
to say.

On Thu, Apr 25, 2024, at 04:15, finxx wrote:
> You should bring
> this up outside of this thread in the mailing list and see what Quentin has
> to say.

My opinion is that code wins arguments. Once we have patches
that significantly make progress towards supporting a new
platform then we can discuss naming and architecture. But I
think that it is premature to embark now on such talking.

I mean no offense, I just want to encourage progress.

Cheers.