I don't program in anything for the calculator beyond TI-86 BASIC, so I know first-hand about the space limitations of calcs. Some news beats no news, but I think there should be a better topic than the space limits on a calculator, and C programming. Stick with ASM or BASIC, and drop all that C crap :)
How about this, don't put up a news item unless it has to do with a wider public. This is focused of TI-89 and C programming. I do TI-86 and VB, so I have close to no idea what you're talking about:)

PS: Visit my webpage. Just couldn't help myself to not put it in!

Happy coding.

Wolf.

Remember that this site is "tiCALC.org"...not "ti-86.org". You have to understand that there are many little pockets of people and what they can relate to. I, for example, don't go beyond the 83+, but I still read up in the other calculator news. The world is quite large, as is the audience of ticalc.org. I don't truly think you could ever get a news article that related to every single person that comes here! If you think differently...share your thoughts (via e-mail of course)...

Matt H.

I suppose I wwent a little overboard with that, but I haven't seen a good article or a major release of a program for the TI-86, so I am prone to blow my top once in a while. Consider this as an inderect apology to evryone that thinks that ticalc.org is a better job than ever. I like the website and the people behind it, but sometimes they bug me.

If you want to program in C, do it on your computer, and don't port it to you measely calculator. Just my opinion, but I did have to comment on the article.

Look kid you obviously don't understand what C does. With C I was able to build a program in 2 minutes which took me 2 hours to do in Assembly. And as for BASIC??? What use is Basic. It just plain sucks. If you want to program Basic do it on YOUR freakin computer and keep to yourself.
What do you think the C language is translated into when it is compiled for the calculator, ASSEMBLY.
I have no idea why you apoligized to everyone then continued to bash on C. If I were you I would keep to myself if I didn't know what I was talking about.

Thanks :)
Don't underestimate the power of C!!!

I was talking not to those that bash C, but to those that bash ticalc.org's news items. I program in C, and I do know what it can do, but C is for the computer, not the calculator. Now if only you could take out your anger somewhere else, that would be real nice!

Wolf.

Not everyone gets that your joking a little on your comment, and that makes flamming common. Ease up a little too.

Cd_Slayer

BASH was written in C too...

Do not overestimate the non-existing power of C!

I agree with the fact that a lot of these article are blah. But who cares right?

-Corey

No one is being forced to come here... I don't know why people are upset about the news.

> Who in their right mind would use moveq.l #0,d0 to clear it?

What would you recommend using instead? This instruction takes up 2 bytes of memory and executes in 4 clock cycles. I'd be really interested in seeing a faster or smaller way to do this.

With that small detail aside, I'd like to ask if you remembered to use the "-O2" switch when compiling; I'm almost sure you didn't as I've never seen anything like that uneeded stack use when it is given. Also, it helps to give the -fomit-frame-pointer option also, as this prevents contstructing unneeded stack frames.

If you like, I can show some examples of its output here that show very good code generation. I am aware of imperfections in its code generation, but human-generated code is usually not perfect either.

clr is just as fast... only 4 clock cycles.... I'm sure theres many other examples where ti-gcc produces questionable code...



Long live asm.

These kinds of oddities are a direct consequence of the differences between hand-crafted assembly and compiled assembly. A language code generator needs to ensure correctness at all costs. That is to say, the code that it generates must be the equivalent of the semantics of the high level language. To this end, code generators use strict algorithms for code translation and register assignment. The results of these are things that many human programmers would not make if they were programming by hand. Optimization within the compiler through heuristics and careful rule-based substitution can be used to improve the code greatly, but there is no way it will ever be at optimum as hand-written code by a master assembly programmer.

Have a look at the url above, it contains the exact timing for 68K instructions.
And it appears that you're wrong. Clr.l d0 takes 6 cycles, not 4, so GCC is more than right since moveq.l #0,d0 actually takes 4 cycles. However, as assembly programmers, you and Scott would have make the mistake, wich brings the following question : is a compiler able to produce better code than a human programmer ? Considering this example, I would answer yes...

So, long live C ?

In general, the statement that a compiler can create faster code is not true. The examination of a single instruction isn't a representative way of proving this assumption of yours either. The major limitation of the compiler is not being able to optimize in ways that are more difficult than simply choosing the quickest instruction for a task. Often, an optimization involves using a completely different approach. The advantage and the ability to determine this other approach is more readily available to the human. Computers have the limitation that they usually cannot make creative decisions, which as any skilled assembly programmer (or programmer in generla) is where the most radical and profitable optimization occurs. To quote Kahn Noonian Singh from the Star Trek episode 'Space Seed': "Improve a machine and productivity may be doubled, but improve man and increase productivity a thousand fold." (well... :) as long as arrogance doesn't count as an improvement)

