SX/B And assembly

duffling

I have know purchased the Sx programming kit and im in the process of learning assembly..

my questions are:

i have played around making some simple SX/B programs ,, then studying the compiled Source code in assembly ,

I was told this assembled code was not optimized , can i then assume that i can go thru this code and with my new assembly knowledge
tweak it so it
·a: takes up less space·· and B: is faster and more efficent ?

I would also like to hear from people who have been programming this Chip for awhile and hear how they attack·a project ..

for example .. dive strait in and program the whole thing in assembly , or a mixture of sx/b and assm ?

thanks again!



·

Bean

By "Not optimized" that means that everytime you use a PAUSE statement for instance, the compiler generates the code for the pause all over again.
If you put common used commands in subroutines, the compiler does a pretty good job.
But as a wise man once said "The best optimizer is between your ears.".

By far the best way to attack a project is in pieces. Get each piece working seperately...THEN get them working together.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video Display Module" Available Now.

www.sxvm.com

"A problem well defined, is a problem·half solved."
·

allanlane5

Yes, don't focus on making the generated assembly code faster and more efficient in the beginning. That's why you are using SX/B on a 50 MIP processor -- so you can focus on functionality, instead of getting bogged down in cycle counting.

Once you have your solution, and you've gotten it debugged and working, THEN you can look at how fast things are happening, and if they are happening fast enough.

Parallax has 10 years experience in using assembly code in a Basic environment. Your goal should be to leverage that expertise -- which they've made possible by releasing SX/B. By all means read their code to understand what they are doing. After a little more experience you'll be able to understand WHY they did it that way. But it really doesn't profit you to try to second guess all the implementation decisions they've made before you even have a working solution.

Paul Baker

Follow allan's suggestion, when I mentioned that SX/B was unoptimized, I was refering to the general fact that solving a solution with a generalized programming language frequently does not result in the fastest or most code efficient method of assembly language. This is true with all compiled languages. Many times SX/B will produce the fastest code or so close that optimization isn't worth the effort.

Optimization takes two different forms, for speed and for space. With SX/B you'll likely find yourself needing to optimize for space before speed because of the SX28 running at 50MIPS but containing 2K of program space. But as Bean alluded to, optimization for space is easily accomplished by wrapping frequently used code in many places in your·program into a function and calling it from your program. Only a very small percentage of programs need to be optimized for speed, and because of the programmer's addage "90% of your program exectution is spent in 10% of your code" it is not nessesary to optimize the entire program for speed, just critical portions that are executed frequently. But if you find the code is operating fast enough (you'll find in the vast majority of time it will) you don't have to go any further.

But by all means, read the outputted assembly code, it will help you learn the gritty details of assembly faster.

duffling

Great replies .. it re-confirmed what i was thinking already

i would love to be able to code in pure assembly and so far much of it makes a lot of sense and is not too difficult

basically i have a project in mind and will start coding it in basic ..

then i guess will tune various parts that need the speed in assm



thanks again