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

User projects written in or related to FreeBASIC.
coderJeff
Site Admin
Posts: 3170
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

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

Postby coderJeff » Jan 12, 2020 17:15

SARG wrote:@coderJeff
Is the release date for 1.08 already planned ?


"planned" is a strong word. I have in my mind to aim for 2020-March, no promises. So far this winter, work has been busy. If obligations at work slow down a bit, it's more likely to happen when I want it to happen, otherwise later.
SARG
Posts: 1033
Joined: May 27, 2005 7:15
Location: FRANCE

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

Postby SARG » Jan 14, 2020 14:52

Hi coderJeff,

Thank you for your reply and the time you spend for all of us. No problem concerning the date :-).

Now I use Git locally and several commits are ready. In fact I have splitted, as best I could, the last modifications based on my daily saves.
how do I proceed for the suite ? I can make available patchs.

Good luck for work.
coderJeff
Site Admin
Posts: 3170
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

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

Postby coderJeff » Jan 16, 2020 3:03

Hi SARG,

Nice! You using git to track your changes is super easy for me to work with. If you want to make it really easy for me and other git users, just push your active branch to public. Very easy if you register on github.

For example, assuming that you have set up a github account with your remote called 'SARG', and you have an active branch called 'gas64':
$ git push SARG gas64

This will make your changes available on github. On my end, I then do:
$ git remote add SARG https://github.com/SARG/fbc
$ git fetch SARG
$ git branch gas64 SARG/gas64
$ git checkout gas64

This allows me to compile your changes, even rebase or merge them in with other changes and test it out.

I am not sure what you are asking about the test suite. In general, you should try and run the test suite locally to ensure all the tests pass. Or if the tests don't pass, at least understand why, and you can possibly block out the failing tests with a '#if ENABLE_CHECK_BUGS' block, if it is impossible to fix the bugs.

Maybe if you have a specific question about the test suite (it requires 'make' and a few other unix-y tools like 'sed', 'xargs', etc to run) I could answer to that.
anonymous1337
Posts: 5494
Joined: Sep 12, 2005 20:06
Location: California

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

Postby anonymous1337 » Jan 16, 2020 6:37

Hey sorry if this has already been answered, but the thread is very long.

Can someone explain what this thread is about to me?

Does "No GCC, only GAS" mean FB no longer has to be compiled to C/C++ first in order to be processed by GCC?

Instead, FB source would compile straight to assembler in GAS format?
Xusinboy Bekchanov
Posts: 206
Joined: Jul 26, 2018 18:28

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

Postby Xusinboy Bekchanov » Jan 16, 2020 10:09

anonymous1337 wrote:Does "No GCC, only GAS" mean FB no longer has to be compiled to C/C++ first in order to be processed by GCC?

Instead, FB source would compile straight to assembler in GAS format?

Yes.
SARG
Posts: 1033
Joined: May 27, 2005 7:15
Location: FRANCE

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

Postby SARG » Jan 16, 2020 22:58

Hi all,

coderJeff wrote:Nice! You using git to track your changes is super easy for me to work with. If you want to make it really easy for me and other git users, just push your active branch to public. Very easy if you register on github.
This allows me to compile your changes, even rebase or merge them in with other changes and test it out.

The repository is created in github : https://github.com/SARG-FB/fbc/tree/SARG-january
I'm not comfortable with Git and I did some mistakes : so no branch. I'll try to fix that. However all the last changes are there.

coderJeff wrote:I am not sure what you are asking about the test suite. In general, you should try and run the test suite locally to ensure all the tests pass. Or if the tests don't pass, at least understand why, and you can possibly block out the failing tests with a '#if ENABLE_CHECK_BUGS' block, if it is impossible to fix the bugs.

Maybe if you have a specific question about the test suite (it requires 'make' and a few other unix-y tools like 'sed', 'xargs', etc to run) I could answer to that.

It was not concerning the test suite, just how to proceed after creating the local repository and you have answered.

anonymous1337 wrote:Does "No GCC, only GAS" mean FB no longer has to be compiled to C/C++ first in order to be processed by GCC?
Instead, FB source would compile straight to assembler in GAS format?

As already replied by Xusinboy Bekchanov, yes.
This version of the compiler produces by default an assembly file (for now with extension a64 to distinguish it from normal asm) then as.exe does the job. It's still work in progress at least to cover linux.
Maybe the thread title should be changed in something clearer. Any idea ?
Test and report issues.
srvaldez
Posts: 2327
Joined: Sep 25, 2005 21:54

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

Postby srvaldez » Jan 29, 2020 11:39

hello SARG
compiling and running the following code will crash
posted by paul doe viewtopic.php?p=268302#p268302

