Gas64 (no more use of gcc, only gas) WDS / LNX
Re: Gas64 (no more use of gcc, only gas) WDS / LNX
I hope this backend could be extended to support Linux and FreeBSD, so FBC no longer depends on GCC. But keep it in mind, FreeBSD's AS tool is not compatible with GAS. So one still has to install the binutils packages in order to use this backend. You should put this clear if you ever want to support FreeBSD.
-
- Posts: 789
- Joined: Jul 26, 2018 18:28
Re: Gas64 (no more use of gcc, only gas) WDS / LNX
Linux already supports
Re: Gas64 (no more use of gcc, only gas) WDS / LNX
I was trying to break the compiler for something that adeyblue had reported, and found this instead:
> fbc-win64 bigstructs.bas -gen gas64 -v
OUTPUT:
FreeBASIC Compiler - Version 1.09.0 (2021-09-06), built for win64 (64bit)
Copyright (C) 2004-2021 The FreeBASIC development team.
standalone
target: win64, x86-64, 64bit
backend: gas64
compiling: bigstructs.bas -o bigstructs.asm (main module)
bigstructs.bas(19) warning 24(3): Variable too large for stack, consider making it SHARED
bigstructs.bas(20) warning 24(3): Variable too large for stack, consider making it SHARED
assembling: d:\fb.git\bin\win64\as.exe --64 --strip-local-absolute "bigstructs.asm" -o "bigstructs.o"
bigstructs.asm: Assembler messages:
bigstructs.asm:13: Error: operand type mismatch for `sub'
bigstructs.asm:100: Error: 0x7fffffc4 out range of signed 32bit displacement
assembling failed: 'd:\fb.git\bin\win64\as.exe' terminated with exit code 1
Code: Select all
'' 1K struct
type T
z as zstring * 1024
end type
'' 1MB struct
type T2
a(1 to 1024) as T
end type
'' 1GB struct
type T3
a(1 to 1024) as T2
end type
'' big structs
dim a as T3
dim b as T3
OUTPUT:
FreeBASIC Compiler - Version 1.09.0 (2021-09-06), built for win64 (64bit)
Copyright (C) 2004-2021 The FreeBASIC development team.
standalone
target: win64, x86-64, 64bit
backend: gas64
compiling: bigstructs.bas -o bigstructs.asm (main module)
bigstructs.bas(19) warning 24(3): Variable too large for stack, consider making it SHARED
bigstructs.bas(20) warning 24(3): Variable too large for stack, consider making it SHARED
assembling: d:\fb.git\bin\win64\as.exe --64 --strip-local-absolute "bigstructs.asm" -o "bigstructs.o"
bigstructs.asm: Assembler messages:
bigstructs.asm:13: Error: operand type mismatch for `sub'
bigstructs.asm:100: Error: 0x7fffffc4 out range of signed 32bit displacement
assembling failed: 'd:\fb.git\bin\win64\as.exe' terminated with exit code 1
Re: Gas64 (no more use of gcc, only gas) WDS / LNX
Fixed.coderJeff wrote:bigstructs.asm:13: Error: operand type mismatch for `sub'
However if cases where the stack needs to be defined >2GB......
I can't get this error.coderJeff wrote:bigstructs.asm:100: Error: 0x7fffffc4 out range of signed 32bit displacement
Come on discord when you want.
Re: Gas64 (no more use of gcc, only gas) WDS / LNX
What version of gnu-AS you are using? I am using 2.30 at the moment.SARG wrote:I can't get this error.coderJeff wrote:bigstructs.asm:100: Error: 0x7fffffc4 out range of signed 32bit displacement
I see your PR to fix differences between 32/64-bit fbc so the output from both compilers is the same for me '-gen gas64'
I get same ASM output both compilers. I will merge in the patch, thank-you.
The deeper issue which we probably can't do much about is hitting the limits on x86_64 instructions. The example I gave is a good example of a bad program. As far as I can tell, x86_64 displacements are limited to signed 32-bit. With very large stack usage as in the example, the displacements exceed the limit of -(2^31) and produce the error.
Re: Gas64 (no more use of gcc, only gas) WDS / LNX
I use as.exe provided for 64bit :
GNU assembler version 2.24 (x86_64-w64-mingw32) using BFD version (GNU Binutils) 2.24
The log :
Disassembling the exe gives a code completely wrong so I guess even no error the assembler is lost......
GNU assembler version 2.24 (x86_64-w64-mingw32) using BFD version (GNU Binutils) 2.24
The log :
- D:\fb32bit>fbc32_gas64.exe -gen gas64 -RR -v -target win64 test.bas -g
FreeBASIC Compiler - Version 1.09.0 (2021-09-07), built for win32 (32bit)
Copyright (C) 2004-2021 The FreeBASIC development team.
standalone
target: win64, x86-64, 64bit
backend: gas64
compiling: test.bas -o test.asm (main module)
test.bas(17) warning 24(3): Variable too large for stack, consider making it SHARED
test.bas(18) warning 24(3): Variable too large for stack, consider making it SHARED
assembling: D:\fb32bit\bin\win64\as.exe --64 "test.asm" -o "test.o"
linking: D:\fb32bit\bin\win64\ld.exe -m i386pep -o "test.exe" -subsystem console -T "D:\fb32bit\lib\win64\fbextra.x" --stack 2097152,2097152 -L "D:\fb32bit\lib\win64" -L "." "D:\fb32bit\lib\win64\crt2.o" "D:\fb32bit\lib\win64\crtbegin.o" "D:\fb32bit\lib\win64\fbrt0.o" "test.o" "-(" -lfb -lgcc -lmsvcrt -lkernel32 -luser32 -lmingw32 -lmingwex -lmoldname "-)" "D:\fb32bit\lib\win64\crtend.o"
D:\fb32bit\bin\win64\ld.exe: cannot open linker script file D:\fb32bit\lib\win64\fbextra.x: No such file or directory
linking failed: 'D:\fb32bit\bin\win64\ld.exe' terminated with exit code 1
Disassembling the exe gives a code completely wrong so I guess even no error the assembler is lost......
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: Gas64 (no more use of gcc, only gas) WDS / LNX
I build first time my standard libraray with -gen gas64 but it ends with wrong emitted assembler code.
32-bit: -gen gas -gen gcc
64-bit: -gen gcc works here
Joshy
assembling: d:\FreeBASIC\bin\win64\as.exe --64 --strip-local-absolute "tinyComplex_sqr.asm" -o "tinyComplex_sqr.o"
tinyComplex_sqr.asm: Assembler messages:
tinyComplex_sqr.asm:40: Error: incorrect register `r11' used with `l' suffix
tinyComplex_sqr.asm:109: Error: incorrect register `r11' used with `l' suffix
tinyComplex_sqr.asm:184: Error: incorrect register `r10' used with `l' suffix
assembling failed: 'd:\FreeBASIC\bin\win64\as.exe' terminated with exit code 1
32-bit: -gen gas -gen gcc
64-bit: -gen gcc works here
Joshy
assembling: d:\FreeBASIC\bin\win64\as.exe --64 --strip-local-absolute "tinyComplex_sqr.asm" -o "tinyComplex_sqr.o"
tinyComplex_sqr.asm: Assembler messages:
tinyComplex_sqr.asm:40: Error: incorrect register `r11' used with `l' suffix
tinyComplex_sqr.asm:109: Error: incorrect register `r11' used with `l' suffix
tinyComplex_sqr.asm:184: Error: incorrect register `r10' used with `l' suffix
assembling failed: 'd:\FreeBASIC\bin\win64\as.exe' terminated with exit code 1
Code: Select all
#include once "tinyComplex.bi"
' sqr
function complex_sqr(byref z as tComplex) as tComplex
dim as const tReal x = z.real()
dim as const tReal y = z.imag()
if (x=0) then
dim as tReal t = rSqr(rAbs(y)/2)
return tComplex(t, iif(y<0,-t,t))
else
dim as tReal t = rSqr(2*complex_abs(z) + rAbs(x))
dim as tReal u = t / 2
if (x>0) then return tComplex(u,y/t)
return tComplex(rAbs(y)/t, iif(y<0,-u,u))
end if
end function
Re: Gas64 (no more use of gcc, only gas) WDS / LNX
@D.J.Peters
Thanks for the report.
Where I can find tinyComplex.bi ? I need it to see the generated code.
Thanks for the report.
Where I can find tinyComplex.bi ? I need it to see the generated code.
Re: Gas64 (no more use of gcc, only gas) WDS / LNX
Hi SARG
I am getting assembler errors here 1.09:
I am getting assembler errors here 1.09:
Code: Select all
#cmdline "-gen gas64"
Dim As Single a = 50
Dim As Single b = 40
Dim as Single L=Sqr(a*a+b*b)
print L
sleep
Re: Gas64 (no more use of gcc, only gas) WDS / LNX
@dodicat
Thanks for the report.
At first glance an issue in optimization : an used register wrongly freed.
Thanks for the report.
At first glance an issue in optimization : an used register wrongly freed.
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: Gas64 (no more use of gcc, only gas) WDS / LNX
here you need both extracted folders on same drive or home folder.SARG wrote:@D.J.Peters
Thanks for the report.
Where I can find tinyComplex.bi ? I need it to see the generated code.
TinyEngine/ (all *.bi files)
TinyEngine-src/ (all *.bas files)
take a look at: "TinyEngine-src/build64-gas64.bat " maybe my compiler switches are a part of the problem !
Joshy
Last edited by D.J.Peters on Jan 09, 2022 9:00, edited 1 time in total.
Re: Gas64 (no more use of gcc, only gas) WDS / LNX
You can just use this command line, all useless options removed. However it would be surprising that this is the reason of the issue.D.J.Peters wrote:take a look at: "TinyEngine-src/build64-gas64.bat " maybe my compiler switches are a part of the problem !
Code: Select all
d:\FreeBASIC\fbc64.exe -v -gen gas64 -w pedantic -lib -i ../TinyEngine/inc -x ../TinyEngine/lib/win64/libTinyEngine-64-static.a *.bas
Re: Gas64 (no more use of gcc, only gas) WDS / LNX
@D.J.Peters
Bug fixed in 10 minutes.... : a variable containing the right datatype was not enough propagated (Jeff created constant datatypes that need to be changed in their standard counterpart before using).
Now all the files are compiled fine.
Until a new daily build is released I can provide ir-gas64.bas fixed.
Edit
Issue reported by dodicat also fixed (one line missing....).
Bug fixed in 10 minutes.... : a variable containing the right datatype was not enough propagated (Jeff created constant datatypes that need to be changed in their standard counterpart before using).
Now all the files are compiled fine.
Until a new daily build is released I can provide ir-gas64.bas fixed.
Edit
Issue reported by dodicat also fixed (one line missing....).
Re: Gas64 (no more use of gcc, only gas) WDS / LNX
Is there a reason the stabs info is put in special sections and not .stab and .stabstr? I don't know about other targets, but I modified your code a bit and in Win and Lin (Ubuntu) if you make the value part of the stab info a .long instead of .quad, objdump -G will then parse it correctly.
Re: Gas64 (no more use of gcc, only gas) WDS / LNX
Initial stabs don't exist in 64bit and the sizes are limited to 32bit for example the addresses so I have kept the same format increasing sizes to 64bit when necessary.adeyblue wrote:Is there a reason the stabs info is put in special sections and not .stab and .stabstr? I don't know about other targets, but I modified your code a bit and in Win and Lin (Ubuntu) if you make the value part of the stab info a .long instead of .quad, objdump -G will then parse it correctly.
There are other limitations, for example max line number is 65535. As the format is now handled by fbc's devs they could easily be removed.
My purpose is to bring a debugger working in 64bit and fbdebugger is the only debugger (or tool) which can exploit that debug data therefore section names don't matter. But using .stab and .stabstr create problems, if I remember well, when linking.
BTW Dwarf format is a nightmare :-)
On the other hand stabs are easy to generate, to read and more important all cases of fbc code can be covered .