I love this stuff. Not that I use tigcc, just love it when people do great things like this. Too nifty.

I don't see anybody else commenting on this yet... (fc?)

Oh boy, now we have an abbrev. for first comment....n/o - anyways, this is an ASM program developer pack, right?

amicek

For a BASIC developer pack, please consult your manual.

--BlueCalx

You can forgive a little ignorance, right?

amicek

why is abbreviation such a long word?

Finally I can write a real ASM Drugwars game. Woo hoo. I needed it to calculate an appropriate amount of interest on $$ from the loan shark

I wouldn't trust my loan shark to calculate any interest for me.

But that's just my opinion :)

--BlueCalx

No, you can't C is not ASM.

You can. Use switch -S to produce ASM code from C. Then you can say that "you have an assembly source for DrugWars" :-)

This is great news. Now I can make math functions that run 100x faster than basic. Oh, and uh... writing games should now be easier. I think I'm gonna try it out right now

I am not so sure that mathematics can be 100x faster than in BASIC. It will be faster, but don't expect such great factor. Look for example statement like b=sin(a). In both Basic and C (and even in assembler) it will call TIOS "sin" function, and if it is slow, nothing can help. Note that in math programs the greatest time consumers are just slow TIOS subroutines, which can't be avoided even in ASM (expect if you want to make better ones by yourself).

I remembered that before 15 years I have on my "ZX Spectrum" two compilers which translates BASIC to ASM: one with only integer support, and one with floating point support. First one introduces increase in speed by factor 300-900, but second one introduces increase in speed by factor 3-8.

If you want to make a really fast game, listen my hint: avoid floating points in games as much as possible, especially in tight loops. Everything which can be integer need to be an integer. Many floating values may be avoided by scaling with some factor. So, use floats only when really necessary. But, if you write math or engineering application, you very probably can not avoid floats.

You're right about that, and also I've read in various places that using shift operators instead of multiply/divide increases the speed too. As to the speed of the math functions, I exagerated about the 100x part. But I did do a siple experiment a few weeks ago. I wrote two small programs, one in basic and one in C, that invert the screen pixel by pixel, and the basic version took 5 minutes to finish, while the C version finished in a little over 1 second. I guess the ti89 spends most of the processing time interpreting basic comands rather than executing them.

By the way, I forgot to mention that I've been looking at some code for various raycasting engines, and most of them create arrays with the values for trig function and then use the arrays to evaluate trig expressions, so that's one way of doing it if you have a program that uses trig functions a lot.

The technique you were talking about earlier involving multiplication and division using shift operations is called fixed point math, and is quite common. It's an integer representation of a floating point number. It's much faster and is definitely looking into. Also, using an array for holding trig values (i.e. sin and cos) REALLY helps, believe me. My 3d engine used it and the speed increases were just phenominal. The only real problem is that the arrays take up a lot of space, especially for a calculator, so you may just want to limit yourself to using degree increments of 10 or so, instead of 1, say.

Finally, Sweeeet!!

Grayscale for my 89 hw2 :)
For the last eight months I have been deprived of grayscale

Speaking for all hw2 owners
Thank you

I am so thrilled about this that I had to register a username just so I could say how thrilled I am! I love TI-GCC! If I were less busy (or lazy) I'd learn assembly...

BTW, I sure could have used this a week ago. I wanted to write a program to let me convert IEEE 754 floating point numbers between ASCII and binary representation. It was basically intended to be a little helper for a Computer Architecture test I took yesterday. I think I did pretty good without it, though. Besides, I don't even know if the 89 uses IEEE 754. Guess I'll go find out. ;)

-Heavy, heavy Kevin

TI-89 does not use IEEE 754 but SMAP II BCD format. This is why there was so many problems with implementing floats in TI-GCC: the compiler itself generates and expects IEEE 754 floats, but TIOS cannot recognize them...

Yeah, I've dived (doven? Uhhh...) into the docs directory now and read a bit about that.

Now, please keep in mind that I don't know much about what I'm talking about here, but if the calcs just uses foating point emulation, would it be possible to implement IEEE floats & doubles? With conversions to and from this other format? It would be more convienient, but I'm not sure if there would really be any other benefits.

I have no idea how gcc deals with floating point in the m68k, but it seems likely that there are 2 possibilities. 1) Emulation, in which case what I suggest should be feasible. 2) Math coprocessor, in which case what I suggest would be near impossible.

