Gas64 (no more use of gcc, only gas) WDS / LNX

User projects written in or related to FreeBASIC.
marcov
Posts: 3019
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: Gas64 (no more use of gcc, only gas) :-)

Postby marcov » Dec 13, 2019 21:47

Do you take into account the varying ABIs between win64 and *nix? (Different parameter regs). Do you use SSE or fpu for floating point support on win64 ? Register parameter save area, red zone support ?
Last edited by marcov on Dec 14, 2019 11:09, edited 2 times in total.
Xusinboy Bekchanov
Posts: 254
Joined: Jul 26, 2018 18:28

Re: Gas64 (no more use of gcc, only gas) :-)

Postby Xusinboy Bekchanov » Dec 14, 2019 3:48

SARG wrote:@Xusinboy,

Thanks for yours comment and report.

First issue is fixed. New version to come...
Before a call it's mandatory saving some registers and after the call restoring them. I forgot to do that for "internal calls" like cos, int, etc.
In your example using 'int' induces unwanted change in one register.....

Thank you.

SARG wrote:Second issue
I'm not able to get a working exe even with the classic compilers (fbc 32bit or 64bit). The message box doesn't show the right text.
The text from the forum is saved in a notepad file then renamed as a bas file and finaly compiled. I guess I missed something.
How do you proceed to compile ?

This example is included in the compiler, in the folder: \examples\unicode\hello_UTF8.bas
To compile it, it must be saved in "utf8" encoding.
In the "examples" folder is saved correctly, you only need to compile.
SARG
Posts: 1157
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Gas64 (no more use of gcc, only gas) :-)

Postby SARG » Dec 14, 2019 23:59

@Xusinboy
Xusinboy Bekchanov wrote:This example is included in the compiler, in the folder: \examples\unicode\hello_UTF8.bas
To compile it, it must be saved in "utf8" encoding.
In the "examples" folder is saved correctly, you only need to compile.

Thanks for your advice. I guess there is a unicode flag (BOM) in this file as copying the text was not enough.
Anyway it was a boring hunt for finally finding a stupid mix of string and wstring. No problem with latin characters but with chinese ones it gives an unexpected result.....

Second issue fixed. Only fbc64_gas64.exe and ir-gas64. bas : http://users.freebasic-portal.de/sarg/f ... _short.zip


@marcov
marcov wrote:Do you take into account the varying ABIs between win64 and *nix? (Different parameter regs).
I'm aware of the differences and for procedure calls I could estimate it's ready at about 90%. Look at the code by searching #ifdef __fb_linux__ but don't hope to easily understand what is done ;-)
marcov wrote:Do you use SSE or fpu for floating point support on win64 ? Register parameter save area, red zone support ?

XMMx registers are used so SSE. Do you have a comment about that choice ?

The register parameters are saved that is also needed for debugging (not of compiler but user's exes). Currently the exe generated with gcc are not correctly debuggable.

Concerning the red zone any space is not reserved and I do not really figure out its purpose....

FYI at the begginng of the project, not very skilled in assembly, I was often looking at the asm code generated by gcc.
Now I will still take any advice.
Xusinboy Bekchanov
Posts: 254
Joined: Jul 26, 2018 18:28

Re: Gas64 (no more use of gcc, only gas) :-)

Postby Xusinboy Bekchanov » Dec 15, 2019 8:24

SARG wrote:@Xusinboy
Second issue fixed. Only fbc64_gas64.exe and ir-gas64. bas : http://users.freebasic-portal.de/sarg/f ... _short.zip

Very good work. Runs fast like a 32-bit GAS. I used to compile for debugging on a 32-bit GAS. Now for me it doesn't matter 32-bit or 64-bit, they are equally fast. And gdb64 downloaded for debugging. And when will you add this 64-bit GAS to the official build?
marcov
Posts: 3019
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: Gas64 (no more use of gcc, only gas) :-)

