Is FreeBasic still continued to develop?

[marcov]

btw v1ctor: if you need to test on bigendian machines or systems with alignment requirement, just yell.

Powerpc: ppc G4 OS X10.4 and ppc64 G5 OS X 10.5
Arm : pda's + sheevaplug (ARMEL)

[DOS386]

Does this become a separate compiler

apparently no

can it still be used as normal, and thus ignore the fact that it emits C ?

YES. Ignore the "-gen GCC" switch and use it as before. Ignore the minor bloat increase and the fact that it can emit also C.

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

Probably YES (especially DOS), but nobody can predict such things exactly.

BTWW, the "-gen GCC" hack opens, at least theoretically, a chance to get a WATCOM-way to 32-bit DOS apps (no DGJPP) and even a 16-bit 8086-compatible target ;-)

[John Spikowski]

I thought the goal was to compile FreeBASIC to C using the emitter and that would be the baseline moving forward. Does that make it a new compiler? I would think so.

[v1ctor]

I see no point doing that. It was hard enough writing the whole thing, imagine converting everything to another language and fixing all the mistakes the converter would make.

The gcc emitter doesn't generate human readable code - yeah, that's a feature of C, i know.

If you are going to just include a C header as-is without any processing and passing C inline blocks to the C compiler, why not making a separated module written in C? Mixing two high-level languages isn't a feature of any real-no-i'm-not-just-a-translator compiler, AFAIK.

DJGPP actually has, officially, a more up to date GCC version than MinGW, so it would be a better plataform for the gcc emitter than the latter.

[John Spikowski]

Excuse me if this sounds like stupid questions.

If I wanted to generate C code to run my FreeBASIC application on OS X, would I need to run the compiler on a currently supported platform?

What if the generated C code isn't compatible with the OS X gcc compiler?

Will there be an additional flag/argument to specify the requested target platform?

[Mysoft]

while the C emitter can't compile fbc itself yeah...
and after that you will also need GCC... as well if isnt x86 there are currently some asm inlines on the C source that would need to be modified
and finally... a port of the rt,[gfx] lib is needed...

[TheMG]

If I wanted to generate C code to run my FreeBASIC application on OS X, would I need to run the compiler on a currently supported platform?

Hypothetically, if a mac port was created, the original port of FBC would be cross compiled (producing the mac binary under windows with the windows binary). Currently there is a command to add more cross compile options that you can select using autoconf. I've never used this and I don't know how well it works, and what else is required.

However, if a mac was port was created there would be an official mac binary available anyway.

What if the generated C code isn't compatible with the OS X gcc compiler?

Will there be an additional flag/argument to specify the requested target platform?

There already is, "-target <name>". The possible cross compilation targets are set as I described above. This will make sure that the generated code will be compatible for that hosts version of AS/GCC.

[Mike Trader]

V1ctor,

Fantastic work... no that didn't quite cover it..

You continue to move this language forward at a speed that even outpaces languages for sale like VB+ (powerlessbasic).

I can't Imagine the amount of effort it takes to do all this. It is easy for us to nitpick your choices and find flaws, but I am impressed with the dignity and honesty of your replies (unlike other vendors who throw anger tantrums, delete threads and ban people)

Your effort does not go un-noticed and while we would all like more more more, I just wanted to take a moment to tell you how much I respect you and your work.

a thousand thank you's... thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you....

[relsoft]

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.

Your original question has nothing to do with portability. You wanted to compare code gen.

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?

[creek23]

what's the commotion here?

oh.

v1ctor's back!

w00t!

If the C emitter is not meant for portability, then what is it for?!?

I was hoping I could start writing GP32/Dingoo (or perhaps PSP!) applications written in FB. :(

[John Spikowski]

Your original question has nothing to do with portability. You wanted to compare code gen.

Sorry, I didn't realize I exceeded my question limit for the month.

[marcov]

If I wanted to generate C code to run my FreeBASIC application on OS X, would I need to run the compiler on a currently supported platform?

Hypothetically, if a mac port was created, the original port of FBC would be cross compiled (producing the mac binary under windows with the windows binary).

I assume you mean generating gcc source, and then compile/link that on Mac?

if not I'm interested where you get the Darwin compatible crossgcc and other tools (AS,LD)

[John Spikowski]

I assume you mean generating gcc source, and then compile/link that on Mac?

Correct.

[marcov]

I assume you mean generating gcc source, and then compile/link that on Mac?

Correct.

Note that in general crosslinking(*) IS possible, but I did that years ago, and it was horror to get cctools compiled (for OS X 10.3 PPC then).

I don't know the current situation, so if sb has up to date info, i'd like to hear it.

(*) I only needed as,ar,ld, not gcc.

[AGS]

I do not really understand why the output produced is referred to as non readable by humans. A small program to show what I mean.

FB source:

Code: Select all

Dim x As Integer

x = x + 8

Print x

And this is the output produced by the C emitter:

Code: Select all

/* Compilation of test.bas started at 13:54:28 on 01-30-2010 */
typedef char byte;
typedef unsigned char ubyte;
typedef unsigned short ushort;
typedef int integer;
typedef unsigned int uinteger;
typedef unsigned long ulong;
typedef long long longint;
typedef unsigned long long ulongint;
typedef float single;
typedef struct _string { char *data; int len; int size; } string;
typedef char fixstr;
void  __stdcall fb_PrintInt( integer, integer, integer );
static void fb_ctor__test( void ) __attribute__ ((constructor)) ;

static void fb_ctor__test( void )
{
	integer X$;
	label$0:;
	#define vr$0 ((integer*)(&X$))
	__builtin_memset( vr$0, 0, (integer)4 );
	X$ = X$ + (integer)8;
	fb_PrintInt( (integer)0, X$, (integer)1 );
	label$1:;
}
/* Total compilation time: 0.002652571764541811 seconds. */

X$ refers to the variable X.
__builtin_memset clears X.
X$ = X$ + (integer)8 looks like the C equivalent of x = x + 8.
fb_PrintInt refers to a routine in the rtl.

Now where does the unreadable part kick in? The example is of course just a short example but still, there is nothing unreadable about it. I've tried an example with some array processing in it as well and the result was somewhat the same: readable code.

I'm wondering why there can be so many seemingly unused labels in the code produced. I wrote a small example that contained a loop and ended up with C source that contained five labels (only one was used to implement the loop). gcc removes non - used labels (when choosing .S as output format the unused labels do not appear in the emitted asm code) so it's not a big thing.