Man, I'm really tired and not thinking clearly right now, so forgive me if none of this makes sense.

Come to think of it, when I attempted to compile a program using foats and doubles the only error I got was in the linker - it was missing a function. I tracked down what that function was for and it turned out to be a float->double conversion. Seems that the program might have worked with that function (which would be fairly simple to write). But like I said, I don't know much about this.

Okay, end of rant.

-Kevin

Huh. I spend more than one month in thinking what is the best. And finnaly, I decided that what I do is the best what it can be done at the moment. If you want to use IEEE floats, you really need to write ALL math functions, starting from add, sub, etc. up to sin, log etc. And note that TIOS sprintf is not happy with IEEE floats. It IS possible to implement IEEE float only by rewriting more than 15K of TIOS to work with IEEE floats, and I really don't want to do this. Better idea will be to MODIFY the GCC compiler to generate BCD floats on "float" and "double" instead of IEEE floats.

You say that calc use fp emulation. Yes it is true, but not in IEEE format. Forget IEEE. TIOS does not know anything about IEEE.

Problem with linker is not so easy as you told about.
You probably tried an example where anything needed is float->double conversion, like if you wrote

float a=2.57;
printf_xy(0,50,str,"%f",a);

But, try the following:

float a,b,c,d,e,f:
a=b+c-d*e/f;

Now the linker will report absence of: addition, substraction, multiplication and division. Nothing can be done with IEEE floats, because TIOS can't do nothing with then. You can say: OK, write this functions: add, sub, etc. But, what about sqr, sin,
asinh, frexp, and much more???

That's why I suggested using ti_float instead of float.
I hope that I am clear enough.

So I take it that there is a 3rd possibility that I didn't think of: emulation, but on the OS level not the compiler/program level. So of course there would be great difficulty getting IEEE to work. I thought that perhaps gcc added the emulation functions inside the program.

-Kevin

GCC has an IEEE floating point emulator package, not as the part of the compiler itself, but as the part of standard library coming with GCC. But, including this package will introduce a big overload to the code, because all functions which already exists in TIOS would be replaced with similar ones (but which use different float format), which need to be embedded in the compiled program. See, I don't want that something like

a=sin(b+c*d/e)^f/tan(asinh(g));

produce 10K of machine code. This is not too big on PC for example, but this IS big on TI-89. By using TIOS functions, similar program produces 100-200 bytes of code.

I forgot to mention yet another reason against IEEE: advanced algebra software routines included in TIOS. All of them expect floats in SMAP II BCD standard. Suppose that you want to calculate

Integrate (x+1.5, x)

At the moment, it is possible with TIGCC. TIOS works with RPN expressions. Rewrite this in RPN as

x x 1.5 + Integrate

So, everything you need to do to calculate such expressions is to push two bytes using push_quantum_pair on estack, to push float number 1.5 using push_Float, to push two bytes again, and finally to call NG_rationalESI to evaluate this. But, float number 1.5 is expected to be SMAP II BCD float number. If I used IEEE floats, in addition to the fact that all float routines must be replaced, you would not be able to use symbolic mathematics at all! So: you CAN NOT use IEEE floats efficiently on the machine where everything in the operating system is programmed to accept only SMAP II BCD floats. That's why I tell: you MUST use BCD floats. Using IEEE on TI-89 is similar like trying to pay something in USA dollars in the country which accepts only German marks.

I realize that TI-OS won't accept IEEE. I'm really just looking for a way to make floating point more convenient. The best idea I can think of so far it to write a parser for TI-GCC that converts all floating point stuff to use the macros that you created. Doesn't sound like an easy task.

By the way, thank you for work on this. It's really terrific.

Better idea is modifying GCC compiler itself and to recompile it. This is possible: its source is available to public, and it has a set of "configuration" files which allow configuring format of various data without analysing the source itself. I know that it IS possible to reconfigure TIGCC by changing ONLY these config files and recompiling the compiler itself. For example, it is neccesary to dsscribe in config files how TI-floats looks like, and to define one function which converts strings to TI-floats (GCC will then use this function during parsing instead of default one). Something about this is written in GCC manual. But, at the moment, I have not enough free time nor knowledge to do this. If anybody is interested to help, please get in contact with me...