Postby marcov » Dec 15, 2019 13:32

SARG wrote:
marcov wrote:Do you take into account the varying ABIs between win64 and *nix? (Different parameter regs).
I'm aware of the differences and for procedure calls I could estimate it's ready at about 90%. Look at the code by searching #ifdef __fb_linux__ but don't hope to easily understand what is done ;-)


Ok.

marcov wrote:Do you use SSE or fpu for floating point support on win64 ? Register parameter save area, red zone support ?

XMMx registers are used so SSE. Do you have a comment about that choice ?


No other one than that is the good one. x87 is deprecated on windows 64-bit, though afaik some compilers do use some of the more special functions (like sin cos). I don't know if that is because the ABI was updated or if it is "illegal".

The register parameters are saved that is also needed for debugging (not of compiler but user's exes). Currently the exe generated with gcc are not correctly debuggable.


I'm not aware of that. Afaik the callee as per ABI can do with the register parameter area what it wants, even store temps. Maybe some compiler do it nicely 1:1 for debugging purposes, but this is afaik not the standard.

Concerning the red zone any space is not reserved and I do not really figure out its purpose....


It is a bit the same idea as register parameter area(rpa), but then on *nix. Provide some room to leaf procedure to store some values, making it thus more likely they can omit the stack frame. The only thing is that it is in the as yet unallocated stack instead of the parents stack like rpa does. Contrary to rpa though, it does complicate runtime stack checking if you have that.

FYI at the begginng of the project, not very skilled in assembly, I was often looking at the asm code generated by gcc.
Now I will still take any advice.


I did some x64 assembler work during the last few years, so I read ABI stuff. Recently, FPC got support for vectorcall, so I had to refresh it all again. It was just a quick fire list of things that I could recall, to make sure you had heard of them.
Last edited by marcov on Dec 15, 2019 15:15, edited 2 times in total.
Xusinboy Bekchanov
Posts: 254
Joined: Jul 26, 2018 18:28

Re: Gas64 (no more use of gcc, only gas) :-)

Postby Xusinboy Bekchanov » Dec 15, 2019 14:08

One more thing: gas64 does not export dll functions
Xusinboy Bekchanov
Posts: 254
Joined: Jul 26, 2018 18:28

Re: Gas64 (no more use of gcc, only gas) :-)

Postby Xusinboy Bekchanov » Dec 15, 2019 18:27

In my new program (1.2.0) I pass this line:

Code: Select all

fFind.SetBounds fFind.Parent-> Left + fFind.Parent-> WIDTH-fFind.WIDTH - 5, fFind.Parent-> TOP + 20, fFind.WIDTH, 65


But in this procedure, ALeft gets a different value:

Code: Select all

Sub Control.SetBounds (ALeft As Integer, ATop As Integer, AWidth As Integer, AHeight As Integer)


In the official version, this is correct.
SARG
Posts: 1157
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Gas64 (no more use of gcc, only gas) :-)

Postby SARG » Dec 16, 2019 17:06

Hi all,

I forgot to mention that all is based on 1.07 version.

@marcov
For Linux I still have to think how to do with the new CVA_xx macros. Maybe the equivalent way used for windows.

As I said several times about debugging, when gcc is used there are some issues :
- baseindex of array is zero in C and no data is transmitted to the debugger if the baseindex is different ( myarray(2 to 4) is changed in myarray(0 to 2) with obviously all the index calculations correctly done.
- loops could also be changed making impossible the tracking of the execution linked with the source code.
My goal is to add stabs data (like gas32) with addresses extended to 64bit and so it will be possible to use fbdebugger like with gas32.

Concerning Red Zone that is also what I have read. It will not be added.


@Xusinboy
- Issue about dll fixed. I learn something every day :-) (section .drectve containing names for exported objects)
- When it will become an official feature ? I don't know. First a complete (linux) and clean code then it's up to coderjeff.

