Let me be clear: this is not a feature request from _PT. He challenged me (or that's what it seemed like at the time) to write these.
One major weakness of ICE is that there are no floating point math routines.
I finished the floating point adding and subtracting routines and I want to finish the multiplication and division soon.

Also, some misc routines: input and output of floating point numbers, etc.

If I get a sufficient amount of interest, I'll release them with a manual to using them.

The thing with having support for floating point numbers is that it bloats up the size of programs and slows them down. Something I think would be an interesting option would be to somehow have both, like by default, any maths would be done with the floating point routines, but have the possibility for the programmer to specify to keep it down to a certain number of bytes, for example, if the programmer knows that the variable will always take on integer values that will remain bounded under 255, he/she could specify that they would like this to be done with 8 fixed bytes. I think this would be the ideal solution, but that would of course require more work from the compiler and by extension, PT_...

So in fact you mean something like declaring a variable at the beginning of your program, where you specify it's type, i.e. floating point number, 3-byte number or 1-byte number?

Problem is though, that you need to declare it, and that is not even close to BASIC..

Well if it isn't declared, then the compiler can just assume the biggest and slowest type, so that it works if you don't declare them, but there is the option to do so in order to reduce size and increase speed...

You can do a little bit of type inferencing, but it would make compilation times longer. I recommend either dynamic linking, by lugging around the ICEFP library (or whatever you'll call it) as a separate program on the calculator, or by linking only the routines that are specifically used in the program (this is a very simple series of checks that can be done on the compiler, or post-compilation).

You could also make the complexity of the routine a part of the name. For instance, FP_ADD_8, FP_ADD_16, etc.

Sorry. I was unclear in my first post. Because I still haven't found amazing documentation for asm for ez80, I'm actually writing these inside of ICE. The general idea would be to "call"functions that would add, subtract, multiply. To use the functions, your would lose access to one of the lists, but who needs all 6 anyway?To make it actually useful, it'll need to have functions to check greater than, equal to, and such.

It's definitely doable using ExecHex( and some ASM stuff. I only wonder how you would do the input and output stuff? How would you actually use it?

Since based on my tests, ICE is pretty fast, I could (for input of numbers) put getkey and Output( to good use, and having it store the numbers typed in a list until enter is hit, then parsing it. As for output, once again I turn to the Output command, 'cept I use the exponent to decide where to output the decimal. I'm kinda reluctant to turn to ASM (without someone else's help) because part of me thinks its not a good first project

Oh, and if you CompilePrgm( does it allow you to call LBL's in that program?