Is FreeBasic still continued to develop?

John Spikowski · Post by **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.

Post by **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 · Post by **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 · Post by **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 · Post by **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 · Post by **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 · Post by **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 · Post by **Lachie Dazdarian** » Jan 25, 2010 9:50

aurelVZAB, you can't fight The Beast.

Landeel · Post by **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-julia ... cc-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 · Post by **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 · Post by **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 · Post by **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 · Post by **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 · Post by **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 · Post by **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.

Is FreeBasic still continued to develop?

Sizeof() bug inside ASM block