This is awesome. Now I will go and write my first compiled program: Fractal Explorer for the 89 (with grayscale!). Good job Zeljko!

Well, I am replying myself with this: there is a program called Fractal Explorer that just was uploaded yesterday, by other author. I will try it tonight.

Wacky? Nifty factor? Nick, man, you been living in the 50's?

Nifty is cool! - Wanna hear something 50s?

Whoah man that's choice!

Yup, people used to say "choice" - you know like "choice" meat? well they said choice in place of cool - I think Nick should use "choice" and see what people say

amicek

I need to find a way to use the word "smashing" as an adjective first. :)

--BlueCalx

Yeah, that would draw some interesting repsonses

amicek

"Smashing" is a peachy adjective. Nifty is jus somethin I try and avoid. Smashing is kind of like a guy adjective. It implies Destruction. Doesn't matter what is getting blown to bits, but it'll be cool. :) btw... put up my tilemap engine!

What does this lib do?

I'm not sure - I guess I am out of the "loop" - I suppose that could be a good thing depending on yourviewpoint...

amicek

To see just how fast TI-GCC code is, I conducted a small test, based on the speed of line-drawing routines. I wrote a C program to draw lines myself, and for the assembly program I call Jimmy Mardell's linelib. The programs would draw a line from the center of the screen to each point on the edges. Each line would be drawn 40 times so that it will be slow enough to time easily. The results:

TI-GCC : 32 seconds, 915 lines per second
Assembly : 30 seconds, 976 lines per second

As you can see, GCC does a pretty good job. In this case it came very close to the assembly program. However, there are some problems with this test:

1) I tested it on VTI, not a real calculator, due to link port problems. I think the relative speeds should be about the same, but it would help if someone could test this for me on a real TI-92 Plus.

2) I don't think the two programs used exactly the same algorithm. In particular, I think LineLib is somewhat more precise (as you can observe from a few dots wrong on the display) which gives it a disadvantage; therefore GCC might look somewhat better than it really is here. I may write my own assembly line routine that works exactly the same as the C one for a more precise comparison later.

3) This isn't completely representative of all code you could write, of course.

4) It doesn't compare size, which I don't think I could do fairly on such a small example anyway.

Despite the drawbacks to this test, I think it still is enough to show that TI-GCC shouldn't be ignored. I actually like programming in assembly myself, but this is certainly useful for people who don't. You can download the sources and executable to the test programs from my web page at:

http://pad.calc.org/st.zip

When compiling it, be sure to use the -O2 switch for full optimization. Also, specifiying -S will generate assembly source that you can analyze to see what the compiler does (although not in exactly the same format as A68K uses).

Note that TI-GCC is even FASTER. You probably used DrawLine from "graph.h". Of course, this is an regular way, but this not shows speed of TI-GCC itself, because DrawLine just calls TIOS ROM routine, which is not so optimized. I tried to made draw_line procedure entirely in C, bypassing TIOS completely. When I made the same test using my draw_line, I got the equal speed as in ASM!

Note that -O2 is of vital importance: I forgot to use this in my game creversi. Try to re-compile it with -O2 switch. It will become a half in size, and two to three times faster!!!

Actually, I'm not quite that stupid. The routine being tested is one that I wrote in C. However, as I mentioned above, I don't think that it works in exactly the same way that the assembly one I'm testing uses.

Sorry, I really didn't want to tell that you are stupid :-) No, really no!!! I am really sorry :-(

Sorry for my English but I'm french
I was wandering isn't there an option en GNU compilers to make the compiler generate an ASM source file. Since most (all ?) compilers generate ASM code before producing the actual binaries. You are talking about tests but you're doing them on small exemples. I 'm not sure it's the best way to do performence tests since it's very easy for the compiler to generate neat code on small exemples try using complicated routines with alot of 'if' 'else' stuff and using structs, then you'll see if it's optimise... Another thing ASM for pc is not widely used and even inline ASM is lesser use than before... I learned X86 ASM for optimisation in my 3D engine but I realised I gain very little speed... Especially with 32 bit OS like Win98. I think C is the best langage overall. ASM is good on small platforms or for robotics but not for PC programming... In ten years I doubght anybody will even use inline assembly on a PC...

Simply put switch -S, e.g. type

tigcc -S -O2 example.c

to procuce ASM source (the extension would be .s). This source can be compiled with the assembler coming with tigcc, but not with PlusShell or Doors assemblers, because the source format is slightly different (the main difference is in the fact that tigcc inserts percent sign before names of the registers, for example move.l %d0,%a0.

Well in most cases it will make a difference.Most proffessional people that do c will tell you to use asm for graphics for speed.This is done all the time on computer games and if applied to the TI calculator would make some games much faster.People like speed

THE_BUTCHER points to me at one bug which I made in gray.h in tigcclib: SetPlane function does'n work in DoorsOS mode. Namely, one trick which I used to save 4 bytes in generated code make a colision with Doors mode. But, the bugfix is straightforward. For all users of tigcclib: edit gray.h, find definition of SetPlane, and replace followint part of the definition

((x)?__gp1:__gp0,0xEF007F))

with

((x)?__gp1:__gp0,239,127))

That's all. Thanks, THE_BUTCHER!

I maybe doing something wrong, but even with the changes shown, my grayscale program won't run in doors. When you try to execute the screen flashes, and refreshes. My program is "nostub", but should'nt still run in doors? or is the exit point required?

Does this work on HW2, AMS2.0x?

Yes it does work on all HW versions and all ROM versions including the HW 2\ROM 2 combination. You must write the program in nostub mode and it has to be 8k or smaller due to the restrictions in ROM 2.0x. You can't compile it for Doors (using libraries and stuff) because Doors doesn't run on the HW 2\ROM 2 combination.

-Sean Barnes

To allow running programs larger than 8K in nostub mode (e.g. without any kernels) even on AMS2.03/HW2 combination, I just made a launcher for it, which also accepts optional program arguments. It is very short (300 bytes), written in C. I will release it after some testing (probably at weekend), with the source code, of course.

For allowing execution of programs longer than 8K even in "nostub" mode (e.g. without any kernels) and even on AMS2.03/HW2 combination, I just made a launcher for it which also accepts optional additional program arguments. It is very short (300 bytes), written entirely in C, and independent of any kernel, external library etc. It will be released after a bit of testing (probably at weekend).