----- Original Message -----
From: <d_yerrick@...>
> John Seghers wrote:
> > For example (and it may be a bad example, I don't know if these
> > are packaged together) if malloc, calloc, free, and realloc are
> > all packaged together, you will have all four of them linked
> > even if you only use malloc/free.
>
> >From what I've seen in malloc() implementations, malloc() and
> free() are the big complicated functions, and calloc() and
> realloc() are tiny wrappers around malloc().  For instance,
> calloc() is merely a malloc() followed by a memset(), and
> realloc() is malloc(), memcpy(), free().

My point was not about how much those specific functions impacted
the final product.  My point was more about granularity in general.
Function-level linkers handle this on a function-by-function basis
whether the code is in a library or not

This becomes even more important with template libraries, since by
definition the template class must be in the compilation unit where it
is used.  If you have 10 functions (each of similar complexity) to provide
the implementation of the template, and your code uses the template
to instantiate a class, but only uses 2 of those functions, you're stuck
with code for all 10 being compiled.

A linker that includes everything from a compilation unit in the final
product will include all of this dead code. A linker that performs
function-level linking will strip it out.

The specific answer came that newlib is pretty granular--generally
one function per file--which is good.  The GCC tool chain developers,
however, (whenever I've seen this issue debated) have basically said
that if you want function-level linking, you have to do it manually--and
they
see this as an acceptable process.  Basically use #ifdefs to break a single
source file into individual compilation units, one for each function.  I
find
that to be an unacceptable amount of manual labor considering that
other tool chains have had this feature for 8-10 years.

- John

--- In gbadev@yahoogroups.com, "Dave Murphy" <wintermute2002@n...> wrote:
>
> > A header file would be a good idea, but using
> > the purported official register names may get one in trouble
> > with trade secret law.
>
> I'm not sure that this would be a problem given that so much
> information is now publically available. How do we know Martin's
> docs are the purported official names for instance?

http://www.work.de/nocash/gbatek.htm

"002h - Undocumented - Green Swap (R/W)"

"The current GBA BIOS addresses only the upper eight bits of this
register (by writing 00h or 80h to address 04000301h), however,
as the register isn't officially documented, some or all of the
bits might have different meanings in future GBA models."

"800h - 32bit - Undocumented - Internal Memory Control (R/W)"

How would Martin Korth know what's "officially documented" without
having access to official docs?

> along with console type stuff for the Xboo cable.  This one
> could be a little sticky legally speaking - I'm fairly sure
> open sourcing the multiboot protocol layer would be a big no no.

But hey, if Martin Korth has documented it...
http://www.work.de/nocash/gbatek.htm#biosmultibootsinglegamepak

--
Damian

--- In gbadev@yahoogroups.com, "John Seghers" <johnse@s...> wrote:
>
> There was posted here a while back info about a GBA "file system"
> whereby you could paste binary files onto the end of a ROM image
> and the file system code could look stuff up by name.

That was mine.  It was called GBFS, and the libraries were under
an X11 style license.
http://www.pineight.com/gba/#gbfs

The biggest drawback with GBFS, or with any other system that
pastes asset data archives at the end of a ROM, is that as far
as I know, you can't do it with a .elf format ROM and so you
can't use VBA's GDB support.

> Also, if someone comes up with a cartridge and/or SIO interface
> to MMC or SD memory cards, having access to these via the file
> i/o functions would be great.

Has anybody tried to reverse engineer the hardware of the
Game Wallet?  The Game Wallet is a SmartMedia drive that
connects to the GBA's SIO port.

> For example (and it may be a bad example, I don't know if these
> are packaged together) if malloc, calloc, free, and realloc are
> all packaged together, you will have all four of them linked
> even if you only use malloc/free.

From what I've seen in malloc() implementations, malloc() and
free() are the big complicated functions, and calloc() and
realloc() are tiny wrappers around malloc().  For instance,
calloc() is merely a malloc() followed by a memset(), and
realloc() is malloc(), memcpy(), free().

--
Damian

For the David which ask...

cvs -z3 -d:pserver:anonymous@...:/cvsroot/devkitadv co
devkitadv

There is also a nightly cvs tarball which can be downloaded from, but I do
not remember where the link is (somewhere under
http://sourceforge.net/projects/devkitadv) ^_^

You can browse the source code online at:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/devkitadv/

On Wed, 26 Feb 2003, David Welch wrote:

> I was also keeping on the bleeding edge of binutils, gcc, and newlib,
> and unless I am looking in the wrong places devkitadv has not kept that
> close to those releases?

You are correct, I did not keep up with new releases of GCC.  Even with
CVS I am worried about how much work it will be to move to 3.3 and 3.4.
Theoritically, with CVS, I could start merging in 3.3 and 3.4 right now,
and be ready on day zero.

> I have for a while now been disappointed by the performance of the code
> generated by gcc (when compared to the pay-for compilers)

I have been wondering if this can be partially remedied by using GCC's
ability to use profiles of running code for optimization.  By using Visual
Body Advance and gprof you should be able to produce profiles that can be
used by GCC to improve code.  Maybe.  Of course, it is more work then just
using ARM's compiler.

> I am still not quite comfortable having one form of fileio in syscalls.c
> that was built with the compiler distribution buried in a .a file somewhere
> and overriding that with my own.  If I simply link in an object with those
> functions included will it override the c library included with the
> compiler?  I know just try it and stop asking dumb questions...

The linker looks object files, and then in library files in the order they
are specified.  For instance, if you write your own malloc and free and
make sure they are specified before the standard library, all your code
(including library code by other people) will link to your malloc and free
and ignore the ones in the .a files.

If you do that with .o files, you will get a multiple definition error.

> Ummmm, (reading your replies) I didnt mean to imply that DKA has swi calls,

I thought I may be misunderstanding you...

> #define HAS_INIT_SECTION,
> ecos uses this, I was trying to do something with the do_global_ctors or
> dtors functions, like remove them because they were wasting memory (I
> think), I dont remember I have always added it in there, ecos.h still has
> it, it looks like gcc/crtstuff.c might look for it...

Is this the option that tells gcc to create .init and .fini sections?  I
actually use the configure option --diable-init-fini or something like
that to disable it because Jeff's crt0.S would just ignore it.  Or, is
this handled by __gccmain.  It has been too long since I investigated C++
compilation to remember ^_^

> I dont know if it has come up yet but I strongly vote to keep the long form
> of the executable names: arm-agb-elf-gcc vs gcc.

In dka, I keep the long names, and then use my mklinkstub program (made
possible through clever use of objcopy ^_^) to create the short name
versions.

I never could finish building gcc if I tried to tell it not to use the
prefix.  Also, the documentation for building gcc now says that it ignores
any attempt to set the name prefix if you are building a cross compiler.
They probably did this because it breaks the build process.

I always felt like it wasn't a big deal to type 'arm-agb-elf-gcc', but I
did not even want to deal with the issue, so I wrote mklinkstub to
simulate symbolic links.

> I only want one gcc executable in the path and that one should build
> for the native host environment, cygwin, mingw, linux, whatever.  For
> arm cross compiling keep the name different arm-agb-elf-gcc.

I think this can be solve by being aware of your path.  If the native path
is first, then it will cover up all the linkstubs in the dka/bin
directory.

I need to look into the -b option more and see how it would relate to the
native compiler.  I was thinking something like this:

arm-agb-elf-gcc ...  # compile for gameboy advance
arm-agb-elf-gcc -b agb  # also compile for gameboy advance
arm-agb-elf-gcc -b gp32  # compile for gp32
arm-gp32-elf-gcc  # compile for gp32
arm-gp32-elf-gcc -b gp32 ... # also compile for gp32
arm-gp32-elf-gcc -b agb  # compile for gameboy advance
gcc 		 # native compiler or gba compiler depending on PATH
gcc -b agb 	 # fails for native compiler
gcc -b gp32 	 # fails for native compiler

In cygwin or msys, you would probably have your path setup so that the
short name 'gcc' would be covered by the native compiler.  But, if you
were using cmd or command.com (I dunno why, Cygwin or msys are much nicer
shells), then you probably do not have another gcc, so you can use the
short name.

When in doubt do a gcc --version (Unlike what rmitton says, changing
version.c is not "just to be fancy")


> Last comment, I cant remember what devkitadv does specifically but I have
> seen a number of arm cross compiler builders use a huge list of switches
> when configuring gcc, the vast majority of those are already the defaults
> or are obsolete or dont apply to arm builds...

I revisited the documentation when I started working on release 5, and
eliminated a few switches.  I am almost completely sure that all the
switches I used before were relavent for gcc version 3.0.2, but they have
changed slightly.

--with-headers is now deprecated, and eliminating it will still result in
a successful build.  The replacement, --with-sys-root, is not required
either.

I am not sure if --disable-shared applies to generic ARM targets.  Perhaps
it only applies to targets with OSes.

Same goes for --disable-threads.  However, I figured that since those
options accurately describe the GBA, that I would keep them.

--enable-targets=arm-coff,arm-aout are there just for completeness.  I
figured that someone might find a use for them, and if so then they would
not have to recompile DKA.  arm-coff is their because I believe that is
what Microsoft's ARM compiler would output.  I wanted to experiment with
it, since it is free and may make better code than gcc.

Perhaps I should add arm-pe so that the devkit could compile PocketPC
executables (I think). ^_^

I kept --enable-win32-registry, although I never had any problems getting
gcc to relocate to different directories.

--with-cpu=arm7tdmi makes the gameboy processor the default.

And of course --target=arm-agb-elf so that it uses the custom linkscript
and crt0.s.

I cannot think of any more switches except for --with-newlib

I found that if you open the .bin file and run it in the emulator directly, it
works. With the new Integrated Development Environment in ham I belive you can
customise it simular to other programs. So we should be able to set it to run
.bin files correctly. Also JC you were saying that you could change the compiled
output of your program to .gba. That may work also.

-DMan-
   ----- Original Message -----
   From: JC Matthews <kreedskulls@...>
   To: gbadev@yahoogroups.com
   Sent: Thursday, February 27, 2003 2:10 AM
   Subject: [gbadev] Ham and DevkitAdvance


   For some reason when I compile the work I have done from the Devkitadvance
into the new version
   of ham, it only works when I am in debug mode (HAM) and I don't understand
why.  Will it affect
   the game when I convert it to the flash card




         Yahoo! Groups Sponsor
               ADVERTISEMENT




   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

> -----Original Message-----
> From: Andreas Thorsén [mailto:yahoo@...]
> Sent: 26 February 2003 22:55
> To: gbadev@yahoogroups.com
> Subject: SV: [gbadev] arm-agb-elf arm-thumb-elf arm-elf (O.O)
>
> Jason, may I just ask what's wrong with cygwin? Why are you
> moving away from
> that? I guess I miss something, but I use it for more than gba development
> with not many problems.

well I'd have to say it's a fine idea. The problem I found with cygwin
relates to official gcc based devkits - swapping about between platforms
often involved a variety of cygwin.dll versions which interfere with each
other in various interesting ways. Once I found MinGW/minsys I found the
problems just went away and I could build win32 native toolchains for
everything as required. The speed difference between a mingw build & a
cygwin build has to be seen to be believed too.

For some reason when I compile the work I have done from the Devkitadvance into
the new version
of ham, it only works when I am in debug mode (HAM) and I don't understand why. 
Will it affect
the game when I convert it to the flash card

> > So what command line switch would you use to switch between a
> > basic GBA crt0/linkscript and one for the GP32?
>
> -b arm-agb-elf / -b arm-gp32-elf perhaps
>
>
http://gcc.gnu.org/onlinedocs/gcc-3.2.2/gcc/Target-Options.html#Target%20Opt
> ions

Coolness, I will be investigating this option very shortly.  It actually
looks fairly simple.

----- Original Message -----
From: "Andreas Thorsén" <yahoo@...>

> I totally agree with this. Even though I have learned to understand
> linkerscripts and crt0.S startup files, I remember it was a real pain in
the
> beginning. Most people probably don't even know what they do, and would be
> left totally stuck if there were no defaults.

Coming back 2 year later I wonder if such an easy to use kit is really
needed anymore.  I guess there will always be newbies.  Considering how many
days I have spented watching binutils, gcc, newlib, and insight compile, I
can certainly imagine that some people would want something easy ^_^

> I use devkitadvance for gp32 development. I easily compiled all the gp32
> devkit examples using devkitadvance. Just added this "-mtune=arm920", and
> used jeff's crt0.S and linkscript for gp32 instead.

After finding instructions in Japanese about how to use DevKit Advance,
finding out that people were using it to develop for a completely different
system was the coolest thing I found out after I started looking into this
again.

> Jason, may I just ask what's wrong with cygwin? Why are you moving away
from
> that? I guess I miss something, but I use it for more than gba development
> with not many problems.

I have been told it is slow.  I have not benchmarked it yet, so it may just
be my imagination, but it seems to be faster.  If it works, and is not a
pain to keep up to date, then I'll stick with it.

It does not really matter whether the compiler EXE are mingw or cygwin
based, you can still use them in either environment (or from the command
prompt).  MinGW wins because of speed, although if it proves difficult to
rebuild it everytime a new GCC comes out, then I'll be reconsidering.

MinGW was a royal pain in the butt to get working.  A lot about mingw is
missing or broken (worse than Cygwin).  I think that I will end up using
Linux as my main dev OS because everything I need is there.

The way things are now, it looks like the tool chain from binutils to newlib
will be mingw based, while Insight/GDB will continue to be Cygwin because
getting Insight/GDB to compile to MinGW is proving to be a project in and of
itself the size of DevKit Advance.

> Regards,
> Andreas Thorsén
>
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

From: "John Seghers" <johnse@...>
> There was posted here a while back info about a GBA "file system" whereby
> you could
> paste binary files onto the end of a ROM image and the file system code
> could look
> stuff up by name.  Perhaps some of the newlib file i/o functions could be
> made to
> use this or something similar.

I have thought about stuff like this.  The main problem is creating
something like this that in such a way that if I use printf, I do not
nessecarily end up linking in all the code for doing all this fancy stuff.

It is possible to create a namespace on which would support all this, for
example, having a /dev/* hiearchy for doing serial IO and debugging, and
other files in a file system.  The problem is that once you have all this
fancy stuff, you need to make it granular, because it will be bloated as
people add stuff.

Maybe I could just create a plug-in system so that people can plug any
drivers they want into it.  The plug in system would be super lightweight,
and not take any room on your ROM unless you use a stdio function.

People could then provide zipfile and filesystem, and serial I/O plug-ins,
and they could do so without making their own distribution of newlib.

> Also, if someone comes up with a cartridge and/or SIO interface to MMC or
SD
> memory cards, having access to these via the file i/o functions would be
> great.
> Also, the game save RAM would be a good candidate for file i/o functions--
> perhaps with a special device identifier /dev/saveram/...

All good candidates for plugins.  I like this idea (it just occured to me).
Mainly because I can imagine the hooks for a standard file I/O driver being
a very small implementation, and it gets me off the hook for having to come
up with The One I/O Implementation to rule them all.

> Just some thoughts about how the standard IO functions could have useful
> application in the GBA rather than just yanking them from newlib.
>
> A Question about newlib.... How granular is it?

For the most part, newlib is one function per object file.  I have not
broken up the parts which I have written for newlib, but I will before
release 5 is finished.

> - John

I really think we are on the same page here Jason, not sure if we are going
round and round...

I tried devkitadv early on in my arm/gba experiments and then tried to use
it at the day job but had to learn how to undo a lot of stuff and then redo
it...That may not make sense but it lead me to do my own cross compile, dig
into newlib and gcc to understand how to get rid of all the SWI calls, etc,
etc.  Yes, crt0.s and a linker script, although both can be only a few
lines of code  when finished each are a big undertaking for the newbie.

Once I had something that worked one way I just did it that way, and kept
the blinders on to what anyone else was doing.  I was also keeping on the
bleeding edge of binutils, gcc, and newlib, and unless I am looking in the
wrong places devkitadv has not kept that close to those releases?

I have for a while now been disappointed by the performance of the code
generated by gcc (when compared to the pay-for compilers) again keeping on
the bleeding edge 3.0 had a noticeable performance jump over 2.95.3, and
each minor release of 3.x.x has shown a one or two percent improvement each
time.  I think newlib 1.11.0 was a performance hit over 1.10.0,
unfortunately I have not been saving those numbers anywhere, jotted on
envelopes and napkins only to be thrown out later...

So I did my own thing instead of use devkitadv because of 1) crt0.o and a
need to control linking 2) not keeping up with new releases (or so I
assume).  1) is solved 2) not sure...

I think this is a very good thing to open up conversation about devkitadv,
and move it to sourceforge, etc.  I think we are all on the right track and
can and should make it useable for  the gba, gp32, and other embedded arm
platforms.

This might lead back to the question of do we use arm-agb-elf or something
more generic like arm-thumb-elf (to which I am partial).  I guess if the
default crt0 is jeffs or one like it for the agb then I would say sure call
it arm-agb-elf.

Ahh, I should have used the word default for crt0, etc not "generic" sorry,
my bad...

For a long time I wasnt quite sure you could override crt0.o without
deleting it from arm-something-elf/lib/  now I know better. my bad...

I am still not quite comfortable having one form of fileio in syscalls.c
that was built with the compiler distribution buried in a .a file somewhere
and overriding that with my own.  If I simply link in an object with those
functions included will it override the c library included with the
compiler?  I know just try it and stop asking dumb questions...

Ummmm, (reading your replies) I didnt mean to imply that DKA has swi calls,
off the shelf newlib does, and we have both exercised them out.   I would
assume, in the end anyone working on an arm wants an Angel/semihosting free
build.  There may be some that would like that stuff left in there, I guess
they can put the original functions back in.

Nope not complaining at all, so far with gcc I have customized the syscalls
and crt0 and linker script on an application by application basis meaning
_I_ didnt use the defaults, and really didnt need them, I guess I dont care
if they are there or not so long as its not painful to get around them...

And for whomever asked, yes syscalls.c from newlib is where you would
simulate file i/o calls open, close, read, write so that they worked on
memory rather than a file system or if you wanted to put in a smart card or
sd card or something here is where you would do it.  I use the gba often as
an embedded platform so I just want to do a printf and have it look like a
computer terminal so I have done that (quite trivial actually).  You could
just as easily go one step further and have printfs shoot text out the
serial port to a dumb terminal (or pc)...Having memory look like a file
system is quite trivial as well, just a few pointers to memory and
variables to keep track of the offsets into memory.

fopen is just a mypointer=basefileaddress;  myoff=0;
read is memcpy(callersbuffer,&mypointer[myoff],size);  myoff+=size;
write is memcpy(&mypointer[myoff],callersbuffer,size); myoff+=size;
and close does nothing...

You get the idea...


#define HAS_INIT_SECTION,
ecos uses this, I was trying to do something with the do_global_ctors or
dtors functions, like remove them because they were wasting memory (I
think), I dont remember I have always added it in there, ecos.h still has
it, it looks like gcc/crtstuff.c might look for it...


To answer another question in this thread from someone.  mingw / msys is
better because 1) produces a gcc that runs faster.  2) both mingw and
cygwin produce gcc "packages" that are about the same size so its a break
even there 3) cygwin relies on a handful of dlls, if you are not careful
you can end up with more than one version of the same dll laying around and
can mess things up.  So if you use lets just say devkitadv built with
cygwin, and never use cygwin for any reason and never have   more than the
one copy of they dlls, then you are fine.  If you start to use cygwin for
other reasons or use other apps built with cygwin you could have a dll
version problem and one or both programs could stop working properly...
Doing a very very simple test the other night I saw that a mingw (msys)
built gcc compiled a program almost twice as fast as the same compile with
a cygwin built gcc...

Unfortunately mingw and cygwin have different goals and philosophy, for
example I dont think you can build insight or gdb under mingw (yes they
have one, I think it was painful) but you can under cygwin, same is true
for many many gnu and open source applications (will build and run under
cygwin but not mingw).  gcc is the exception to the rule...

I dont know if it has come up yet but I strongly vote to keep the long form
of the executable names: arm-agb-elf-gcc vs gcc.  I only want one gcc
executable in the path and that one should build for the native host
environment, cygwin, mingw, linux, whatever.  For arm cross compiling keep
the name different arm-agb-elf-gcc.  I am not saying that dka doesnt
because it does, I am just casting a vote for a ballot that hasnt happened
yet...

Last comment, I cant remember what devkitadv does specifically but I have
seen a number of arm cross compiler builders use a huge list of switches
when configuring gcc, the vast majority of those are already the defaults
or are obsolete or dont apply to arm builds.  Every time I re-read the gcc
documentation related to configure I can only come up with --target,
--prefix, and --with-newlib.  What does devkitadv use? and can we
re-evaluate what each one does and why its there and do we really need
it?  I struggled with many of these switches recently, built a gcc under
mingw about 20 different ways trying to get the binaries to run, from a
windows perspective, from c:\gccarm\bin finally gave up when I found out
(from another David) that they run just fine from c:\msys\gccarm\bin.  With
cygwin its pretty easy to get them to run from c:\gccarm\bin or pretty much
anywhere...

David (hmmm, well its a popular name, there are a lot of us running around)...

At 03:54 PM 2/26/2003 -0600, Jason Wilkins wrote:
>On Wed, 26 Feb 2003, David Welch wrote:
> >
> > This may all be beaten to death already, perhaps not, I too have switched
> > to mingw (Thanks Dave Murphy and others) I use my gcc build for both the
> > gba and something completely different so I want mine to be a generic arm,
> > for the gba use this crt0.s, syscalls.c, libcfunc.c, linker script for
> that
> > arm use another crt0.s, syscalls.c, libcfunc.c and linker script.
>
>There is not such thing as a generic link script or crt0.S
>
>I include one with DevKit Advance which is useful for projects without
>special needs, and the source code for those that want to rewrite it and
>use something custom.  Making the default useful for many people is better
>than making a default that is only useful for people writing for an Angel.
>
> > Basically those files I have identified as problematic for inserting Angel
> > SWI calls which I have absolutely no use for and just make life
> difficult...
>
>As far as I know, I have removed all Angel SWI from DevKitAdvance.  I have
>stubbed out all the low level syscalls so that they do nothing.  Sort of
>like you described.
>
> > Then each application supplies its own crt0.s, syscalls.c, and libcfunc.c
> > and linker script and uses the
> > -nostartfiles switch on gcc.
>
>Nothing stops you from doing that.  All devkitadv does is supply a default
>which will work most of the time unless you want to do something special.
>
> > Is there anything wrong with this approach?
>
>Nothing wrong with it.  I just think that my approach is better.  Many
>people have said how nice it is that you do not have to mess with crt0.S
>and lnkscripts unless you want to with DevKit Advance.  I believe that is
>why was (is?) popular.
>
> >  Is there an easier way to have the one cross compiler work for the gba,
> > gp32, and generic arms and allow stdio (syscalls), crt0, and linker
> > script customization?
>
>I'm not exactly sure what you mean.  A generic, out of the box, arm-elf
>compiler will work exactly like DevKit Advance if you give it the right
>options.  I've just tried to reduce the number of options you have to give
>it to get working results.
>
> > Also I started added a define of HAS_INIT_SECTION to gcc/config/arm/elf.h
> > probably starting with gcc 2.95.2, just a bad habit I guess (was trying to
> > kill off Angel and any other unused, excess code), I dont see anyone else
> > doing it, perhaps its a useless step?
>
>What does HAD_INIT_SECTION do?  Where exactly are the Angel calls you
>speak of?  I am sure I exorcised them from DKA.  I just edited out all the
>SWI calls from syscalls.c and removed the interupt table stuff.
>
> > I dont need/want to use any defaults...
>
>I've always said that devkitadv is never supposed to get in your way.
>Having functional defaults does not get in your way.  I cannot help but
>feel that you would rather have defaults which do not work, rather than
>defaults that a lot of people might use.  I could include defaults which
>cause the gameboy to emit a high screeching sound if you tried to use
>them, but it really makes no difference to you because you do not use
>them.  Maybe I am just imagining that you are complaining.
>
>The only problem I can see you having would be if I made
>arm-agb-elf-newlib depend too much on the default lnkscript and crt0.S.
>Rest assured that I will document the dependencies and write a bare bones
>example lnkscript and crt0.S so that anyone who wants to make their own
>custom stuff, can still use arm-agb-elf-newlib as long as they make sure
>to do a couple of things.
>
>The only dependence I can think of right now is exporting a symbol so that
>newlib knows where the bottom of the heap is.
>
>
> > David
>You are both named David!!!! ^_^

From: <krozinsky@...>
> I've been looking as the .s files generated from my c code and notice
> the following register names being used: sp, lr, s1, fp, ip

There's a nice document on the ATPCS (Arm Thumb Procedure Call Standard)
at http://www.cs.cornell.edu/courses/cs414/2001fa/armcallconvention.pdf
This document will probably help you a bit in understanding the compiler's
output.

Page 10 of this PDF has a listing of what the registers are used for, along
with
their synonyms.

Specifically:
r15 = PC: Program Counter
r14 = LR: Link Register
r13 = SP: Stack Pointer
r12 = IP: Intra-procedure-call scratch register
r11 = FP: Frame Pointer
r10 = SL: Stack limit (stack checking variants)
r9 = SB: Static Base (PID/reentrant/shared library variants)
r7 = WR: Thumb work register

There are other synonyms as well.

- John

> -----Original Message-----
> From: Damian Yerrick <d_yerrick@...>
> [mailto:d_yerrick@...]
> Sent: 26 February 2003 18:13
> To: gbadev@yahoogroups.com
> Subject: [gbadev] Re: arm-agb-elf arm-thumb-elf arm-elf (O.O)
>
>
> --- In gbadev@yahoogroups.com, "Dave Murphy" <wintermute2002@n...>
> wrote:
> > couple of things I had on my todo list :-
> >
> > o Put together agb headers from Martin Korth's GBAtek document -
> > http://www.work.de/nocash/gbatek.htm
>
> I'm not so sure.  A header file would be a good idea, but using
> the purported official register names may get one in trouble
> with trade secret law.

I'm not sure that this would be a problem given that so much information is
now publically available. How do we know Martin's docs are the purported
official names for instance?

> And while we're on the msys/GNU track, I
> would also investigate developing 'gbzip', a GBA-lz77 compressor
> with roughly the same command line syntax as gzip, and including
> it in the distribution.

this one I'd say would be a good plan given the regular questions that
appear here about this.

> > o make an attempt to reduce Newlib by stripping the stuff which
> > just isn't applicable to a console environment.
>
> This would be mostly fopen() and friends, right?  But if I were
> changing newlib, I would add some way to perform stdio over the
> serial port in UART mode or over the emulators' interfaces.

Definitely considering this one, along with console type stuff for the Xboo
cable. This one could be a little sticky legally speaking - I'm fairly sure
open sourcing the multiboot protocol layer would be a big no no.


> > o possibly collaborate with the SGADE team with a view to
> > providing their libs as standard
>
> Any library provided with devkitadv should be non-copylefted
> free software.
>
> > o investigate the possibility of integrating gp32 within the same
> toolchain

> So what command line switch would you use to switch between a
> basic GBA crt0/linkscript and one for the GP32?

-b arm-agb-elf / -b arm-gp32-elf perhaps

http://gcc.gnu.org/onlinedocs/gcc-3.2.2/gcc/Target-Options.html#Target%20Opt
ions

Ken,

Here's some info.

SP = R13
LR = R14
SL = R10
FP = R11
IP = R12

There are some more that are occasionally used.

SB = R9
V6 = R9
V7 = R10
PC = R15

Guido Henkel, CEO
G3 Studios - http://www.g3studios.com

   ----- Original Message -----
   From: krozinsky <krozinsky@...>
   To: gbadev@yahoogroups.com
   Sent: Wednesday, February 26, 2003 3:39 PM
   Subject: [gbadev] Still learning assy


   Hello,

   I'm still trying to figure out all the ARM assy stuff and have a
   question that I can;t find an answer to in their docs.

   I've been looking as the .s files generated from my c code and notice
   the following register names being used: sp, lr, s1, fp, ip

   I know that sp maps to r13 and lr to r14 but which registers are the
   others mapping to?

   Regards

   Ken




         Yahoo! Groups Sponsor
               ADVERTISEMENT




   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Hello,

I'm still trying to figure out all the ARM assy stuff and have a
question that I can;t find an answer to in their docs.

I've been looking as the .s files generated from my c code and notice
the following register names being used: sp, lr, s1, fp, ip

I know that sp maps to r13 and lr to r14 but which registers are the
others mapping to?

Regards

Ken

> > Is there anything wrong with this approach?
>
> Nothing wrong with it.  I just think that my approach is
> better.  Many
> people have said how nice it is that you do not have to mess
> with crt0.S
> and lnkscripts unless you want to with DevKit Advance.  I
> believe that is
> why was (is?) popular.

I totally agree with this. Even though I have learned to understand
linkerscripts and crt0.S startup files, I remember it was a real pain in the
beginning. Most people probably don't even know what they do, and would be
left totally stuck if there were no defaults.


> >  Is there an easier way to have the one cross compiler work for the
> > gba, gp32, and generic arms and allow stdio (syscalls), crt0, and
> > linker script customization?
>
> I'm not exactly sure what you mean.  A generic, out of the
> box, arm-elf
> compiler will work exactly like DevKit Advance if you give it
> the right
> options.  I've just tried to reduce the number of options you
> have to give
> it to get working results.

I use devkitadvance for gp32 development. I easily compiled all the gp32
devkit examples using devkitadvance. Just added this "-mtune=arm920", and
used jeff's crt0.S and linkscript for gp32 instead.


Jason, may I just ask what's wrong with cygwin? Why are you moving away from
that? I guess I miss something, but I use it for more than gba development
with not many problems.

Regards,
Andreas Thorsén

On the newlib side of things... I'm not familiar with newlib, so some if
this may be
off the wall, but if it sparks some ideas, I'll be happy :)

There was posted here a while back info about a GBA "file system" whereby
you could
paste binary files onto the end of a ROM image and the file system code
could look
stuff up by name.  Perhaps some of the newlib file i/o functions could be
made to
use this or something similar.

Also, if someone comes up with a cartridge and/or SIO interface to MMC or SD
memory cards, having access to these via the file i/o functions would be
great.
Also, the game save RAM would be a good candidate for file i/o functions--
perhaps with a special device identifier /dev/saveram/...

Just some thoughts about how the standard IO functions could have useful
application in the GBA rather than just yanking them from newlib.

A Question about newlib.... How granular is it?  People often state, "Oh,
that code is in a library so it'll only be linked in if it's needed."  In
actually
the library granularity for linking is the .o file. Unless the library is
built with
one function per .o file (or one function tree where the top function is the
one someone would call and all other functions in that .o file are required
if it is used), you will get dead library code eating up your RAM.  For
example (and it may be a bad example, I don't know if these are packaged
together) if malloc, calloc, free, and realloc are all packaged together,
you will
have all four of them linked even if you only use malloc/free.

This .o granularity is something that modern C++ compilers (Microsoft,
Borland, and others) have done away with since the mid-90's.  Function-level
linking is one of the things that has turned C++ from a bloat-producing
language into a language that can be used in production environments since
you can use classes that have lots of generic features and not pay the price
for the ones you don't use.

- John

On Wednesday 26 February 2003 22:54, Jason Wilkins wrote:

> >  Is there an easier way to have the one cross compiler work for the gba,
> > gp32, and generic arms and allow stdio (syscalls), crt0, and linker
> > script customization?

i am using devkitadv for both gba and gp32 in parallel, using my own
linkerscripts,crt0 etc. works great as far as i can tell :O)

in practise, if you want to use gcc for developing on different targets in
parallel (targets that share the same cpu/gcc that is) you are probably
always better off doing the above (explicitly link stuff manually that you
want etc) unless someone comes up with a port of gcc that cleanly allows to
switch between targets using the -m switch. (the r3000 port may be an example
for this, among others)

gpz

On Wed, 26 Feb 2003, David Welch wrote:
>
> This may all be beaten to death already, perhaps not, I too have switched
> to mingw (Thanks Dave Murphy and others) I use my gcc build for both the
> gba and something completely different so I want mine to be a generic arm,
> for the gba use this crt0.s, syscalls.c, libcfunc.c, linker script for that
> arm use another crt0.s, syscalls.c, libcfunc.c and linker script.

There is not such thing as a generic link script or crt0.S

I include one with DevKit Advance which is useful for projects without
special needs, and the source code for those that want to rewrite it and
use something custom.  Making the default useful for many people is better
than making a default that is only useful for people writing for an Angel.

> Basically those files I have identified as problematic for inserting Angel
> SWI calls which I have absolutely no use for and just make life difficult...

As far as I know, I have removed all Angel SWI from DevKitAdvance.  I have
stubbed out all the low level syscalls so that they do nothing.  Sort of
like you described.

> Then each application supplies its own crt0.s, syscalls.c, and libcfunc.c
> and linker script and uses the
> -nostartfiles switch on gcc.

Nothing stops you from doing that.  All devkitadv does is supply a default
which will work most of the time unless you want to do something special.

> Is there anything wrong with this approach?

Nothing wrong with it.  I just think that my approach is better.  Many
people have said how nice it is that you do not have to mess with crt0.S
and lnkscripts unless you want to with DevKit Advance.  I believe that is
why was (is?) popular.

>  Is there an easier way to have the one cross compiler work for the gba,
> gp32, and generic arms and allow stdio (syscalls), crt0, and linker
> script customization?

I'm not exactly sure what you mean.  A generic, out of the box, arm-elf
compiler will work exactly like DevKit Advance if you give it the right
options.  I've just tried to reduce the number of options you have to give
it to get working results.

> Also I started added a define of HAS_INIT_SECTION to gcc/config/arm/elf.h
> probably starting with gcc 2.95.2, just a bad habit I guess (was trying to
> kill off Angel and any other unused, excess code), I dont see anyone else
> doing it, perhaps its a useless step?

What does HAD_INIT_SECTION do?  Where exactly are the Angel calls you
speak of?  I am sure I exorcised them from DKA.  I just edited out all the
SWI calls from syscalls.c and removed the interupt table stuff.

> I dont need/want to use any defaults...

I've always said that devkitadv is never supposed to get in your way.
Having functional defaults does not get in your way.  I cannot help but
feel that you would rather have defaults which do not work, rather than
defaults that a lot of people might use.  I could include defaults which
cause the gameboy to emit a high screeching sound if you tried to use
them, but it really makes no difference to you because you do not use
them.  Maybe I am just imagining that you are complaining.

The only problem I can see you having would be if I made
arm-agb-elf-newlib depend too much on the default lnkscript and crt0.S.
Rest assured that I will document the dependencies and write a bare bones
example lnkscript and crt0.S so that anyone who wants to make their own
custom stuff, can still use arm-agb-elf-newlib as long as they make sure
to do a couple of things.

The only dependence I can think of right now is exporting a symbol so that
newlib knows where the bottom of the heap is.


> David
You are both named David!!!! ^_^

>

>
> At 07:05 AM 2/26/2003 -0500, you wrote:
> >----- Original Message -----
> >From: "Dave Murphy" <wintermute2002@...>
> >
> >[...]
> > > o make an attempt to reduce Newlib by stripping the stuff which just isn't
> > > applicable to a console environment.
> >
> >what kind of stuff are you thinking about stripping out?  although i
> >override malloc/free and a few str* routines for speed, i make heavy use of
> >stdlib in my day-to-day code at work.  i am investigating the possibility of
> >using devkit-advance or your port of gcc 3.2, and having useful stuff
> >stripped out could prove to be a stumbling block.  i would recommend leaving
> >most of it in -- it is a library after all, and stuff you don't use won't
> >get linked in.  ;)
> >
> > > o possibly collaborate with the SGADE team with a view to providing their
> > > libs as standard
> >
> >again, another thing i would recommend against.  one of the things i liked
> >about your distribution as opposed to devkit-advance is that it does not
> >build jeff frohwein's crt0.s and ldscript into the toolchain.  these startup
> >files prove problematic, and although overridable, it's nice to see the
> >default barebones versions built into the tools.  providing a link to the
> >startup files / SGADE in the documentation should be sufficient.  these
> >things can be easy for users to add, yet get difficult for others to
> >decouple once they make their way into the distributions.
> >
> >just my twopence.
> >
> >regards,
> >matthew.
> >
> >
> >
> >
> >
> >
> >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

--
            The Phoenix - NekoCo - The Artistic Intuition Company
DevKitAdvance*MirrorReflex*Teapot*PhoenixQuake*Caelius*Zen-X*InfiniteRealms

--- In gbadev@yahoogroups.com, "Dave Murphy" <wintermute2002@n...>
wrote:
> couple of things I had on my todo list :-
>
> o Put together agb headers from Martin Korth's GBAtek document -
> http://www.work.de/nocash/gbatek.htm

I'm not so sure.  A header file would be a good idea, but using
the purported official register names may get one in trouble
with trade secret law.

> o add libs for the BIOS called as detailed above

This is a good idea.  Make sure to override signed / and % with
calls to BIOS divide.

And while we're on the msys/GNU track, I
would also investigate developing 'gbzip', a GBA-lz77 compressor
with roughly the same command line syntax as gzip, and including
it in the distribution.

> o make an attempt to reduce Newlib by stripping the stuff which
> just isn't applicable to a console environment.

This would be mostly fopen() and friends, right?  But if I were
changing newlib, I would add some way to perform stdio over the
serial port in UART mode or over the emulators' interfaces.

> o possibly collaborate with the SGADE team with a view to
> providing their libs as standard

Any library provided with devkitadv should be non-copylefted
free software.

> o investigate the possibility of integrating gp32 within the same
toolchain

So what command line switch would you use to switch between a
basic GBA crt0/linkscript and one for the GP32?

--
Damian

This may all be beaten to death already, perhaps not, I too have switched
to mingw (Thanks Dave Murphy and others) I use my gcc build for both the
gba and something completely different so I want mine to be a generic arm,
for the gba use this crt0.s, syscalls.c, libcfunc.c, linker script for that
arm use another crt0.s, syscalls.c, libcfunc.c and linker script.

Basically those files I have identified as problematic for inserting Angel
SWI calls which I have absolutely no use for and just make life difficult...

Essentially I neuter those files
mv crt0.S crt0.Sorig (just in case)
touch crt0.S  (create an empty file so I dont have to mess with the
configure or make process)
mv syscalls.c syscalls.corig
touch syscalls.c
etc...

Then each application supplies its own crt0.s, syscalls.c, and libcfunc.c
and linker script and uses the
-nostartfiles switch on gcc.

Is there anything wrong with this approach?  Is there an easier way to have
the one cross compiler work for the gba, gp32, and generic arms and allow
stdio (syscalls), crt0, and linker script customization?

Also I started added a define of HAS_INIT_SECTION to gcc/config/arm/elf.h
probably starting with gcc 2.95.2, just a bad habit I guess (was trying to
kill off Angel and any other unused, excess code), I dont see anyone else
doing it, perhaps its a useless step?

I started using arm-thumb-elf instead of arm-elf I guess because of an
email from Jeff way back when, thought it might make a difference, it
"SAYS" more to me than arm-elf does or arm-unknown-elf, so I like it...just
my two cents, again I supply my own linkerscript, etc at application
compile time so I dont need/want to use any defaults...

David



At 07:05 AM 2/26/2003 -0500, you wrote:
>----- Original Message -----
>From: "Dave Murphy" <wintermute2002@...>
>
>[...]
> > o make an attempt to reduce Newlib by stripping the stuff which just isn't
> > applicable to a console environment.
>
>what kind of stuff are you thinking about stripping out?  although i
>override malloc/free and a few str* routines for speed, i make heavy use of
>stdlib in my day-to-day code at work.  i am investigating the possibility of
>using devkit-advance or your port of gcc 3.2, and having useful stuff
>stripped out could prove to be a stumbling block.  i would recommend leaving
>most of it in -- it is a library after all, and stuff you don't use won't
>get linked in.  ;)
>
> > o possibly collaborate with the SGADE team with a view to providing their
> > libs as standard
>
>again, another thing i would recommend against.  one of the things i liked
>about your distribution as opposed to devkit-advance is that it does not
>build jeff frohwein's crt0.s and ldscript into the toolchain.  these startup
>files prove problematic, and although overridable, it's nice to see the
>default barebones versions built into the tools.  providing a link to the
>startup files / SGADE in the documentation should be sufficient.  these
>things can be easy for users to add, yet get difficult for others to
>decouple once they make their way into the distributions.
>
>just my twopence.
>
>regards,
>matthew.
>
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

On Wed, 26 Feb 2003, Dave Murphy wrote:

> Newlib accounts for a great deal of the download size currently weighing in
> at a shade over 20MB for my build.

Wow, how did this happen?  For devkit advance release 4, the newlib
package is only 4 megabytes.

This is Jason...

On Wed, 26 Feb 2003, matthew conte wrote:

> i would recommend leaving
> most of it in -- it is a library after all, and stuff you don't use won't
> get linked in.  ;)

Actually, some useless stuff does get linked in.  I myself never planned
on removing any functions which could be implemented in some way (and I
left in stubs for functions which do not work).  But, I do plan on
reducing or eliminating the footprint of linking with newlib.

> > o possibly collaborate with the SGADE team with a view to providing their
> > libs as standard
>
> again, another thing i would recommend against.  one of the things i liked
> about your distribution as opposed to devkit-advance is that it does not
> build jeff frohwein's crt0.s and ldscript into the toolchain.

?????

This is odd.  If you use your own link script, then it does not matter
whether you use devkit advance or not.  Having the scripts and crt0.s be
the default would neither be a plus nor a minus.

> these startup files prove problematic,

How?

If you are going to override them, then who cares.  If you are not, then
any problems you see are bugs, and I can fix them.  Tell me what they are.


> and although overridable, it's nice to see the default barebones
> versions built into the tools.

The default versions are not barebones!  They are actually quite bloated
and do not work at all with the gba.  Why is having a useless script built
into the linker an advantage over having one that is usable for most
projects?

I'm kinda baffled by this.  DevKit Advance gives you a choice of whether
to override or not.  A plan vanilla arm-elf compiler **forces** you to
override it.

The built in the default arm-elf scripts is like having a car with jelly
donuts for tires.  They are useless for driving so you have to change
them.  The tires I provide may be basic whitewalls which will get your
from here to there ok, but if you want to slap some custom 20 inch gold
plated dubs on it, I'm not stopping you.

> providing a link to the startup files / SGADE in the documentation
> should be sufficient.  these things can be easy for users to add, yet
> get difficult for others to decouple once they make their way into the
> distributions.

I do not quite understand what you mean by coupling.  It is not like they
could not just be removed.  The compiler does not depend on the user
libraries.

I myself, only planned on distributing a library which allows you to fully
use the features of the DevKit Advance linker script and crt0.S (overlays,
variable placement, etc), as well as a header to define all the hardware
registers and memory ranges to get people started faster.  But, by no
means would it be anything except an extra 200k download for those that
download a full install, and no extra for those that install from
packages.

It could not get in the way because you would still have to tell the
compiler to link it in:

gcc game.c -o game.elf -ldevkitadv

I also wanted to include a basic tool for dealing with binary data.
Although I am sure that has been done to death by now.

Hmm, I also wanted to include any functions which would require that
someone use assembly language, or very obtuse C code.

Also, any functions which can be used to access special debugging features
built into emulators.  For instance, I may make newlib stdio functions
actually work through an emulator for outputting debug information.

Anything higher level than this I would want to leave to the other
libraries, or I would create a library and keep it seperate from
devkitadv, but dependent on it.

Actually, I am not interested in a middle level library which is not quite
a full game engine but is also not just a thin layer just above assembly
language.  Such middle level libraries are too general I think, if I
create a high level library, it will be a set of routines that I am
actually using in a game.  Not a set of routines which I think someone may
find useful one day.

> just my twopence.
>
> regards,
> matthew.
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

--
            The Phoenix - NekoCo - The Artistic Intuition Company
DevKitAdvance*MirrorReflex*Teapot*PhoenixQuake*Caelius*Zen-X*InfiniteRealms

> -----Original Message-----
>
> [...]
> > o make an attempt to reduce Newlib by stripping the stuff which
> just isn't
> > applicable to a console environment.
>
> what kind of stuff are you thinking about stripping out?  although i
> override malloc/free and a few str* routines for speed, i make
> heavy use of
> stdlib in my day-to-day code at work.  i am investigating the
> possibility of
> using devkit-advance or your port of gcc 3.2, and having useful stuff

all being well now Jason is moving to minsys they should both end up being
the same thing :)

> stripped out could prove to be a stumbling block.  i would
> recommend leaving
> most of it in -- it is a library after all, and stuff you don't use won't
> get linked in.  ;)

Newlib accounts for a great deal of the download size currently weighing in
at a shade over 20MB for my build. There are quite a few things in newlib
which have no relevance to GBA development such as file IO, code relating to
POSIX environments. The directory arm/arm-agb-elf/lib of my current build
accounts for 58MB of the final install alone :/ I thought it might be worth
attempting to reduce this although another option is to have an installation
script compile these from source.

> > o possibly collaborate with the SGADE team with a view to
> providing their
> > libs as standard
>
> again, another thing i would recommend against.  one of the things i liked
> about your distribution as opposed to devkit-advance is that it does not
> build jeff frohwein's crt0.s and ldscript into the toolchain.
> these startup
> files prove problematic, and although overridable, it's nice to see the
> default barebones versions built into the tools.

I much prefer it this way myself but I've had a few comments about my
toolchain not being able to generate gba binaries without the custom files.
I do feel that it's a little awkward to set up crt0 suitably given the
amount of conditional code in there. I've also noticed a tendency for
example code around to have things like interrupt tables directly in there.
Perhaps it comes down to personal preference but I do feel that this
practice is a poor coding standard.

> providing a link to the
> startup files / SGADE in the documentation should be sufficient.  these
> things can be easy for users to add, yet get difficult for others to
> decouple once they make their way into the distributions.


fair point - this one was my little rebellion against HAM and closed source
libraries in general. Fair enough if we're talking about proprietary cutting
edge technology with a lot of research & development  ... pre-emptive
</rant> :)

thanks for the input

Dave

----- Original Message -----
From: "Dave Murphy" <wintermute2002@...>

[...]
> o make an attempt to reduce Newlib by stripping the stuff which just isn't
> applicable to a console environment.

what kind of stuff are you thinking about stripping out?  although i
override malloc/free and a few str* routines for speed, i make heavy use of
stdlib in my day-to-day code at work.  i am investigating the possibility of
using devkit-advance or your port of gcc 3.2, and having useful stuff
stripped out could prove to be a stumbling block.  i would recommend leaving
most of it in -- it is a library after all, and stuff you don't use won't
get linked in.  ;)

> o possibly collaborate with the SGADE team with a view to providing their
> libs as standard

again, another thing i would recommend against.  one of the things i liked
about your distribution as opposed to devkit-advance is that it does not
build jeff frohwein's crt0.s and ldscript into the toolchain.  these startup
files prove problematic, and although overridable, it's nice to see the
default barebones versions built into the tools.  providing a link to the
startup files / SGADE in the documentation should be sufficient.  these
things can be easy for users to add, yet get difficult for others to
decouple once they make their way into the distributions.

just my twopence.

regards,
matthew.

> -----Original Message-----
> From: Jason Wilkins [mailto:fenix@...]
> Sent: 26 February 2003 06:24
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] arm-agb-elf arm-thumb-elf arm-elf (O.O)
>
>
> Oh no, I'm not objecting at all!  I was just saying that for
> consistencing,
> no one should use arm-agb-elf unless they are building devkit advance.  I
> would have named it something less general (arm-devkitadv-elf) if I had it
> to do again.  The name sort of betrays my goal of becoming the defacto
> standard for hobby developers.  My ambition and actual efforts are closer
> now.

just checking :) Now that you've decided to move to minsys there's probably
more to be gained from collaboration - compiling gcc for anything not
already natively supported is a complete pain as I'm sure you know :)

couple of things I had on my todo list :-

o Put together agb headers from Martin Korth's GBAtek document -
http://www.work.de/nocash/gbatek.htm
o add libs for the BIOS called as detailed above
o make an attempt to reduce Newlib by stripping the stuff which just isn't
applicable to a console environment.
o possibly collaborate with the SGADE team with a view to providing their
libs as standard
o investigate the possibility of integrating gp32 within the same toolchain

The last one may be a pain - I was hoping it might be possible to use the
same basic tools for gp32 with little modification given that the agb
targeted compiler can produce code for the ARM920 with no modification.

Is it possible to grab your latest source from somewhere? Now you've got it
working with minsys it probably makes more sense to use the same build
system.

Dave

Oh no, I'm not objecting at all!  I was just saying that for consistencing,
no one should use arm-agb-elf unless they are building devkit advance.  I
would have named it something less general (arm-devkitadv-elf) if I had it
to do again.  The name sort of betrays my goal of becoming the defacto
standard for hobby developers.  My ambition and actual efforts are closer
now.

Anyway.  I have finally managed to get all the bugs worked out of the MinGW
build of DevKit Advance, and release 5 should be based on MinGW instead of
cygwin.

I will be producing a beta soon.

We need to see if our goals are so different that we cannot work on one
compiler together.  It would be a shame to duplicate efforts, especially if
I just spent a week banging my head up against building in msys and you
already cracked it ^_^



----- Original Message -----
From: "Dave Murphy" <wintermute2002@...>
To: <gbadev@yahoogroups.com>
Sent: Sunday, February 23, 2003 5:52 PM
Subject: RE: [gbadev] arm-agb-elf arm-thumb-elf arm-elf (O.O)


>
>
> > -----Original Message-----
> > From: Jason Wilkins [mailto:fenix@...]
> > Sent: 23 February 2003 11:58
> > To: gbadev@yahoogroups.com
> > Subject: Re: [gbadev] arm-agb-elf arm-thumb-elf arm-elf (O.O)
> >
> >
> > This may be old, but I've been out of the loop for a while ^_^.
> > There was a
> > thread a few months ago concerning the difference between arm-elf,
> > arm-unknown-elf, and arm-agb-elf.
> >
> > From: "Dave Murphy" <wintermute2002@...>
> >
> >
> > > the center of the name has absolutely no meaning whatsoever.
> >
>
> It's so old I can't find the relevant message on my system :/ I'm
relatively
> sure it's completely out of context.
>
> The accepted naming convention appears to be <cpu>_<vendor>_<os>, in some
> cases it appears to be <cpu>_<machine>_<output format>. Essentially you
can
> put whatever you like in there and alter build scripts to pay attention to
> those values.
>
> If you're objecting to my use of arm-agb-elf in the mingw variant then say
> so. However I would like to say that it's not meant to be a competing
> product but rather an extra flavour. Personally I don't like cygwin & I'd
> rather use minsys, if others feel the same way then it's there for them to
> use.
>
> Currently there are some differences but my ultimate goal was for this to
be
> the MinGW variant of DKA much as there's a linux variant for people who
use
> that OS. The next step is getting the problem with hard coded paths sorted
> in my build then to apply some of your patches to set the default crt0 &
> linkscript.
>
> At the end of the day both builds are ARM targeted gcc for use in
developing
> agb software.
>
>
> Dave
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

> -----Original Message-----
> From: Jason Wilkins [mailto:fenix@...]
> Sent: 23 February 2003 11:58
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] arm-agb-elf arm-thumb-elf arm-elf (O.O)
>
>
> This may be old, but I've been out of the loop for a while ^_^.
> There was a
> thread a few months ago concerning the difference between arm-elf,
> arm-unknown-elf, and arm-agb-elf.
>
> From: "Dave Murphy" <wintermute2002@...>
>
>
> > the center of the name has absolutely no meaning whatsoever.
>

It's so old I can't find the relevant message on my system :/ I'm relatively
sure it's completely out of context.

The accepted naming convention appears to be <cpu>_<vendor>_<os>, in some
cases it appears to be <cpu>_<machine>_<output format>. Essentially you can
put whatever you like in there and alter build scripts to pay attention to
those values.

If you're objecting to my use of arm-agb-elf in the mingw variant then say
so. However I would like to say that it's not meant to be a competing
product but rather an extra flavour. Personally I don't like cygwin & I'd
rather use minsys, if others feel the same way then it's there for them to
use.

Currently there are some differences but my ultimate goal was for this to be
the MinGW variant of DKA much as there's a linux variant for people who use
that OS. The next step is getting the problem with hard coded paths sorted
in my build then to apply some of your patches to set the default crt0 &
linkscript.

At the end of the day both builds are ARM targeted gcc for use in developing
agb software.


Dave

This may be old, but I've been out of the loop for a while ^_^.  There was a
thread a few months ago concerning the difference between arm-elf,
arm-unknown-elf, and arm-agb-elf.

From: "Dave Murphy" <wintermute2002@...>


> the center of the name has absolutely no meaning whatsoever.

Actually, the center of the name does have meaning.  Different middle parts
can tell the build process for gcc or binutils to do slightly different
things.  If it does not recognize it, then it just treats it like it says
'unkown' but if it does recognize it, then it can include different setups.

I decided to use arm-agb-elf as the target for the gameboy advance.  This
target is recognized by the changes I made to binutils and newlib.  If you
are compiling the source for devkitadv then you will get different results
if you specify arm-elf or arm-agb-elf.  If you are not compiling the source
for devkitadv, then you will get a compiler that claims to be arm-agb-elf,
but is really just the same as arm-elf (only DevKit Advance can be
arm-agb-elf, maybe I should have chosen arm-devkitadv-elf, but I was there
first ^_^)

arm-thumb-elf is a bogus target.  The build process does not recognizes it
and treats it exactly like arm-elf (or arm-unknown-elf, which is the long
form)

arm-agb-elf will build in an appropriate link script for ld, and will build
in an appropriate implementation of _sbrk into newlib so that malloc will
work.