Is FreeBasic still continued to develop?

[Prime Productions]

Can you code using pure ASM as well?

Assuredly. I am a ASM programmer and FreeBASIC, my all time two favourite languages. I am writing an OS in NASM.

Just as long as it never is a to C compiler, I'm not complaining.

Yes, and Lachie, what is The Beast? cha0s, C, or a character in a fairy tale?

David

[marcov]

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.

This is not true. The very first C++ compiler from Bjarne(Cfront) followed this track afaik mostly to demonstrate C++' backwards compatibility to C, but all serious C++ compilers typically generate code directly. (and that includes GCC)

But don't worry, C++ compilers are already slow enough without such drastic steps :-)

[John Spikowski]

Can we assume that Victor is coding to ANSI C standards for the assembler engine?

[marcov]

Can we assume that Victor is coding to ANSI C standards for the assembler engine?

Who cares? MSVC and GCC is enough. (gcc and its related toolchain is nearly worthless on windows)

[AGS]

One of my favorite routines in the C emitter related code (ir-hlc.bas):

Code: Select all

'':::::
private sub _emitSpillRegs _
	( _
	)

	/' do nothing '/

end sub

Now that's the kind of code even I can understand. Eleven routines in the emitter start with the words /' do nothing '/.

This piece of code is nice too:

Code: Select all

#ifdef TARGET_X86
	hWriteLine( "static inline " & rtype_str & " fb_" & fname &  " ( " & ptype_str & !" value ) {\n" & _
				!"\tvolatile " & rtype_str & !" result;\n" & _
				!"\t__asm__ (\n" & _
				!"\t\t\"fld" & ptype_suffix & !" %1;\"\n" & _
				!"\t\t\"fistp" & rtype_suffix & !" %0;\"\n" & _
				!"\t\t:\"=m\" (result)\n" & _
				!"\t\t:\"m\" (value)\n" & _
				!"\t);\n" & _
				!"\treturn result;\n" & _
				!"}", FALSE )
#else
	#error !!!WRITEME!!!
#endif

Mind the !!!WRITEME!!!.

Someone said something about the kind of C code getting emitted. The part of the code starting with __asm__ looks like GCC code to me so it's not Ansci C and not C99 (it's GCC).

Another routine contains this statement:

Code: Select all

hWriteLine( "goto *" & hVregToStr( v1 ) )

Computed goto (goto *) is a GCC extension (it's not part of C99). But you will not hear me complaining (computed goto seems like a good idea).

By far my MOST favorite part of the C emitter thus far...

Code: Select all

'' HACK: reusing the accessed flag (that's used by variables only)

If there is one thing I love to find in source code it's hacks.

Source code without hacks is no good. Thus far only one piece of source code in the C emitter has been marked hack. That's a bit disappointing to me. The final version of the emitter should contain at least ten hacks :)

I hope v1ctor will be able to finish the C emitter.

[John Spikowski]

It would be interesting to compare the C code generated by the FreeBASIC emitter to what BCX and BaCon is generating.

Anyone want to contribute a test program that would compile on all versions of Basic?

[relsoft]

It would be interesting to compare the C code generated by the FreeBASIC emitter to what BCX and BaCon is generating.

Anyone want to contribute a test program that would compile on all versions of Basic?

It's not the code generation that matters most. It's the final executable speed. Hence the maxim "let GCC do most of the hard work in optimizing code."

[DOS386]

Can you code using pure ASM as well?

Sure ;-)

Also because we won't include gcc in Windows and DOS (too big package, IMO), so making it obligatory to users to first download and install MinGW and to configure it (set env. variable) would turn new users away from FB.

Right ;-) ... I wouldn't touch FB if I had to set up DGJPP before being able to use FB at all.

But other questions:

1. Next release ... any guess about date and number ?

2. Anyone knows whether DrV or CoderJeff intend to return ?

3. Any chance to get the GfxLib bugs (DOS and Win32) fixed ?

[John Spikowski]

It's not the code generation that matters most. It's the final executable speed. Hence the maxim "let GCC do most of the hard work in optimizing code."

Correct me if I'm wrong but I think the C emitter is being created to make FreeBASIC more portable. Any other benefits are icing on the cake.

[counting_pine]

Could it be that you last changes broke the existing GAS generator?

Apparently this one's my fault:
http://fbc.svn.sourceforge.net/viewvc/f ... ision=5272

I can't see how though! Will have to give the diff a good look over...

[marcov]

It would be interesting to compare the C code generated by the FreeBASIC emitter to what BCX and BaCon is generating.

Anyone want to contribute a test program that would compile on all versions of Basic?

It's not the code generation that matters most. It's the final executable speed. Hence the maxim "let GCC do most of the hard work in optimizing code."

It's not the speed that matters, as long as it is enough. It is about getting the job done, and not get hung up in details.

Moreover, unlocking maximum GCC speed also needs additional effort. Just like there is a difference between generating asm and fast asm, there is als a difference between generating slow C and fast C.

[ffweb]

From Wikipedia I read:

FreeBASIC continues to make development progress toward its goal of being a GCC front-end

http://en.wikipedia.org/wiki/Freebasic

So I think that the on-going evolution is right in the stated direction. "Front-end" doesn't mean "translator".

[TheMG]

Well, front end would usually mean that it gives GCC something that the backend (code generator and optimizer) can handle, which would be some form of IR. This was the original intention, as far as I know.

However GIMPLE (and/or the general structure of GCC) was deemed to messy/difficult to work with, so a C emitter plan started. While this doesn't make much difference in terms of outputted binaries, it is slightly slower and technically means FreeBASIC won't be a front end to GCC.

[Dinosaur]

Hi all

After reading this whole post, I am confused as to what all this means for the average user of FB.

1. Does this become a separate compiler, and if so, can it still be used as normal, and thus ignore the fact that it emits C ? (I know not human readable)
I realise that the installation of additional components may be needed.

2. Will the Windows and Dos compilers suffer from lack of development, because all effort will be on the other.?

I dont really care how the compiler is made,(nor do I understand it) I just need to know that it can be used for my purpose.

Regards

[Mysoft]

1. Does this become a separate compiler, and if so, can it still be used as normal, and thus ignore the fact that it emits C ? (I know not human readable)
I realise that the installation of additional components may be needed.

no its the same compiler... the only difference is the switch -gen GCC that is used to emit C code instead of ASM.

2. Will the Windows and Dos compilers suffer from lack of development, because all effort will be on the other.?

well the DOS version have chance of always lack development, but there's a slight chance that it's already working using DJCPP. and despite they might erronously! say... windows is generaly one step ahead even in bugfixes, also they only meant that its "easier (LOL)" to get it working on linux due the fact GCC can be installed with some command lines only...