Code: Select all

sub _
  word( byval whatever as integer )
 
  ? whatever
end sub

/'
  Naturally, none of these work either
'/
sub _
  dword( byval whatever as integer )
 
  ? whatever
end sub

sub _
  qword( byval whatever as integer )
 
  ? whatever
end sub

dim as sub( byval as integer ) _
  wordSub => @word

wordSub( -4 ) '' <-- Crash

sleep()
SARG
Posts: 1033
Joined: May 27, 2005 7:15
Location: FRANCE

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

Postby SARG » Jan 29, 2020 18:14

HI srvaldez,

Thanks for reporting.

The issue comes from the use of the assembly 'word' as function name, changing by '_word' solves it. The address contained in wordsub is wrong so the call --> crash.
All assembly words (registers and so on) used as name could cause errors. That was partially fixed but coderjeff did some changes in mangling function. Indeed adjustments are required (error generation at compilation time, prefix / suffix added). The question is still opened, .....
paul doe
Posts: 1175
Joined: Jul 25, 2017 17:22
Location: Argentina

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

Postby paul doe » Jan 29, 2020 19:19

SARG wrote:...
All assembly words (registers and so on) used as name could cause errors. That was partially fixed but coderjeff did some changes in mangling function. Indeed adjustments are required (error generation at compilation time, prefix / suffix added). The question is still opened, .....

Yes, renaming the symbol is indeed the simplest solution, but what strikes me as strange is that fbc doesn't mangle function names in the global namespace. Perhaps there is some logic behind this, but it's good to know nonetheless (could save someone some time debugging this obscure issue). Thanks for looking at it, SARG.
SARG
Posts: 1033
Joined: May 27, 2005 7:15
Location: FRANCE

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

Postby SARG » Jan 29, 2020 20:57

@paul doe

With what versions did you get problem ?

I tried gas32 and gcc without issue. 'word ' is renamed ( __WORD@4 or _WORD).
Maybe you use gas64. In this case proc/var names are not changed.
paul doe
Posts: 1175
Joined: Jul 25, 2017 17:22
Location: Argentina

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

Postby paul doe » Jan 29, 2020 21:02

SARG wrote:@paul doe

With what versions did you get problem ?
...

The standard distro of fbc 1.07.1 for 64-bit, gcc 5.x toolchain. Both gas and gcc backends compile it but produce an executable that crashes upon calling the pointed function.
paul doe
Posts: 1175
Joined: Jul 25, 2017 17:22
Location: Argentina

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

Postby paul doe » Jan 29, 2020 21:13

This code:

Code: Select all

sub _
  word( byval whatever as integer )
 
  ? whatever
end sub

/'
  Naturally, none of these work either
'/
sub _
  dword( byval whatever as integer )
 
  ? whatever
end sub

sub _
  qword( byval whatever as integer )
 
  ? whatever
end sub

dim as sub( byval as integer ) _
  wordSub => @qword

wordSub( -4 ) '' <-- Crash

sleep()

Yields this assembly when compiled just with -console -R:

Code: Select all

   .file   "FbTemp.c"
   .intel_syntax noprefix
   .text
   .globl   WORD
   .def   WORD;   .scl   2;   .type   32;   .endef
WORD:
   push   rbp
   mov   rbp, rsp
   sub   rsp, 32
   mov   QWORD PTR 16[rbp], rcx
.L2:
   mov   r8d, 1
   mov   rdx, QWORD PTR 16[rbp]
   mov   ecx, 0
   call   fb_PrintLongint
   nop
   leave
   ret
.L3:
   .globl   DWORD
   .def   DWORD;   .scl   2;   .type   32;   .endef
DWORD:
   push   rbp
   mov   rbp, rsp
   sub   rsp, 32
   mov   QWORD PTR 16[rbp], rcx
.L5:
   mov   r8d, 1
   mov   rdx, QWORD PTR 16[rbp]
   mov   ecx, 0
   call   fb_PrintLongint
   nop
   leave
   ret
.L6:
   .globl   QWORD
   .def   QWORD;   .scl   2;   .type   32;   .endef
QWORD:
   push   rbp
   mov   rbp, rsp
   sub   rsp, 32
   mov   QWORD PTR 16[rbp], rcx
.L8:
   mov   r8d, 1
   mov   rdx, QWORD PTR 16[rbp]
   mov   ecx, 0
   call   fb_PrintLongint
   nop
   leave
   ret
.L9:
   .def   __main;   .scl   2;   .type   32;   .endef
   .globl   main
   .def   main;   .scl   2;   .type   32;   .endef
