Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: Hot_Dog on April 12, 2011, 01:51:02 pm
-
I've had several people ask me about how well I optimize Correlation, since programmers using it for Ti-Basic programs try really hard to get the most out of their Ti-Basic programs. Although I carry out as many optimizations as I can, I've only programed in ASM for 1.5 years, and therefore I'm not the greatest optimizer on this website. Nonetheless, Correlation displays text faster than Output( and Text( do.
And just like Correlation, ASM programs always run faster than Ti-Basic programs do, even if you're a beginner. So don't feel bad if you don't know how to make your program the fastest it can be. It will still run great, it will still run FAST. Optimization takes practice.
We may offer optimization suggestions, but it's never to critisize...it's to help you get better. So be proud of yourself for writing an already-fast program.
-
Yeah I agree. Of course it's always good to optimize more and more, although it's inevitable that in any language you'll not know every calc84maniac tricks right away.
That said it's also good to ask help in here if you need optimizing help.
-
optimizations as I can, I've only programed in ASM for 1.5 years, and therefore
Only? :P
I agree with you though Hot_Dog, optimization is very hard, Runer112 seems to be a pro at it.
-
Optimizations can be tough to do. Especially when it is not your own code that you are working with. I consider myself good at z80 asm, but I still have difficulty understanding routines written by calc84maniac. One of the things I dislike with z80 asm compared with other asm languages is that optimizations are very tough to master. After only a few months in SH3 I have mastered the few optimizations that are even available to a coder. Making that language very easy to learn once you ignore the user/privilege mode and the displacements.
-
I consider myself good at z80 asm
You're z80man :P
Since I don't know Z80 Assembly very well, I don't know any optimization (except for stuff like ld h,0/ld l,5 could be ld hl,5 and jp to jr when shorter). But tricky ones? I have no idea.
-
To be honest, you won't start optimizing stuff until you know how many t-states and bytes each command is. And don't go memorize it because you need to learn it through experience. The optimizations really start to come when you start rearranging code and taking different approach to tasks. The little trick optimizations wont really save you much time except for in sections of code that get run like 10,000 times per second. Well optimized code is usually created, it's reformed from bad code.
So, what am I saying. Don't worry yourself over little optimizations, fix them if you find them, but mostly for learning purposes. It's with persistent attempts to write good code that you will in fact write good code.
Oh, and IX is slow :P
-
One thing I'm good at is memorizing little tricks to cut off lag (I usually optimize purely for speed -- I like fast things :)) but I don't consider myself anywhere near a decent level of optimizations per program. However, I learnt that testing out different things in repeated loops also shows you a few things -- or just looking at a cycle sheet :P
The thing is, optimization is a stupid thing to do unless:
- you can write z80 code so fast that adding some optimizations won't slow down your programming speed
- you otherwise have a basic structure / functionally have your program working -- optimizations aren't gonna fix something that doesn't yet exist ;)
Another thing I learned is to learn all the optimizations, and WRITE them down, and actually use flashcards -- this is how I learned how to do a few things. I've been trying to learn z80 assembly for a full year now -- I have mastered everything in the 28 days tutorial, and I still know I have a very far way to go before I become a master.
Also, WikiTI is a good resource for these things when you lack a portable calc84, BW, or such. ;). I learned so much stuff there. Those who haven't checked it out yet should -- it's chock full of rich info that can greatly improve your knowledge and skill. Kudos to the authors of it :)
-
Yep, the best way to learn optimisations is to use your resources! Plus, once you optimise a certain type of code enough, it eventually becomes habit and once you look at t-states and whatnot long enough, you eventually see the patterns in timings. Even then, though, you might not manage to optimise it as much as possible. The thing is, though, in assembly, you have to remember that at the "slow" 6MHz, over 6 000 000 cycles are executed each second and most instructions use 11 cycles or less.
EDIT: So it isn't really that big of a deal if your code isn't absolutely completely optimised-- it's just fun to optimise and nice to say "yeah, my code is 5% faster and 2 bytes shorter." Programming is one of those things where you want to say "mine's smaller than yours!"
-
One of the best ways I've found to learn how to optimize code is to look at compiler outputs. While they can make some pretty idiotic mistakes, they often have really brilliant optimizations that you never would have thought of yourself. Also, if you're able to keep track of program flow, try using Self modifying code. It's often one of the best ways to get highly optimized loops.
-
ANother thing: sometimes optimizing might make your code totally unreadable, even in BASIC. As a result it might be very hard to debug or read if you ever took a long hiatus from coding and then came back to your project later. I recommend not waiting to optimize stuff, but for the most complex stuff sometimes it's good to wait at the very end of development.
-
Personally, I optimize as I go and I rarely find large optimizations when I go back over my code again. This being said, I code in Basic for the most part, and I've never even finished a decent program in Asm. ;)
-
I'm horrible at optimizing, so I'll get it all working, back it all up, then re-do it essentially. Sometimes I'll go back and say "What the heck was I thinking..."
-
I remember you asked me if you could optimize Illusiat 13 at one point, and I told you to wait until I finish it, because I feared I couldn't understand the code anymore after you do so. XD
-
I'm horrible at optimizing, so I'll get it all working, back it all up, then re-do it essentially. Sometimes I'll go back and say "What the heck was I thinking..."
I'm just like you, I code it first (working) and then optimize it, I can't optimize a lot in the first writing.