#47955 - joebob180 - Fri Jul 15, 2005 9:10 am
Is there any advantage to storing maps in binaries as opposed to headers?
#47956 - wintermute - Fri Jul 15, 2005 9:42 am
1. Never, ever put data in headers. It's extremely poor practice and will cause problems at some point. If nothing else #including a header with data will require that data to be recompiled every time the C/CPP file changes. Compiling arrays is both memory hungry and notoriously slow.
2. There are several advantages to converting directly from binary data to an object file using objcopy without the intermediate step of converting to a C array. As noted above, compiling large arrays consume copious quantities of memory and are notoriously slow. There is also no need to consume large quantities of disk space to store the converted arrays as source code.
#47970 - tepples - Fri Jul 15, 2005 1:23 pm
wintermute wrote: |
There are several advantages to converting directly from binary data to an object file using objcopy without the intermediate step of converting to a C array. |
There is one main disadvantage: objcopy does not let the caller specify the minimum alignment of the object in memory.
Quote: |
As noted above, compiling large arrays consume copious quantities of memory and are notoriously slow. |
Only if you converted your file to C rather than assembly language. The GBFS distribution includes a tool called 'bin2s' that converts binary files to assembly language code, which is much faster to compile than C. The advantage of 'bin2s' over 'objcopy' is that 'bin2s' assumes 4-byte alignment, unlike 'objcopy' that assumes 1-byte alignment.
Quote: |
There is also no need to consume large quantities of disk space to store the converted arrays as source code. |
Then store the converted arrays in the operating system's pipe buffer using something like this:
Code: |
bin2s data1.bin data2.bin data3.bin | as -c -mthumb-interwork -o data.o |
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#47980 - wintermute - Fri Jul 15, 2005 4:19 pm
That's quite cool. Bin2s is provided in the latest devkitARM release so we could modify the bin2o rule in base rules to use that instead of the objcopy trickery.
This section :-
Code: |
#---------------------------------------------------------------------------------
# canned command sequence for binary data
#---------------------------------------------------------------------------------
define bin2o
padbin 4 $(<)
$(OBJCOPY) -I binary -O elf32-littlearm -B arm \
--rename-section .data=.rodata,readonly,data,contents,alloc \
--redefine-sym _binary_`(echo $(<) | sed -e 's/^\/\([a-zA-Z]\/\)/\1_/' | tr . _ | tr / _)`_start=`(echo $(<F) | tr . _)`\
--redefine-sym _binary_`(echo $(<) | sed -e 's/^\/\([a-zA-Z]\/\)/\1_/' | tr . _ | tr / _)`_end=`(echo $(<F) | tr . _)`_end\
--redefine-sym _binary_`(echo $(<) | sed -e 's/^\/\([a-zA-Z]\/\)/\1_/' | tr . _ | tr / _)`_size=`(echo $(<F) | tr . _)`_size\
$(<) $(@)
echo "extern const u32" `(echo $(<F) | tr . _)`"_end[];" > `(echo $(<F) | tr . _)`.h
echo "extern const u8" `(echo $(<F) | tr . _)`"[];" >> `(echo $(<F) | tr . _)`.h
echo "extern const u32" `(echo $(<F) | tr . _)`_size[]";" >> `(echo $(<F) | tr . _)`.h
endef
|
would become :-
Code: |
#---------------------------------------------------------------------------------
# canned command sequence for binary data
#---------------------------------------------------------------------------------
define bin2o
bin2s $(<) | arm-elf-as -o $(@)
echo "extern const u32" `(echo $(<F) | tr . _)`"_end[];" > `(echo $(<F) | tr . _)`.h
echo "extern const u8" `(echo $(<F) | tr . _)`"[];" >> `(echo $(<F) | tr . _)`.h
echo "extern const u32" `(echo $(<F) | tr . _)`_size[]";" >> `(echo $(<F) | tr . _)`.h
endef
|
#47984 - ScottLininger - Fri Jul 15, 2005 4:55 pm
Devil's Advocate post here...
One advantage to using headers (or at least .c files, with headers) is for learning. It allows you to see the data in an extremely simple and easy-to-edit format that maps one-to-one to what you'd see if you hand coded the data. This saved my butt many, many times while I was learning GBA programming and trying to debug my first programs.
Another time to consider using headers is if you are generating maps out of your own tools. Yes, writing a binary file from most environments is almost as easy as writing a text file, but it gets back to the debugging issue noted above. When you can see the output from your mapping program in a form that you've already got working on the GB side, there's one less layer of obfuscation to debug.
Finally, headers means one less step in your compiling/linking process, which can be a challenge in itself, especially for compiler retard like me.
:)
-Scott
#47986 - tepples - Fri Jul 15, 2005 5:03 pm
ScottLininger wrote: |
One advantage to using headers (or at least .c files, with headers) is for learning. It allows you to see the data in an extremely simple and easy-to-edit format that maps one-to-one to what you'd see if you hand coded the data. |
So does the .s method.
Quote: |
Another time to consider using headers is if you are generating maps out of your own tools. Yes, writing a binary file from most environments is almost as easy as writing a text file, but it gets back to the debugging issue noted above. When you can see the output from your mapping program in a form that you've already got working on the GB side, there's one less layer of obfuscation to debug. |
So does the .s method.
Quote: |
Finally, headers means one less step in your compiling/linking process, which can be a challenge in itself, especially for compiler retard like me. |
data.s is just one more file, and it can be put in with the link step; how hard can that be?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#47999 - poslundc - Fri Jul 15, 2005 8:52 pm
ScottLininger wrote: |
One advantage to using headers (or at least .c files, with headers) |
Big distinction. One's good for learning, I agree. The other, however, I believe is only good for learning how to do things incorrectly.
Dan.
#48004 - joebob180 - Fri Jul 15, 2005 10:34 pm
Ok, thanks for the advice.
I am going to make my own tools, and thats the main reason I asked, but its about the same either way.
Im going to use Visual Basic to make my tools. I already know the basics, but Im going to have to remember them ;). Does anyobdy know any good tutorials for tool making in VB? I remember reading one a long time ago for rom hacking but I cant find it now?
#48181 - Miked0801 - Sun Jul 17, 2005 11:58 pm
How well do you already know VB?
#48195 - joebob180 - Mon Jul 18, 2005 3:45 am
Fairly good, not much .NET, but I know 6.
#48197 - poslundc - Mon Jul 18, 2005 4:33 am
It should come as no surprise that you do not need to know anything about .NET in order to write GBA tools.
Dan.
#48223 - joebob180 - Mon Jul 18, 2005 7:45 am
Yeah, I know, I just got to find my VB cd and install it, its been a while.