Is FreeBasic still continued to develop?

For other topics related to the FreeBASIC project or its community.
John Spikowski
Posts: 453
Joined: Dec 24, 2005 2:32
Location: WA - USA
Contact:

Postby John Spikowski » Jan 25, 2010 1:23

dumb/lazy translator = One to one BASIC line to C equivalent. No higher level code optimizations, code constructs, or implementations.


If you write the Basic to C translator correctly, the translator is where your optimizations should occur.

I think what Victor is trying to accomplish is retain what is still useful in classic FB and replace the assembler with gcc. This makes FreeBASIC easier to port once it can convert itself to C. When that happens it will make FB much easier for others to contribute.
v1ctor
Site Admin
Posts: 3801
Joined: May 27, 2005 8:08
Location: SP / Bra[s]il
Contact:

Postby v1ctor » Jan 25, 2010 1:59

The C code generated isn't for human consumption, it won't ever be approved by FDA.

SARG: I couldn't reproduce the error. That code won't generate any output unless the struct is referenced - even so i couldn't get that error to repeat (using -g, -exx or not).

Sure, if you want to create a thread to report the issues, go for it. Much simpler to me to find the problems - but please, try to find what is going wrong and just post a snippet to reproduce the error, not a full application that isn't compiling.
Prime Productions
Posts: 147
Joined: May 24, 2009 23:13
Location: Texas, United States, Planet Earth
Contact:

Postby Prime Productions » Jan 25, 2010 2:06

I don't like the idea of making FreeBASIC a BASIC to C translator. Might as well use C.
John Spikowski
Posts: 453
Joined: Dec 24, 2005 2:32
Location: WA - USA
Contact:

Postby John Spikowski » Jan 25, 2010 2:26

The C code generated isn't for human consumption, it won't ever be approved by FDA.


I guess we will have to file for a EUA for your life saving language. ;-)
cha0s
Site Admin
Posts: 5317
Joined: May 27, 2005 6:42
Location: Illinois
Contact:

Postby cha0s » Jan 25, 2010 3:20

Prime Productions wrote:I don't like the idea of making FreeBASIC a BASIC to C translator. Might as well use C.


Well, you can hand-code ASM (FB is currently a BASIC to ASM translator) while the rest of us program in high-level languages of our choice. ;p
angros47
Posts: 1673
Joined: Jun 21, 2005 19:04

Postby angros47 » Jan 25, 2010 7:44

As far as I know, many C++ compilers (even GCC, I think) actually convert c++ to c, then compile c. If so, FB would simply do the same thing of many c++ compilers.
aurelVZAB
Posts: 342
Joined: Jul 02, 2008 14:55
Location: Croatia
Contact:

Postby aurelVZAB » Jan 25, 2010 9:37

I agree with Prime Production i also dont like idea that FB translate to C.
If Fb currently generate asm code that is better becose is for sure faster.
And many other compilers generate asm code not C code.
Lachie Dazdarian
Posts: 2338
Joined: May 31, 2005 9:59
Location: Croatia
Contact:

Postby Lachie Dazdarian » Jan 25, 2010 9:50

aurelVZAB, you can't fight The Beast.
Landeel
Posts: 747
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Postby Landeel » Jan 25, 2010 10:26

I agree with Prime Production i also dont like idea that FB translate to C.
If Fb currently generate asm code that is better becose is for sure faster.
And many other compilers generate asm code not C code.


v1ctor said:
Just to make it clear, FB won't just translate BASIC to C. Gcc is used as a high-level assembler, not a single C header is ever included


emitter <> translator

As stated many many many times already, this is NOT a FreeBASIC to C translator. Emitted C code is NOT human-readable, as with the currrent GAS (ASM) emitter. NOT a translator.

The GAS emitter is for x86 only. What about other platforms? x86_64? Should FreeBASIC be stuck on x86 forever?

And what about taking advantage of the already existing gcc optimizations? You'd better benchmark it before telling what is faster.

http://www.freebasic.net/temp/rel-juliarings-gas.exe

http://www.freebasic.net/temp/rel-juliarings-gcc.exe

http://www.freebasic.net/temp/rel-juliarings-gcc-sse.exe

I did, and the C version is faster. In this particular example, C with Pentium 4 + SSE is about 3 times faster than GAS in my system.


