FreeBASIC 64bit Compiler

[SARG]

At the Go Tools site (GoRc and other tools) there is interesting information about asm coding under x64 :

http://www.godevtool.com/GoasmHelp/64bits.htm

It seems not so easy to change the asm back end to x64 but not impossible. An interesting project....

As you said, AGS, "Of course not having to start from scratch is an advantage" :-)

[AGS]

I remember a discussion, on this forum (long time ago), about using C as a target
language for FreeBASIC. And the discussion led to something of a split: there were
those that were not too keen on having a C back end. And there were those that
were okay with the idea (I don't think anyone got really enthusiastic about the
idea of targeting C).

Fast forward to 2014 and all of a sudden C is to become the default back end
for the 64bit version of FreeBASIC. What happened here?
The gcc back end was never used that much on x86. The default back end on x86
was and is the assembler back end. And I don't think many fb programmers care(d)
about using anything but the default back end.

When fb programmers want to make a switch to 64bit then they all of a sudden
have to use the C back end (as there is no alternative back end when compiling a
64bit application) and have to install gcc. Perhaps llvm can produce 64bit applications
as well but the llvm back end has seen so little use it cannot be considered anything but
pre-beta quality (post-alpha, unstable, whatever-you-want-to-call-it).

Afaik the C back end does not support the entire FreeBASIC language. Using it
as a default target language would mean having to drop features from the
language. But, as I wrote: afaik and I could be wrong here.

As a question to the devs: are there plans to create a x86-64 back end? Or would having
such a back end be desirable?

It should be clear to everyone using FreeBASIC what they are getting if and when
a 64bit version of FreeBASIC gets released.

[AGS]

At the Go Tools site (GoRc and other tools) there is interesting information about asm coding under x64 :

http://www.godevtool.com/GoasmHelp/64bits.htm

It seems not so easy to change the asm back end to x64 but not impossible. An interesting project....

As you said, AGS, "Of course not having to start from scratch is an advantage" :-)

If it is considered enough to just change register names, get calling conventions right (caller-callee/
stack/register related things) and make sure some other things are dealed with x64 differs little
from x86.

If, however, you'd want to take full advantage of the possibilities of the x64 instruction set then
things become different. You'd have to add quite a bit of code to get register allocation right,
generate optimized code using SSEx where possible etc...
Most of those kind of optimizations require elaborate code analysis.

The biggest problem to me seems to be the lack of support in the C back end for
parts of the current FreeBASIC syntax. Using the C back end should not necessitate having to program
in FreeBASIC-- (FreeBASIC-- = a 'cut down' version of FreeBASIC). Targetting C is fine by me
but not if that means I cannot use feature x, y and z of the FreeBASIC language.

[marcov]

Fast forward to 2014 and all of a sudden C is to become the default back end
for the 64bit version of FreeBASIC. What happened here?

Seems that dkl prefers it.

The gcc back end was never used that much on x86. The default back end on x86
was and is the assembler back end. And I don't think many fb programmers care(d)
about using anything but the default back end.

Implementers decide, not users. Want to improve native backend, then work on it and support it, just
like Daniel is doing for the C end.

Personally, I don't like the C (or LLVM) route either.

Perhaps llvm can produce 64bit applications
as well but the llvm back end has seen so little use it cannot be considered anything but
pre-beta quality (post-alpha, unstable, whatever-you-want-to-call-it).

LLVM (non x86 and windows) seems to have become more palapable, but still has some way to go. But worse, it brings in
the same dependencies and buildtools trouble as the C direction, so I'm not really sure this is a solution. That may change long term of course, but they said that about gcc too in the nineties, and I'm still waiting.

Afaik the C back end does not support the entire FreeBASIC language. Using it
as a default target language would mean having to drop features from the
language. But, as I wrote: afaik and I could be wrong here.

And features added and their implementation are chosen to match that, yes. No messing with the stack.

As a question to the devs: are there plans to create a x86-64 back end? Or would having
such a back end be desirable?

That (the need for it) is harder to answer. 64-bit seems to be more important on the *nix side, but the *nix side leans towards C.
The push for 64-bit, is less so on client windows. More than half of the average users apps (and usually a lot more) are still 32-bit, except services and shell plugins. On the Windows server, the 64-bit migration is also more pronounced though.

One could argue that C backend is good enough though. But anyway, it doesn't make sense to argue about the "need", if there are no people interested to actually do the work.

[dkl]

I haven't wanted to work on more ASM backends due to lack of knowledge: I've never even programmed in x86 ASM, all I know about it comes from work on fbc. Much less x86_64 or ARM etc.

