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

[coderJeff]

@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]

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]

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]

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]

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]

Hi all,

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.

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.

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]

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]

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]

...
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]

@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]

@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]

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]

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]

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]

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.