gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Beginners > ASM questions.

#15419 - Steve++ - Thu Jan 22, 2004 11:17 am

I'm just starting out GBA dev. I want to start with assembly because I'm not afraid of it (have used PIC assembly, did a bit of Intel years ago) and I think it's a great way to get to know the GBA (and I'm a control freak). Anyway...

I want to use the GNU assembler (not goldroad) in either the devkitadv or HAM environment (not using HAMlib). I'm just not sure what happens when I assemble a file. I've come across documents about the COFF and ELF formats, but they are huge and complicated.

First of all, what exactly happens when I do the following?
gcc -o game.elf game.S
objcopy -O binary game.elf game.bin
(or something like that)...

Is it the same under devkitadv as in HAM?

What about the COFF (.o) format? How do I use that? If I write a program and assemble it to a .o file, won't the program start location be in the wrong spot (i.e. 0x00000000 instead of 0x8000000)? Do I have to pad the beginning of the file with 33,554,432 nops (128 MB) to get the right start location? Or is there a way to tell the assembler that the program will be loaded from address 0x8000000 instead of 0x000000? Will the linker completely screw with my programs' addresses so that, for example, when I refer to address 0x000000, the same code in the final binary file will get converted to 0x8000000? What gets relocated and what doesn't?

I would have thought converting assembly language to raw binary executable code would be a very simple manner. Why is this not the case? (Grrrr....!)

Last questions: if i get this all to work, how do i set aside space for the header? I've heard VBA doesn't care whether or not a header is present - but how does it know whether or not it's there? The first word in the header is a pointer to the start of the program, right? If VBA doesn't care whether or not there is a header, how does it know what to do with the first word (i.e. how does it know whether it should jump to that memory location or execute the word itself?)?

I don't care what's in the header (except for the first word) because i know my soon-to-arrive flash cart will insert it, but i've heard that space should be set aside anyway, as the flash cart isn't going to relocate the code (i definitely wouldn't want that to happen!!).

Sorry for the barrage of questions. I've been reading stuff for the last couple of weeks and it seems that this basic information isn't available.

Thanks to anyone who takes the time to read this and/or reply.

#15424 - FluBBa - Thu Jan 22, 2004 1:25 pm

If you are used to assembler and not machinecode you should know the answear to most of these questions.
All references to addresses within your program should be to labels and not to real addresses, the linker only relocates pointers to labels.
The header contains info about the ROM, it a good idea to have at least an idea what is in it, info should be available in most GBA documents. The first word is a branch instruction, not just an address, most flashing softwares writes a new header if there is none present, so you at least have to leave room for the header.
I am sorry I cant comment more on gcc and gas, some one else probably will though.
_________________
I probably suck, my not is a programmer.

#15434 - poslundc - Thu Jan 22, 2004 3:28 pm

Steve++ wrote:
First of all, what exactly happens when I do the following?
gcc -o game.elf game.S
objcopy -O binary game.elf game.bin
(or something like that)...


Well, there might be stuff I'm missing, but it's basically the following:

- gcc pre-processes your file (macros, comment removal, etc.; you can skip this step by renaming your file to .s instead of .S)
- gas converts your assembly code into object code (.o)
- ld links your object files into a .elf file and resolves all of the address labels
- objcopy strips the label data, etc. from the .elf file and gives you a GBA-compatible binary file.

It's the responsibility of the linker (ld) to make sure that stuff gets put in the proper sections (eg. that your code appears in the ROM). To achieve this, you should have a linker script (one comes with devkitadvance). I'm not exactly sure on the syntax to pass the linkscript to gcc (I usually call gcc -c to compile separate object files then call ld explicitly) but it will be in the gcc man pages.

Dan.

#15485 - Steve++ - Fri Jan 23, 2004 2:52 am

Thanks for your help.

I just had a look at devkitadv, in particular crt0.S and lnkscript. Now, I know nothing about this kind of stuff and it would seem pointless for me to learn about such matters if all I want to do is write plain and simple arm assembly (using gas). That stuff seems too complicated for what I want to do.

Is there a way that I can use the assembler, possibly without a linker script (and possibly without a linker at all), to produce raw executable code that knows it's being started at 0x8000000?

I remember reading a beginners' article (years ago, so I can't find it) on operating systems that showed how to do this kind of thing for a C program, using DJGPP (it was for making a bootloader), although I can't recall if (or how) they made the program aware of where it was being loaded.

From my PIC project I recall there was an assembler directive called ORG that handled location awareness.

#15499 - FluBBa - Fri Jan 23, 2004 12:05 pm

Maybe you can get Ville Helin http://www.hut.fi/~vhelin/wla.html to implement ARM support in his WLA DX assembler.
_________________
I probably suck, my not is a programmer.