First off, notice that the DDJ article says that FP languages may be better for some environments, not all. In particular, it’s useful when you can parallelize and on multi-core systems (which the GBA isn’t). According to wikipedia, FP tends actually slower except for heavy number crunching.

As for which languages are available for GBA programming, most of it is C/C++ and assembly, but there also DragonBASIC and from a cursory glance at Torlus’ site, it seems that he’s got some Forth, lua and an early Java there. How well these work I can’t tell you, though. There’s also a Pascal port and something called Catapult, but that’s for official developers only.

Note that except C(++) and asm, everything is very old and as far as I know no longer actively supported.

Maybe I have still have a lot of question to ask you in the future. :)
Please don’t be annoyed with me for asking these questions which maybe you think so easy.

But I still have one question. As you said, part of the extra information in the ELF file is debugger information, which could be helpful when running with gdb. I remember that the “-g” option of GCC on Linux platform can produce extra debugging information. What is the different between these two commands “gcc -g -o file file.c” and “gcc -o file file.c” in Linux OS? Does the ELF file contain more debugging information if you add “-g” option when you complie the source codes?

Thank you so much.

The GBA does not expect all that extra stuff and doesn’t know what to do with it. In other words, it wouldn’t run. The objcopy tool strips all the excess information.

I think there’s a linker flag that strips the binary down to the raw bits and bytes, but I’ve never really examined what it does. Also, part of the extra information in the ELF file is debugger information, which could be helpful when running with gdb.