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.

Coding > Raising number of "incbin" resulting in R_ARM_THM_

#27739 - DiscoStew - Wed Oct 20, 2004 7:44 am

Just some relevent information...
For the past few days I've been working on a VB.Net program that would allow me to take a bunch of compatible WAV files, and one by one convert them into 8AD format by accessing tepples's wav28ad prog while it writes into 2 other files, 1 ASM file that loads each 8AD file by "incbin" with a START and END label on each end, and one "C" file that sets up a const array with extra data per file so that I can access the audio by indexing. With all these files together along with code that plays these audio files through AAS, I'm trying to create an easy way to play 8AD audio.

Now for the problem...
I'm using DevKitARM for this project I working on, and I plan to use a very hefty amount of 8AD audio that could total up over 10MB (not just sfx, but streamed music too). Everything seems to work correctly when I have at most about 3MB of 8AD audio. However, when I begin to go over that amount, I get linking errors like "relocation truncated to fit: R_ARM_THM_PC22 yadayadayada", sometimes in my 8ad and other functions, and sometimes in a '$t' function. I did a forum search on "R_ARM_THM_PC22", and all I got were threads leading to function calls of IWRAM. The problem occurs when I "incbin" more than approx 3MB of data into 1 object file. I'm not sure if I have explained enough for an answer to my problem, but perhaps someone can lead me in a direction that will result in this problem being fixed.
_________________
DS - It's all about DiscoStew

#27761 - tepples - Wed Oct 20, 2004 8:06 pm

"PC22" means 22-bit program counter. A 22-bit number can represent numbers up to 2^22, which is around 4 million. This seems close to your "about 3MB" limit for the amount of data you've been able to incbin.

Are you putting the incbin statements into the .rodata section (as you should) or into the .text section (as I suspect)? If changing the section doesn't work, you may have to do some playing with long_call, or you may have to switch to an appended data method such as GBFS (and give up source debugging).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#27769 - DiscoStew - Wed Oct 20, 2004 10:04 pm

AHA! You are right!

I made the change in my ASM file containing the incbin statements from "SECTION .text", to "SECTION .rodata", and now I have no problems. I didn't know to use .rodata instead. jd's AAS where all the data is stored starts with using .text instead of .rodata, so I assumed I could do the same thing here. Wouldn't this also cause a problem in AAS if the compiled ASM file for that is over 4MB, or does the ConvAAS program change over to .rodata once the 4MB limit is reached?
_________________
DS - It's all about DiscoStew

#27772 - jd - Thu Oct 21, 2004 12:39 am

DiscoStew wrote:
Wouldn't this also cause a problem in AAS if the compiled ASM file for that is over 4MB, or does the ConvAAS program change over to .rodata once the 4MB limit is reached?


No, it doesn't. I must confess I wasn't aware of this restriction until now, but I am working on a new version of AAS and I'll make sure I change Conv2AAS to use .rodata rather than .text.

#27775 - DiscoStew - Thu Oct 21, 2004 2:37 am

jd wrote:
I am working on a new version of AAS and I'll make sure I change Conv2AAS to use .rodata rather than .text.


Good deal. Can you devulge any details as to what we may see in the new version? Just thought I ask.

I just tested my prog, and it is a whopping 16MB, 15.8MB is playable 8ad audio. =)
It is just a test, I don't plan on using that much...................yet. =)

EDIT:
Actually, 15.4MB is 8ad audio, approx. 400K is from 3 MODs that I tried out.
_________________
DS - It's all about DiscoStew

#27777 - tepples - Thu Oct 21, 2004 3:27 am

Well at least it isn't 15 MB of GSM audio. Then you'd probably be making a dance simulator.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#27780 - jd - Thu Oct 21, 2004 3:52 am

DiscoStew wrote:

Good deal. Can you devulge any details as to what we may see in the new version? Just thought I ask.


The main new feature will be 16 channel support, as well as support for louder, clipped mixing modes (which you really need with more than 8 channels).

#27785 - DiscoStew - Thu Oct 21, 2004 5:20 am

oooooooo, me like..........
_________________
DS - It's all about DiscoStew

#27786 - DekuTree64 - Thu Oct 21, 2004 5:36 am

Yes, yes, I'm very curious to see how fast you can get 16 channels. Lots of nice tricks to go around, but also lots of limits, especially on the number of registers available to work with.
Awesome job finishing up Payback by the way, you have my fullest respect as a fellow lover of insanely optimized code, and you can bet I'll be first in line to buy a copy.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#27787 - jd - Thu Oct 21, 2004 6:10 am

DekuTree64 wrote:
Yes, yes, I'm very curious to see how fast you can get 16 channels. Lots of nice tricks to go around, but also lots of limits, especially on the number of registers available to work with.


What tricks did you have in mind? The performance is basically the same (per channel) as with 8 channels and it doesn't need any extra registers. (The volume boosted modes take a bit more CPU time and use a lot of tricks, though.)

DekuTree64 wrote:
Awesome job finishing up Payback by the way, you have my fullest respect as a fellow lover of insanely optimized code, and you can bet I'll be first in line to buy a copy.


Thanks!