He didn't say _faster_ code, he said _better_ code. I don't know what he meant by that, but better doesn't always mean faster.

Well there are many criteria to better code. Faster is one of them, but my same arguments apply equally to the others. There is also readable code. Compilers do not produce readable assembly code (even though the source is much more readable). In any case... an optimizer usually able to do two different types of optimizations: faster and bigger size or slower and smaller size. The decision to use these options always involves a tradeoff that must be weighed based on the needs of the program...

In theory (and in my experience, in practice) a compiler -can- produce faster, tighter code than a human, but not -always-. Quickly, algorithmically feeling out all the different instructions to do a certain task, and comparing them with regards to speed, size, and processor component utilization, is a task better left to a machine. However, there are a lot of crappy compilers out there. GCC isn't one of them--it's a tried and true compiler updated constantly. On the other end of the scale, we have MSVB's native code compiler (this isn't a knock against VB, it's one of my favorite languages), which produces objects megabytes in size to do trivial tasks.
C -on- the calculator--silly idea. C to program -for- the calculator, good idea. Anyone who's tried to write a really big program in ASM knows it's difficult. Here are the advantages of a HLL like C:
--Easier to debug large amounts of code
--More modular
--More portable
I didn't say -faster-, because it's true that a human can usually optimize the compiler's code to some degree. But, make sure you check your timing tables before, say, picking a clr.l over a moveq.l. *grin*

In theory, a compiler could be perfectly optimizing, but that assumes that optimizations that have to be made are very simple. The most important optimizations are at the algorithmic level. No C compiler can change the algorithm on the fly. That requires a human. As far as size, assembly programs are almost always smaller. The reason is that C involves a lot of overhead. Managing a complicated call stack, symbol table, heap, etc. is something that uses a lot of memory. Assembly programmers can get by using the processor's stack and using memory with an adhoc (less organized but smaller usage) way. Visual Basic has yet more overhead, because in order to accomplish ease of use they have had to sacrifice size, because they need a lot of libraries loaded that are general purpose in nature. If you are interested in compiling and optimizing, I suggest the Dragon Book (It has a dragon on it). You should be able to find it in a library. It covers, lexical analyzers, context-free grammar's, code generation, and optimization. Additionally, for algorithmic considerations, there is no book better than the Art of Computer Programming by Donald E. Knuth. It is not for the faint heart, but it will teach you tons. :)

Gcc uses the stack for variables to, at least local ones. In a finished program it does not manage any symbol table, and the "call stack" is mainly stack frames designed to make it easy to access local data even if the stack itself is occupied by parameters for deeper calls, or some other data.

Also, if you have to change the algorithm, don't you have to do that in both C and assembly? And in my experience it's a whole lot easier to change high-level stuff like that in C.

For the record, I like both C and assembly, but C beats assembly for large projects, specifically ones with complex data structures. Assembly rules for small, tight code where speed is really needed, and/or when you hit the hardware (greyscale, sprites...)

_I_ think that there is a use of C on a calculator.

1. I bet every assembler programmer uses a C-like calling covention if he calls subroutines, so it cannot be that costly (if the c compiler allows "register int b"-like constructs)

2. In C you've got #defines ("inline" functions in higher languages), for which TASM has no good support. I know you can produce bad code with #defines:
int f(i): int(i) { /* a big chunk of code */ }
#define MAX(x,y) (((x)>(y))?(x):(y))
Now MAX(f(1),f(2)) evaluates f three times and not two times, as good code does. BUT: There are basic C optimization tricks to prevent this ("register int b") so this cannot happen to a good c programmer.

3. Programs are faster written. An important advantage of C.

4. You have got an inline assembler. So write your program in C, "profile" it (I know this is nearly impossible on the TI calcs, but it is possible), and optimize code that is often called by using asm. YOu dont need a function that does
int max (x,y) int(x), int(y)
{
if (x>y) return x; return y;
}
Why not
__ASMFUNC__ int max (a,b) register int(a) register int(b)
// no real c, not fully correct but mostly ok
{
#asm
cp b
ret.nc // no carry/borrow
ld a, b
ret
#endasm
}
?
(OK, you will use a macro here)

5. ASM is error-prone. You do not have a real chance to fix bugs in the algorithm used.

