native At&t Assembly emitter
native At&t Assembly emitter
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.
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.
Re: native At&t Assembly emitter
Since you seem to be the only one person here, that wants to use TCC (for whatever reason),Julcar wrote: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.
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.)
Re: native At&t Assembly emitter
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 ?
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 ?
Re: native At&t Assembly emitter
When you don't care about performance...SARG wrote: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 ?
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.
Re: native At&t Assembly emitter
@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).
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).
Re: native At&t Assembly emitter
1 minute search:systemctl wrote:me if I'm wrong. Thanks.
https://sourceforge.net/projects/mingw/ ... /binutils/
Please research your posts and statements a bit more.
Re: native At&t Assembly emitter
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)SARG wrote:@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).
Re: native At&t Assembly emitter
I find gcc much faster than tcc.
Try this with -O2 in gcc and compare a compile with tcc.exe.
isprime.c
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.
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");
}
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.
Re: native At&t Assembly emitter
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?
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.
Re: native At&t Assembly emitter
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
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
Re: native At&t Assembly emitter
Seems promisingsrvaldez wrote: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
Re: native At&t Assembly emitter
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 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.
Re: native At&t Assembly emitter
I've seen some examples but never used it before AFAIKdodicat wrote: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.
Re: native At&t Assembly emitter
(that's not an embedded system but a 1998 workstation)Julcar wrote:
[*] I work on embeded systems, with no more than 128mb of RAM, 4GB of Hard disk, and 1 cpu core of 1ghz
Re: native At&t Assembly emitter
The world of the barebones is very diverse, here is an approach of my current work environment: https://www.ints.com/products/lubesoft/ ... hin-clientmarcov wrote:(that's not an embedded system but a 1998 workstation)Julcar wrote:
[*] I work on embeded systems, with no more than 128mb of RAM, 4GB of Hard disk, and 1 cpu core of 1ghz