- About speed there are 2 aspects : time of compilation and time of execution.
Compilation time will not be as good as with gas. Unfortunately code optimization is time consuming because is done with each line of asm code by analyzing it with the previous. For small piece of code no real difference.
A small example where 2 lines have been replaced by one.

Code: Select all

#O4lea r11, -120[rbp]
#O4mov QWORD PTR [r11], 0
mov QWORD PTR -120[rbp], 0 #Optim 4


Execution time should be equivalent between exes generated with gcc and gas64. However it's not possible to compete if a Ox(O2,O3,OF) parameter is used.

- About the last issue in your program
As I'm not comfortable with OOP it's a real tresor hunt to find my way
type frmfind extends form
type form extends containercontrol
type containercontrol extends control
type control extends component
type component extends my.sys.object
And more I'm looking for fields in type but they are properties.

I'm going to try to write a short code for testing however if you could post one it will help me.


A new version http://users.freebasic-portal.de/sarg/f ... _short.zip with the fix for dll issue and this:
Info added in the header of the compiler : Backend used for compiling fbc (gcc or gas64) and also that gas64 is forced as backend.

    FreeBASIC Compiler - Version 1.07.0 (2019-12-15), built for win64 (64bit), used backend gas64 <--------------
    Copyright (C) 2004-2019 The FreeBASIC development team.

    *** Current backend forced to gas64 *** <-------------------

    standalone
    target: win64, x86-64, 64bit
    compiling: hello_utf8.bas -o hello_utf8.a64 (main module)
SARG
Posts: 1157
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Gas64 (no more use of gcc, only gas) :-)

Postby SARG » Dec 17, 2019 1:07

@Xusinboy

Last bug fixed so no need your short code. Time to go to bed so new version tomorrow.
SARG
Posts: 1157
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Gas64 (no more use of gcc, only gas) :-)

Postby SARG » Dec 17, 2019 18:24

Xusinboy Bekchanov
Posts: 254
Joined: Jul 26, 2018 18:28

Re: Gas64 (no more use of gcc, only gas) :-)

Postby Xusinboy Bekchanov » Dec 17, 2019 19:34

Now everything works.

Every time I download, "Nod32 Antivirus 8" stops the download. I temporarily disable the antivirus and load it. When scanning with the same antivirus, it will not find anything. And virustotal.com will not find anything either.
SARG
Posts: 1157
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Gas64 (no more use of gcc, only gas) :-)

Postby SARG » Dec 17, 2019 20:29

Xusinboy Bekchanov wrote:Now everything works.
Good thing. I was scary to spend a lot of time in your code ;-)
To fix I only have added one small line . I do things too complicated for my little brain :-)

Xusinboy Bekchanov wrote:Every time I download, "Nod32 Antivirus 8" stops the download. I temporarily disable the antivirus and load it. When scanning with the same antivirus, it will not find anything. And virustotal.com will not find anything either.
Exes generated by fbc are often seen like false positives as recently discussed in an other thread. And Antiviruses don't like downloading of exes "hidden" in a zip file. When donwloaded the files are checked and happily nothing is found. Sorry for this drawback.
Xusinboy Bekchanov
Posts: 254
Joined: Jul 26, 2018 18:28

Re: Gas64 (no more use of gcc, only gas) :-)

Postby Xusinboy Bekchanov » Dec 18, 2019 5:29

Thanks you, then we are waiting for the gen gas for Linux.
coderJeff
Site Admin
Posts: 3342
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Gas64 (no more use of gcc, only gas) :-)

Postby coderJeff » Dec 31, 2019 14:22

SARG wrote:@coderjeff
Could you please try on your side the test suite. By the way, very impressive.


Hi, SARG. Looking pretty good. I missed the part about based on 1.07, and I have tested on most recent fbc/master. I made some changes to run the fbc test suite to completion (using the normal makefile process). Here's summary of results:

Code: Select all

