All works fine here. (HDMI, 3D only on Raspberry PI, Audio, NET, USB etc.)After a "hello_world.c" and some OpenGL ES test's I learn ARM assembler now.I use code::blocks and geany as IDE (same as on Win32 and x86 Lnux)Porting the FB runtime for ARM linux devices should be possible all dev packages are the same as on a x86 Linux box.

The problem is the ARM code emitter for fbc.

OpenGL on the PI can't run in a window it's a kind of fullscreen indepent from current window managerso ScreenRes() will ignore width,height and depth and ScreenInfo() can return the current resolution and depth.

None OpenGL modes are libX11 stuff same as on x86 lnux.

@DKL Can FB compile it self if you compile it self with -gen gcc ?

Joshy

Last edited by D.J.Peters on Aug 31, 2014 18:41, edited 2 times in total.

This should generate a *.c file for each *.bas file. On Angström you've to adapt the outcome. Skip the gdm-part (mouse handling) since there's no libgdm. And some __asm__ statements need adaption. That should be all to get it compiled.

D.J.Peters wrote:so far i know we need on other cpu architectures:

libfb.a, libfbgfx.a, libfbmt.a

fbgfx is NOT a must-have (AFAIK), you can use SDL, GDK or others.

But either fb or fbmt are mandatory. They should compile with gcc on any system.

D.J.Peters wrote:but was it with the linker stuff ?crt2.o, crtbegin.o, crtend.o, ...

These are parts of the C build system. They should come with the system.

In the above described way I managed to compile all *.o files (compiler & rtlib) and to build the libfb.a and libfbmt.a native on Angström. But, I couldn't link them yet (The original makefile uses fbc. I'm not familar with alternatives, ld or gcc).

root@beaglebone:~/Projekte/test# cat a.bas ?"My first FreeBasic program on ARM:"for i as integer = 1 to 9 ?i; " line of putput!"next?"Voila!!!"root@beaglebone:~/Projekte/test# ./aMy first FreeBasic program on ARM: 1 line of putput! 2 line of putput! 3 line of putput! 4 line of putput! 5 line of putput! 6 line of putput! 7 line of putput! 8 line of putput! 9 line of putput!Voila!!!root@beaglebone:~/Projekte/test#

Well, it happened during September/October after the 0.24.0 release. There were lots of -gen gcc patches coming in at the time, and more until early 2013. Work on the LLVM backend helped the C backend aswell, though after the initial phase of getting excited about it I haven't continued working on it much. But it's still an interesting option, especially to solve the debugging meta data problems with the C backend, and I want to make it work eventually.

Much like TJF said, you can pre-compile the fbc sources (from the src/compiler/ directory) by doing:

fbc -target linux *.bas -gen gcc -r -m fbc

and then theoretically copy the .c files over to the target system and compile them with gcc using something like:

gcc -o fbc -fno-strict-aliasing -frounding-math fbrt0.o *.c -lfb

That's assuming you have already compiled libfb.a and fbrt0.o on the target system. It will probably need further -l options depending on rtlib dependencies, on Linux for example -lncurses or -ltinfo, and -pthreads.

Just keep in mind that the .c code is not system/architecture/ABI-neutral, so for example .c code generated with -target linux won't work on Win32, and (currently as of FB 0.90) it also contains 32bit assumptions so won't work on 64bit, not to mention that there still is some x86 inline asm used by -gen gcc to implement fast & "properly" rounding (the FB way of rounding) for float <-> integer conversions which won't work on other architectures.

We've started the 64bit port a while ago (i.e. x86_64 Linux/Windows systems, and theoretically other 64bit too), and I'll continue working on it now that the 0.90 release is done. It includes removing the 32bit assumptions from fbc and of course removing any traces of x86 from -gen gcc output. And just overall qualiy improvements of -gen gcc since it will fully rely on it.

While -gen gcc can already be used to port FB to different architectures (only requiring some tiny fixes as of FB 0.90), porting to a different operating system such as MacOSX or Android is more difficult because the rtlib must be ported first (and the gfxlib2 shouldn't be forgotten either) to use the different set of system functions.