ticalc.org
Basics Archives Community Services Programming
Hardware Help About Search Your Account
   Home :: Archives :: News :: Feature: C Programming Editorial

Feature: C Programming Editorial
Posted by Nick on 13 May 2000, 07:06 GMT

Scott Dial of the TCPA (both of which are down because Dim-TI's server is acting up again =[ ) has written our next (belated) feature on C programming on calculators. It's opinionated, so I have to say that Scott's opinions don't reflect my opinion or that of ticalc.org's.


The use of C on a calculator is a horrible waste of space. I love the idea as much as the next guy, but there simply isn't enough space for all the bloated code. GCC doesn't produce the most optimized code by far. *gasp* I understand using it to ruff in some program that you need real quick, but any complex program is going to bloat that much more. I even particurally like the fact that I can port a program for my pc to the 89 relatively easily.

What I can't stand is how many people think that C is so much better than asm... There are some real complex things you can do with C that I would be wary of attempting with ASM, but it still could be done cleaner in ASM. The GCC compiler isn't exactly optimal either. Anyone ever looked at the source (-S) it produces? Who in their right mind would use moveq.l #0,d0 to clear it? It has no clue that there is even a better choice... Or how about it moves values on the local stack that don't even need to be preserved or referenced in that method... movew d0,-2(a6) \ tst.w -2(a6). No one can replace the human mind.

I would hate to see all the programmers of tomorrow using C because it is easier... nothing great is ever easy. C is the lazy mans excuse to not learn to really program the calculator. What's that you say? The AMS was written in C... well yes it was and I hate TI for it. Space is not a luxury on such a small memory capacity. If every new programmer that comes in starts writing everything in C then space becomes even less of a luxury. Long live assembly!

 


The comments below are written by ticalc.org visitors. Their views are not necessarily those of ticalc.org, and ticalc.org takes no responsibility for their content.


Re: Feature: C Programming Editorial
Wolf  Account Info
(Web Page)

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.

     13 May 2000, 07:54 GMT

Re: Re: Feature: C Programming Editorial
Matthew Hernandez  Account Info
(Web Page)

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.

     13 May 2000, 14:59 GMT


Re: Re: Re: Feature: C Programming Editorial
Wolf  Account Info
(Web Page)

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.

     13 May 2000, 16:10 GMT


Re: Re: Re: Re: Feature: C Programming Editorial
bradys9 Account Info

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!!!

     13 May 2000, 20:37 GMT

Re: Re: Re: Re: Re: Feature: C Programming Editorial
Wolf  Account Info
(Web Page)

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.

     14 May 2000, 02:29 GMT

Re: Re: Re: Re: Re: Feature: C Programming Editorial
Paulo Marques  Account Info
(Web Page)

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

Cd_Slayer

     14 May 2000, 02:52 GMT


Re: Re: Re: Re: Re: Feature: C Programming Editorial
Free_Bird Account Info
(Web Page)

BASH was written in C too...

Do not overestimate the non-existing power of C!

     14 May 2000, 22:03 GMT

Re: Re: Feature: C Programming Editorial
Vejita  Account Info
(Web Page)

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

-Corey

     13 May 2000, 22:28 GMT


Re: Re: Feature: C Programming Editorial
Alan Rudolph  Account Info
(Web Page)

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

     13 May 2000, 23:43 GMT

Re: Feature: C Programming Editorial
Patrick Davidson  Account Info
(Web Page)

> 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.

     13 May 2000, 07:57 GMT


Re: Re: Feature: C Programming Editorial
Andrew Magness  Account Info
(Web Page)

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.

     13 May 2000, 15:35 GMT

Re: Re: Re: Feature: C Programming Editorial
Andy Selle  Account Info
(Web Page)

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.

     13 May 2000, 18:15 GMT


Re: Re: Re: Feature: C Programming Editorial
Blue_Z  Account Info
(Web Page)

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 ?

     13 May 2000, 22:04 GMT


Re: Re: Re: Re: Feature: C Programming Editorial
Andy Selle  Account Info
(Web Page)

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)

     14 May 2000, 01:48 GMT


Re: Re: Re: Re: Re: Feature: C Programming Editorial
JaggedFlame

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.

     14 May 2000, 03:59 GMT


Re: Re: Re: Re: Re: Re: Feature: C Programming Editorial
Andy Selle  Account Info
(Web Page)

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...

     14 May 2000, 04:11 GMT


Re: Re: Re: Re: Re: Re: Re: Feature: C Programming Editorial
Cliff

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*

     14 May 2000, 10:42 GMT


Re: Re: Re: Re: Re: Re: Re: Re: Feature: C Programming Editorial
Andy Selle  Account Info
(Web Page)

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. :)

     14 May 2000, 16:45 GMT


Re: Re: Re: Re: Re: Re: Re: Re: Re: Feature: C Programming Editorial
Niklas Brunlid  Account Info
(Web Page)

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...)

     15 May 2000, 20:14 GMT


Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Feature: C Programming Editorial
Rudi.83g  Account Info

_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.

     22 August 2000, 14:19 GMT

Re: Feature: C Programming Editorial
johnmcd3

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?

     13 May 2000, 08:49 GMT

Re: Re: Feature: C Programming Editorial
Patrick Davidson  Account Info
(Web Page)

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.

     13 May 2000, 09:13 GMT

Re: Re: Re: Feature: C Programming Editorial
EvanMath

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?

     13 May 2000, 17:15 GMT


Re: Re: Re: Re: Feature: C Programming Editorial
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

     14 May 2000, 07:52 GMT


Re: Re: Re: Feature: C Programming Editorial
johnmcd3

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

     14 May 2000, 07:31 GMT

Re: Re: Feature: C Programming Editorial
Jonah Cohen  Account Info
(Web Page)

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.

     13 May 2000, 15:35 GMT

Re: Re: Feature: C Programming Editorial
johnmcd3

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.

     14 May 2000, 07:48 GMT


Re: Re: Re: Feature: C Programming Editorial
Patrick Davidson  Account Info
(Web Page)

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

     14 May 2000, 10:09 GMT


Re: Re: Feature: C Programming Editorial
johnmcd3

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.

     14 May 2000, 08:42 GMT

1  2  3  4  5  6  

You can change the number of comments per page in Account Preferences.

  Copyright © 1996-2011, the ticalc.org project. All rights reserved. | Contact Us | Disclaimer