SUMMARY (brief: failures only)

 Asserts    Passed    Failed  Suite                                      Tests
--------  --------  --------  --------------------------------------  --------
     382       369        13  fbc_tests.structs.padding                     10
      30        29         1  fbc_tests.structs.anon_intrinsic               1
     576       573         3  fbc_tests.string_.trigraphs                    1
       9         6         3  fbc_tests.string_.initialization               3
     364       238       126  fbc_tests.string_.escape                      15
      18        17         1  fbc_tests.numbers.longints                     3
  290934    269385     21549  fbc_tests.numbers.cast_f2ll                    2
       2         0         2  fbc_tests.functions.va_tmpstring_gcc           1
       8         6         2  fbc_tests.functions.va_strings_gcc             1
     174       173         1  fbc_tests.functions.return_byref              26
      39        35         4  fbc_tests.file_.input_                         8
    2756      2750         6  fbc_tests.expressions.iif_                    17
      23        21         2  fbc_tests.expressions.idiv_by_float            1
     428       346        82  fbc_tests.expressions.ftoi                     3
     196       195         1  fbc_tests.dim_.byref_                          7
     111       110         1  fbc_tests.datetime.testtime                    2
     154       138        16  fbc_tests.compound.select_                     9
--------  --------  --------  --------------------------------------  --------
  631502    609689     21813  Total                                       1914


My local commit history on your gas64 branch is a little messy, so I can't tell in all cases if it was your bug, or my bad rebase. I'll review the changes I made again and post.

Of significance:
1) fbc is cross compiler, so __FB_LINUX__ or __FB_WIN32__ or SSE 4.1 detection within fbc compiler itself can only be used to detect suitable defaults. Otherwise the backend emitter should use the env.clopt.target (and other options), to determine code generation.
2) the emitter doesn't come alive until _emitBegin() is called, and must completely die in _emitEnd(). Should not expect to carry emitter information forward from one module compile to next module compile. For example, in the version I had, the 'ctx.head_txt' was not cleared so caused assembly error in second module to compile.
3) my CPU doesn't support sse 4.1 and there were some unguarded 'roundss' and 'roundsd' instructions. (I called no_roundsd instead).
4) manipulating the mxcsr register in a global variable seems like would not be thread safe.
5) Symbols cannot be emitted based on their ALIAS only. For example local scope statics do not have a mangled public name and must get a unique identifier otherwise will get duplicate definitions in the .a64 file. I removed all of your custom symbol mangling and call only 'symbGetMangledName()'. The llvm mangling almost works as-is, except for GAS64 need to mangle statics to a unique id.

Of personal preference:
- I changed the default to -gen gas64 for windows rather than forcing the options. That way I can still control code gen from the command line for other targets using same built fbc exe.

For CVA_* on Linux x86-64, see https://www.uclibc.org/docs/psABI-x86_64.pdf starting around pg 50. The needed structure is already built in in to the compiler (see 'FB_CVA_LIST_BUILTIN_C_STD' and 'symbKeywordTypeInit()'). Rather than one saved pointer to fetch the next arg (like on windows and linux x86), the structure has indexes in to the register save area and stack areas to track next argument.

Code: Select all

   ''            type __va_list_tag alias "__va_list_tag"
   ''               as ulong gp_offset
   ''               as ulong fp_offset
   ''               as any ptr overflow_arg_area
   ''               as any ptr reg_save_area
   ''            end type 
coderJeff
Site Admin
Posts: 3342
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Gas64 (no more use of gcc, only gas) :-)

Postby coderJeff » Jan 03, 2020 21:09

hi SARG, I posted your code on top of current fbc/master (1.08.0) plus my changes at SARG-gas64. There are some compiler warnings (if using -w pedantic), and at least one error when building a release version of fbc because internal typeDumpToStr() is only available when building the debug version of fbc.

Return to “Projects”

Who is online

Users browsing this forum: No registered users and 10 guests