I don't like the idea of making FreeBASIC a BASIC to C translator. Might as well use C.


v1ctor said:
Just to make it clear, FB won't just translate BASIC to C. Gcc is used as a high-level assembler, not a single C header is ever included


Can you code using pure ASM as well? Again, NOT a translator.

Sorry, but I guess you guys have no idea what you're complaining about.
jcfuller
Posts: 324
Joined: Sep 03, 2007 18:40

Postby jcfuller » Jan 25, 2010 11:12

SARG wrote:
By the way, is it possible to use (easily) Pelles C or an other compiler ?

And why not open a special topic (sticky) on the gcc emitter.


If we could use Pelles C it might be possible to create 64bit apps?



James
MichaelW
Posts: 3500
Joined: May 16, 2006 22:34
Location: USA

Postby MichaelW » Jan 25, 2010 11:18

aurelVZAB wrote:If Fb currently generate asm code that is better becose is for sure faster.

The generated assembly code is likely to be significantly slower than compiler-optimized (O2) C code would be. It’s not that FBC generates bad code, it’s that the good C compilers generate very good code, thanks to years of effort by more or less large teams of programmers.
segin
Posts: 126
Joined: Dec 27, 2005 5:22
Contact:

Postby segin » Jan 25, 2010 11:41

jcfuller wrote:If we could use Pelles C it might be possible to create 64bit apps?

James


Except that GCC already does 64bit already, even on Windows.

Secondly, unless Pelles C and it's associated toolchain use object files compatible with GCC, the whole thing is utterly useless.
jcfuller
Posts: 324
Joined: Sep 03, 2007 18:40

Postby jcfuller » Jan 25, 2010 11:53

segin wrote:
jcfuller wrote:If we could use Pelles C it might be possible to create 64bit apps?

James


Except that GCC already does 64bit already, even on Windows.

Secondly, unless Pelles C and it's associated toolchain use object files compatible with GCC, the whole thing is utterly useless.


I may be mistaken but my understanding is there is not an official GNU Windows 64bit port, only a beta fork??

James
aurelVZAB
Posts: 342
Joined: Jul 02, 2008 14:55
Location: Croatia
Contact:

Postby aurelVZAB » Jan 25, 2010 13:22

Lachie....

""aurelVZAB, you can't fight The Beast.""

HEH what Beast! you mean - C?
I dont wana fight with nothing i just say....heh
smagin
Posts: 136
Joined: Jun 09, 2005 16:46
Location: Russia, Belgorod

Sizeof() bug inside ASM block

Postby smagin » Jan 25, 2010 16:13

Hi, Victor, a question to you.

Could it be that you last changes broke the existing GAS generator? I have a piece of code here which produces weird results:

Code: Select all

type c_type
    i as integer
    j as integer
end type

#define SOMENUMBER 5

asm
    mov ecx, sizeof(c_type)*(SOMENUMBER-2)
    xor eax, eax
   
    mov ecx, (SOMENUMBER-2)*sizeof(c_type)
    xor eax, eax
   
end asm


And the asm emitted:

Code: Select all

   .intel_syntax noprefix

   #321.bas' compilation started at 19:08:51 (FreeBASIC v0.21.0b)

.section .text
.balign 16

.globl _main
_main:
push ebp
mov ebp, esp
and esp, 0xFFFFFFF0
sub esp, 4
push ebx
push esi
push edi
mov dword ptr [ebp-4], 0
call ___main
push 0
push dword ptr [ebp+12]
push dword ptr [ebp+8]
call _fb_Init@12
.Lt_0002:
mov ecx, 8(5-2) ; <<<<< here !!!
xor eax, eax
mov ecx, (5-2)*8    xor eax, eax ; <<<<< SIC! two mnemonics on the same line
.Lt_0003:
push 0
call _fb_End@4
mov eax, dword ptr [ebp-4]
pop edi
pop esi
pop ebx
mov esp, ebp
pop ebp
ret
   #321.bas' compilation took 0.0002603080165417548 secs


I have an impression that sizeof intrinsic macro is being incorrecly parsed inside asm blocks.

The last SVN build 01-24-10 from Imortis is used. Prevoious build of December compiled this correctly.

Thanks.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 5 guests