main:
   push   rbp
   mov   rbp, rsp
   sub   rsp, 48
   mov   DWORD PTR 16[rbp], ecx
   mov   QWORD PTR 24[rbp], rdx
   call   __main
   mov   DWORD PTR -12[rbp], 0
   mov   rax, QWORD PTR 24[rbp]
   mov   r8d, 0
   mov   rdx, rax
   mov   ecx, DWORD PTR 16[rbp]
   call   fb_Init
.L11:
   lea   rax, QWORD[rip]
   mov   QWORD PTR -8[rbp], rax
   mov   rax, QWORD PTR -8[rbp]
   mov   rcx, -4
   call   rax
   mov   ecx, -1
   call   fb_Sleep
.L12:
   mov   ecx, 0
   call   fb_End
   mov   eax, DWORD PTR -12[rbp]
   leave
   ret
   .ident   "GCC: (x86_64-win32-sjlj-rev0, Built by MinGW-W64 project) 5.2.0"
   .def   fb_PrintLongint;   .scl   2;   .type   32;   .endef
   .def   fb_Init;   .scl   2;   .type   32;   .endef
   .def   fb_Sleep;   .scl   2;   .type   32;   .endef
   .def   fb_End;   .scl   2;   .type   32;   .endef

Conversely, when compiled in 64-bit with -console -gen gcc -R, yields this:

Code: Select all

typedef   signed char       int8;
typedef unsigned char      uint8;
typedef   signed short      int16;
typedef unsigned short     uint16;
typedef   signed int        int32;
typedef unsigned int       uint32;
typedef   signed long long  int64;
typedef unsigned long long uint64;
typedef struct { char *data; int64 len; int64 size; } FBSTRING;
typedef int8 boolean;
typedef void (*tmp$2)( int64 );
void fb_PrintLongint( int32, int64, int32 );
void fb_Init( int32, uint8**, int32 );
void fb_End( int32 );
void fb_Sleep( int32 );
void QWORD( int64 );

void WORD( int64 WHATEVER$1 )
{
   label$2:;
   fb_PrintLongint( 0, WHATEVER$1, 1 );
   label$3:;
}

void DWORD( int64 WHATEVER$1 )
{
   label$4:;
   fb_PrintLongint( 0, WHATEVER$1, 1 );
   label$5:;
}

void QWORD( int64 WHATEVER$1 )
{
   label$6:;
   fb_PrintLongint( 0, WHATEVER$1, 1 );
   label$7:;
}

int32 main( int32 __FB_ARGC__$0, char** __FB_ARGV__$0 )
{
   int32 fb$result$0;
   __builtin_memset( &fb$result$0, 0, 4ll );
   fb_Init( __FB_ARGC__$0, (uint8**)__FB_ARGV__$0, 0 );
   label$0:;
   tmp$2 WORDSUB$0;
   WORDSUB$0 = (tmp$2)&QWORD;
   (WORDSUB$0)( -4ll );
   fb_Sleep( -1 );
   label$1:;
   fb_End( 0 );
   return fb$result$0;
}

I hadn't tested GAS64 yet, this is just with the gcc and gas backends on 1.07.1. As you can see, the names in the global namespace are not mangled. Result is the same with whatever optimization switch on gcc.
SARG
Posts: 1033
Joined: May 27, 2005 7:15
Location: FRANCE

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

Postby SARG » Jan 29, 2020 21:19

My bad, I renamed word by _word for testing gas64 and I forgot to set back the original name....

gas32 and gcc32 no issue.
gcc64 a strange behaviour. I'm looking what is happening.

Test by adding a print before the call
print "I'm here" <-- looping until crash
wordSub( -4 ) ''
paul doe
Posts: 1175
Joined: Jul 25, 2017 17:22
Location: Argentina

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

Postby paul doe » Jan 29, 2020 21:28

Indeed, it's just gcc64 that does this. Naturally, none of the other x64 ASM keywords work:

Code: Select all

sub _
  rax( byval whatever as integer )
 
  ? whatever
end sub

dim as sub( byval as integer ) _
  wordSub => @rax

wordSub( -4 ) '' <-- Crash

sleep()
SARG
Posts: 1033
Joined: May 27, 2005 7:15
Location: FRANCE

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

Postby SARG » Jan 29, 2020 21:32

I was writing when you posted.
Gas32 and gcc32 no problem unless I missed something.

The issue comes from --> lea rax, QWORD[rip]
The syntax is correct in assembly. However the address gets by lea (load address) is wrong. It's the adress in the middle of the instruction not the proc adress...... For this reason there is loop on the print command.

Currently without changing the proc name no way.

Return to “Projects”

Who is online

Users browsing this forum: No registered users and 7 guests