native At&t Assembly emitter

[Julcar]

Hi guys,

recently I had a failed journey in the aim of Emitting Assembly code with FB but using TCC building tools for generating executables, until I figured out :shame: the incompatibility between both syntax, Intel in FBC's side and AT&T on the TCC's side.

After exploring in the land of the ASM to S converters and translators, and failing again and again, I started wondering: is possible to FBC emit AT&T syntax directly? Maybe I am requesting something impossible, but let me know what are the possibilities.

Thanks.

[MrSwiss]

I started wondering: is possible to FBC emit AT&T syntax directly? Maybe I am requesting something impossible, but let me know what are the possibilities.

Since you seem to be the only one person here, that wants to use TCC (for whatever reason),
it is highly unlikely, that your idea is going to be greeted with approval, by a mayority here.
We use FBC as it's supposed to be used: for the whole binary build ... (.exe/.a/.so or .dll).

From my point of view, it's a pointless excercise, that is good for you alone, only.
(I'm not certain that you understand, the amount of work you're asking for, that such a change
or option, whould undoubtedly require.)

[SARG]

Some years ago there was an attempt to generate asm with ATT syntax : viewtopic.php?f=17&t=16742

But the project is dead : https://sourceforge.net/p/fbc/patches/22/

A translator is possible, see AT&T Syntax versus Intel Syntax : http://staffwww.fullcoll.edu/aclifton/c ... yntax.html
However what is really the interest using TCC instead GAS ?

[systemctl]

Some years ago there was an attempt to generate asm with ATT syntax : viewtopic.php?f=17&t=16742

But the project is dead : https://sourceforge.net/p/fbc/patches/22/

A translator is possible, see AT&T Syntax versus Intel Syntax : http://staffwww.fullcoll.edu/aclifton/c ... yntax.html
However what is really the interest using TCC instead GAS ?

When you don't care about performance...

TCC is small and GCC is big? TCC is very fast and GCC is very slow? On Linux it's barely noticeable, but on Windows, it does.

BTW, the more compiler supported, the better. I want LLVM Clang to be supported compiler, though, not TCC. Note: I mean supporting compile emitted C code with Clang, not emit LLVM IR (already done).

p/s: Most of the time, GNU Binutils (ld, as, objdump,...) is get as part of the whole GCC suite on Windows, so it's bloated in size. As I know it's no way to get latest binutils separated from GCC on Windows other than installing Cygwin or MSYS2, which is another beast in size. Correct me if I'm wrong. Thanks.

[SARG]

@systemctl
Sorry for your eyes.
However you should know what the OP wants to do and read carefully what I wrote before a such reply. I hope Julcar will reply.

Julcar wants to generate directly asm code with ATT syntax then use TCC to compile the asm file.

So my question what is the interest not using GAS ? GCC is not involved (no C used) only the assembler and the linker. They are small and very fast.
And both are provided with FBC (at least under Windows).

[marcov]

me if I'm wrong. Thanks.

1 minute search:
https://sourceforge.net/projects/mingw/ ... /binutils/

Please research your posts and statements a bit more.

[Julcar]

@systemctl
Sorry for your eyes.
However you should know what the OP wants to do and read carefully what I wrote before a such reply. I hope Julcar will reply.

Julcar wants to generate directly asm code with ATT syntax then use TCC to compile the asm file.

So my question what is the interest not using GAS ? GCC is not involved (no C used) only the assembler and the linker. They are small and very fast.
And both are provided with FBC (at least under Windows).

I am working on embedded systems, for those systems with tiny amounts of memory and processor cycles TCC is great, mainly because its linker is very smart when linking to system dlls instead of static libraries, which reduce the executable size and hence less bytes loading to memory, maybe I ain't dig more onto FBC linker options, but AFAIK the FBC compiler is packaged itself with a bunch of static libraries (in my current embed workspace I just uncompressed binaries and includes and I am failing when compiling because the linker is unable to find these .a files)

[dodicat]

I find gcc much faster than tcc.
Try this with -O2 in gcc and compare a compile with tcc.exe.
isprime.c

Code: Select all

 




#include<math.h>
#include<stdio.h>
#include<stdlib.h>