But a serious disadvantage of C, that has to be named is:
-1. You DO HAVE a source-level debugger for asm, but not for C. In C you rely on your compiler not optimizing so that you can recognize your own code.

I know a little c and so I downloaded the ti-gcc and the ti libraries and played around with. They are really cool, as I know no assembly. I was wondering if there are any messageboards, forums, newsgroups, etc. specifically on ti-gcc. What about any tutorials specifically dealing with c on the calculator.
Specifically I was wondering what kind of math stuff you can do. Can you use the calculators symbolic manipulation stuff and preprogramed funtions like derivatives, etc. Also, how do you output a result to the home screen instead of it saying done at the end. Thanks,

John McDowell

P. S. Hey Patrick Davidson, I had an interesting calculator expirience regarding Pheonix 5.2 last week. I 'm not sure if it was Pheonix's fault or not. Here was the situation to the best I can remember. I had just loaded doors and pheonix and a bunch of other assembly games on my calculator and since I have AMS 2.03 (FYI I have HW1) I archived everything so if the calculator crashed it would retain the memory. I kept a copy of the libraries archieve in another directory since they had to be unarchived. I had been playing a bunch of them and I was in Pheonix and i pushed "one point shield recharge" and the calculator crashed. I turned it back on and copied the librayies back out and I did it again to see what would happen and sure enough, the sheild thing in the shop crash the calc. I thought ok, i won't ever push shield recharge again, and recopied the libraries out again. Unfortunantly, my little brother started playing and crashed it the same way except this time it crashed permanantly. Both I and TI over the phone tried many methods to revive it, but to no avail. I sent it in and about 4 days later i had a brand new ti-89. I think the problem was all the archiving messed with AMS 2.03 on HW1, but I am scared to try it again. Anyone else report the shield problem?

Well, I'm very sorry that you've had this problem. I haven't had any reports of the same problem from anyone else. If this happens every time you select that item, something unique must be occuring in your situation, as I'm sure that many people have played beyond that point, and none have reported the problem. Of course, I know that lots of people don't ever report such problems, but something this frequent and certain would probably have been reported by somebody.

Archiving is probably fairly common too (though it does prevent high scores from being saved) and since the program is copied to RAM temporarily to run, it doesn't seem like that would have such drastic effects.

Just out of random questioning, it might help to know exactly which version of Doors though it seems like any combination would have been tried by someone.

More shocking is the permanent damage that appeared to happen; possibly the Flash ROM could have been corrupted, but for this to happen due to a mistake would be extremely unlikely, as its quite a comples process to do it intentionally.

So, I don't really know if it's a problem in Phoenix or not; the sequence of events you described happening certainly suggest that it it, but it's highly unlikely that a random failure would cause this kind of problem.

I play pheonix pretty often, and I've never had it crash on me at all. I use teos, mainly because of the archived library support.

Also, I saw somewhere that if the calc freezes up, you should take out a battery, hold ")" and "(-)", put the battery back in, and continue holding the keys until the screen comes back up. Did you try that, Johnmcd3?

Oh yeah that and a bunch of other wierd voodoo rituals to try to revive it. I thought it was weird that the 1-800-ticares guy had no idea what I was talking about when I mentioned those keypresses. I was really happy with hoe ti delt with it though.

John

Well the problem was definantly in pheonix, but i think there were to many external influences for you to correctly diagnose the problem. I also remember that another assembly game, bigdyna was acting weird. But don't worry about man, I have never had a problem with pheonix before and I was actually quite pleased with how quickly texas instuments delt with the issue; it was no big deal.
While I am talking to you, I (and my other friends who don't lurk on ticalc message boards) wanted to let you know how much we appreciate you taking the time to write such awesome stuff for us out here. The other day someone playing pheonix asked me who takes the time to make this stuff, and I told him and he said, "Well that guy is a stud". Sometimes I think that people on these boards forget how much goes into these projects. Anyway, thanks and I wouldn't worry about the problem.

John

Maybe phoenix just got corrupted in the link transmission, or even when you downloaded it off the web. Test it on VTI before you try it again on-calc, though.

So I take it there are no message boards or places with tutorials to help program this stuff. Thats a shame because I think a lot of people would be interested in it.

Stuff about TI-GCC is often posted on ticalc.org's Assembly-89 mailing list.

I just answered my own question about math stuff, symbolic manipulation, and returning values. It's all included in the library release 1.5. I thought I had gotten it when I downloaded TI-GCC, but it turns out it must be downloaded separately.