Hex- context is everything here. Hex itself is a just a numbering system and it depends entirely upon where it is as to whether the game will interpret it as an instruction on the CPU, a value to be loaded in memory, a value to launch input into a longer set of instructions to generate something else or something else entirely. You can made educated guesses and you can narrow it down using various methods mind you and that is what most of hacking is concerned with.
Float - varies between consoles. Quite often we have no float/decimal places at all, BCD (older consoles liked it), fixed point (the DS uses them extensively) or workarounds (3.5/2.5 == 35/25 or more commonly log tables) to contend with. Float did eventually take over though gamecube is an odd one as floating point performance, not to mention issues with quad, double or single precisions, mean it is taken on a game by game or even section by section basis.
Programming languages in ROM hacking are approached from two ways.
1) Programming tools for hacking purposes. As long as you are not using something like R (made for stats), matlab (more made for maths, engineering and science) or SQL (a database language) you are probably good.
2) Understanding what the original developer was doing. As game consoles are typically low powered devices compared to the PC of the day, even today but doubly so on old consoles, this typically means very low level languages though oddities can arise (several commercial DS games of note were made in lua for one, online games can almost do raw SQL, microsoft did XNA which comes from .net and c# which has all sorts of implications and many modern games can be web based). The spectre that looms over it all is assembly programming though- if you are not familiar with the concept it is the thing taken at signals (or with a bit of minor abstraction) as it runs on the hardware.
C - was probably still a dominant language on the gamecube so being able to think in C and translate it back is nice. Whether I would use it for tools is a different matter. Plenty is made in it still and lots was made in it but others might say go a bit higher.
C++ - I like it and it was used in game development. Just for tools you can probably go a bit higher (C# or one of the related languages for instance)
3d languages.... I would rather know about how 3d works from the ground up ( http://www.youtube.com/playlist?list=PL6A7DF3D7866EB076&feature=plpp
) than a language. Beyond that game consoles are not tied to directX or opengl so much either and the 3d hardware not the most advanced so you might find yourself doing things raw. However if you want to make tools then you probably want to be able to speak to opengl or direct3d.
Python. Great for tools, used in a handful of PC games both modern and old and maybe some console ones as well. Probably will not teach you anything about low level coding or how programming at such levels works but its usefulness for tools shines through.
(the learn ? the hard way for python is great and I am told the others are much the same)http://www.youtube.com/watch?v=hE7l6Adoiiw&feature=BFa&list=EC6B940F08B9773B9F
I quite like some of the Apress "beginning" books as well.
D.... someone made a real program in it.... wonders never cease. When you say AX I assume you mean Fzero AX rather than the AX video stuff.
(warning PDF link)
Learn that and maybe an implementation on the DS or something and most things after that are just variations on the theme (different intervals between flags, different flag lengths or splits between read back and length of read bits).
As you seem taken by the gamecube you might as well have the best hardware docs that I know of for it.http://hitmen.c02.at/files/yagcd/yagcd/frames.html
I should also note the gamecube, being an optical media system, has a filesystem for its games which so you can break an iso up into its constituent files where GBA and 16 bit and older were typically bundled into a single file which you got to pull apart.
Actual devkits..... generally we do not suggest using them wholesale if not for licensing concerns then as they are not really that useful as general purpose tools and most modern ones are not that useful as hardware docs either.
I will stop here for the moment as you have probably had to re-evaluate a few things and may wish to change a few questions.