int isprime(unsigned long long n)
{		
 if (n == 2 | n == 3)
{
  return (-1);
}

  if ( n % 2 == 0)
  {
  return(0);
}
  
   if ( (n % 3)== 0)
   {
  return(0);
}

 unsigned long long limit=(unsigned long long) sqrt(n)+1;
 unsigned long long i;
 
  for (  i = 6  ; i < limit ; i = i + 6 )
  {
  	
        if (n % (i-1) == 0)
		{
        return(0);
        }
         if (n % (i+1) == 0)
         {
        return(0);
          }
    
    }
  return(-1);	
}



int main(void)
{
	unsigned long long x;
	unsigned long long min=100000000000000000ull;
	unsigned long long max=100000000000000900ull;
	
printf("Range from   %d " , min ,"  to %d " , max," \n");
printf("  to %d \n\n" , max);

    	for (x=min;x<max;x++)
	{
		if (isprime(x))
		{
printf("Prime   %d\n",x);
	}
}
	system("pause");
} 

The whole minGW can be downloaded from the freebasic news section.
viewtopic.php?f=1&p=264580#p264580
All under
The MinGW-w64 toolchains used . . .

various 32 and 64 bit gcc versions.
Each package about 500 mb when expanded.
You can choose one and make sure it's bin folder in on path and you can run gcc, g++ and all the other bits (gendef, strip, dlltool, make . . .) anywhere.
No need for fancy installations at all.

[Julcar]

This is not about the C language at all, I want to code in FreeBasic, but instead of compiling with binutils, I want to use the integrated tools in TCC (assembler and linker), the handicap is the syntax used, FreeBasic emits intel_syntax but TCC expects AT&T syntax, is not so complicated to understand.

Why I want to use TCC?

• I work on embeded systems, with no more than 128mb of RAM, 4GB of Hard disk, and 1 cpu core of 1ghz
• I've made tests with binaries generated by both Binutils and TCC, and second ones are enough faster (compiling and running) to worth the effort.
• as the reduced disk space, TCC by default links binaries with system's shared libraries, whereas Binutils preffers to link to static ones, increasing the final binary size (and hence more RAM is needed to load the binary)
• a normal installation of FreeBASIC requires 107mb of disk (libraries and includes), a normal TCC setup requires only 5mb, please take account that I need to do the compilation (and sometimes the coding itself) on the same embeded machine.

For me it's a lot of reasons to look for a proper solution to my problem.

[srvaldez]

hello Julcar
try
fbc -rr -gen gcc -asm att your_program.bas
you will get as output
your_program.asm in At&t Assembly syntax
[edit]
I forgot, needs gcc

[Julcar]

hello Julcar
try
fbc -rr -gen gcc -asm att your_program.bas
you will get as output
your_program.asm in At&t Assembly syntax
[edit]
I forgot, needs gcc

Seems promising

[dodicat]

I remember you using this switch before srvaldez.
I hope Julcar can use it.
My above test was in response this statement by systemctl
"TCC is small and GCC is big? TCC is very fast and GCC is very slow? On Linux it's barely noticeable, but on Windows, it does."
When in fact the stripped .exe files are about the same size and the gcc .exe is much faster (for this particular task) if optimised -O2.

[Julcar]

I remember you using this switch before srvaldez.
I hope Julcar can use it.
My above test was in response this statement by systemctl
"TCC is small and GCC is big? TCC is very fast and GCC is very slow? On Linux it's barely noticeable, but on Windows, it does."
When in fact the stripped .exe files are about the same size and the gcc .exe is much faster (for this particular task) if optimised -O2.

I've seen some examples but never used it before AFAIK

[marcov]

[*] I work on embeded systems, with no more than 128mb of RAM, 4GB of Hard disk, and 1 cpu core of 1ghz

(that's not an embedded system but a 1998 workstation)

[Julcar]

[*] I work on embeded systems, with no more than 128mb of RAM, 4GB of Hard disk, and 1 cpu core of 1ghz

(that's not an embedded system but a 1998 workstation)

The world of the barebones is very diverse, here is an approach of my current work environment: https://www.ints.com/products/lubesoft/ ... hin-client