Today I'm pretty confident though that I, or anyone else who might want to really work on it, could add an x86_64 ASM backend to fbc. A huge chunk of work (the 64bit support in fbc's front & middle ends) is already done, and the C backend works for x86_64, so there's a way to get started. All that's left to do is to extend the ASM backend with a x86_64 emitter module and adjust fbc's middle end to support x86_64 ABI details such as passing arguments in registers. The former I think will be easy but a lot of work, the latter will require some internal restructuring/clean ups but I think it's possible.

It'd sure be nice to have more ASM backends in fbc (and, more people working on/maintaining it). They should generate good code, but it doesn't have to be perfect. And they definitely shouldn't do things like "rearranging code because the C standard allows it" which is an issue with the C backend & GCC optimizations. Either way though, the C backend is working right now which is better than nothing and always a nice alternative/fall back option to have.

I agree that it sucks to make it the default because it's slow, must be included in FB distribution, etc. Of course currently for x86_64 or ARM it's fbc's only option. The 2 FB features that are having difficulties with the C backend are FB's va_first/va_arg/va_next macros and FB's inline asm. There's a mix of x86 vs non-x86 issues and gcc-related issues in both cases. It's obvious that x86 inline asm only works on x86, but the vararg macros are something that I think are by design too x86-specific to work on other platforms: They assume that the vararg parameters are passed on stack (following the x86 ABI), which I think isn't the case with the x86_64 ABI where they may be passed in registers etc. So unless we find a way around it, this part of the FreeBASIC language isn't portable.

[marcov]

One interesting thing to note here is

The caller reserves space on the stack for arguments passed in registers. The called function can use this space to spill the contents of registers to the stack.

That's pretty normal and called a "register save area".

The problem is that while X86_64 shares the common feel of i386, the programming model is more RISC like, a trend already started with the i686 ABIs followed by e.g. OS X. So a general RISC way of doing things, many orthogonal registers, cheap PIC, register save areas, register FPU, generally no multiple calling conventions. (only one system ABI)

Some x86 artifacts are still available, e.g. the new registers have corresponding small size equivalents (r11w etc), but not high byte (what would be equivalent to AH..DH), the variable instruction size and the CISC complex addressing modes. While the subdivision is not RISC, propagating the feat to all registers is a RISC feature (orthogonality, all registers behave the same)

Microsoft lets you pass arguments by means of registers as well but uses only four registers(not 6).
And floating point arguments are passed using sse (mmx registers).

SSE2 (and btw, mmx!=sse. And sse!=sse2)

Afaik for Windows XP 64-bit, x87 was even deprecated, one HAD to use SSE2.

The most interesting feature of x64 seems to be the larger amount of registers. Even after using 4 to 6 registers
for passing arguments there are still 6 left. Which could mean that all local variables can be kept in registers.
Register allocation becomes an interesting issue when you can use more than a couple of registers
(on x86 there are only a few registers available so there is very little that can be done using some smart
register allocation algorithm).

Cheap PIC and finally a guaranteed new base level. (everything at least first generation (754) Athlon64. Second generation (939) Athlon64 if you use WIn8, which adds some important atomic operations forgotten in the first design, as well as SSE3 and safd/lafd. SSE3 chiefly adds some with unaligned memory access variants to SSE2)

Updating the x86 back end so it can take advantage of those extra registers could prove to be quite a bit of work.

It is still a new architecture. So talking about "updating" is underestimating the effort a bit.

And making use of extra registers efficiently might require changes to register allocation strategy, and investing in a SSA middle end might be a good thing too.

Not to mention that the code generated for calling functions/returning from functions has to be changed quite
a bit. Overall the x86 assembler generating back end needs an overhaul to 'change' it into a x64 assembler
generating back end. Of course not having to start from scratch is an advantage. And somehow I don't think a
back end that generates x64 assembler is anywhere near the top of the devs to-do list.

One of the problems of having only backend is that a lot that was simply hardcoded by generating some glue assembler and a bit of stack space now becomes a problem. The same goes for the libraries.

In general, minimization of assembler and arch specific usage(*), and a flexible way for the compiler to call RTL helpers (so that the abstract CG can call a helper by simply calling an overriden method etc)

(*) I fear for fbgfx there.

It seems a lot easier to get the C back end to generate x64 specific C as C is C is C :)

C is not C, since C is not something defined, but only a set of rules (set in the standard) that must be obeyed. In other cases, compilerwriters have a free hand.

What you have to watch out for are type definitions. On x64 the size of a pointer is 8 bytes and
a long is 64 bits.

No that is not universally true. E.g. on Windows long is 32-bit and longlong is 64-bit. This afaik also applies to some commercial unices, but since my knowledge there is outdated, they might have adjusted meanwhile.

An integer is still 32 bits though? All of that is, of course, platform/compiler dependent.

IIRC some IBM platforms were ILP64, and thus had integer=64-bit. Not sure if it was x86_64 though.

Personally I'd like to keep the possibility to use the freebasic inline assembler syntax regardless of the
back end. Writing gcc - style inline assembler just isn't any fun.

Keep the possibility: certainly. In time though, more node oriented assembler is more optimal, though it usually only matters in often used language helpers. But that is probably still far away.

[MichaelW]

Personally I'd like to keep the possibility to use the freebasic inline assembler syntax regardless of the
back end. Writing gcc - style inline assembler just isn't any fun.

I agree. I don’t know about x64, but for 32-bit code the gcc backend does not prevent you from using Intel syntax in inline assembly. Compared to the gas backend there are differences: you must provide statements to switch to Intel syntax and then back to AT&T syntax, each statement must be enclosed in double quotes, and AFAICT the compiler does not provide anything to help you access variables or procedure parameters. Of these differences the third is a problem, but in the case of shared variables the names are easy to predict, for static variables you can get the names from the gcc assembly output, and the same for the EBP-relative displacements for procedure parameters and local variables.

Code: Select all

dim shared as integer g_i = 1,g_j

function Test( byval x as integer, byref y as integer ) as integer
    dim as integer r
    asm
        ".intel_syntax noprefix"
        "mov eax, [ebp+8]"
        "mov ecx, [ebp+12]"
        "add eax, [ecx]"
        "mov [ebp-8], eax"
        ".att_syntax prefix"
    end asm
    return r
end function

function TestNaked naked( byval x as integer, byref y as integer ) as integer
    asm
        ".intel_syntax noprefix"
        "mov eax, [esp+4]"
        "mov ecx, [esp+8]"
        "add eax, [ecx]"
        "ret 8"
        ".att_syntax prefix"
    end asm
end function

print Test(1,2)
print TestNaked(1,2)

asm
    ".intel_syntax noprefix"
    "mov eax, _G_I$"
    "shl eax, 4"
    "mov _G_J$, eax"
    ".att_syntax prefix"
end asm

print g_j

''-----------------------------------------------------
'' For an initialized shared variable to be assigned a
'' symbol it must be accessed somewhere in the source.
''-----------------------------------------------------

g_j = g_i

sleep

[jcfuller]

I didn't think any of the 64bit c/c++ compilers had built in asm statements??

James

[marcov]

I didn't think any of the 64bit c/c++ compilers had built in asm statements??

Afaik BCB only supports AT&T and only for whole functions (but inside the C/C++ sourcefile). Most recent BCB's are LLVM based afaik, which may account for the (quite alien for Borland users) AT&T requirement. At the company, we reverted from the "full (Pascal and C++) to the small package (Pascal only) a few years back, so I don't really know the most recent versions first hand.

Delphi 64-bit allows intel asm, but also only whole functions. but the intel Delphi's are not (yet) LLVM based. The ARM crosscompilers are said to be LLVM. I don't use them, so don't know about their assembler status.

In short: LLVM might also be only AT&T.

[MichaelW]

It apparently depends on the compiler. Judging from my quick search, the Microsoft compiler does not, GCC does, and the Intel compiler does.

[jcfuller]

It apparently depends on the compiler. Judging from my quick search, the Microsoft compiler does not, GCC does, and the Intel compiler does.

I am surprised with MinGW gcc. I know I tried but it may have been with some code using intel syntax that failed?

James

[dkl]

For now I have continued to use existing FB target names, and only added new ones: win32, linux, x86_64-win32, x86_64-linux, ...
[...]

To follow up on this, now I'm thinking we should use these target names:

dos
win32
win64
linux-i686
linux-x86_64
linux-armv6
linux-armv7
freebsd-i686
freebsd-x86_64

Basically using the <os>-<arch> format for Linux/BSD and keeping it very simple for dos/win32/win64. It seems to me that this is the prettiest solution, for example "win64" should be all that's needed -- much better than "x86_64-win32". In other words, it's simple for Windows users, while having more variety for Linux/BSD.

[marcov]

To follow up on this, now I'm thinking we should use these target names:

On FPC dos 32-bit is "go32v2", and msdos is reserved for native (16-bit) dos.