SX/B vs PBASIC memory usage

Paul

Has anyone made a comparison to the memory usage of SX/b vs. PBASIC? I understand the this is more of an 'art' than 'science' but I could use an educated guess at this point. I am looking to move a PBASIC program into the SX/B to save some cash. The PBASIC program takes up 4 slots and about 4k total bytes.
I keep looking at the SERIN, SEROUT commands and while it looks like SERIN only takes about 5 bytes in PBASIC, I'm betting it takes about 50 in SX/B compiled. Text is another problem with 500 bytes of text,. PBASIC tokenizes it pretty good but in SX/B it appears to take up nearly a whopping 1/4 of the 2K memory of a SX28AC/DP. ouch.
Is there a good rule of thumb when sizing SX/B programs?
-Paul

Paul Baker

Its an apples to oranges comparison, the PBASIC is an interpreter based system where each command compiles to a byte code, so there is very little variation (if any) of the size for each command. SX/B is a compiler based system and has a wide fluctuation in size, X = X + 1, can be compiled into a single instruction, but more complex (*,/,...) commands will span quite a few. The upshot is SX/B allows you to see the compiled assembly, allowing you to visually count/verify/alter the code.

Granted SX/B takes up more space than a PBASIC program, but its a small price to pay for execution speeds 100 times faster or more, and the seasoned coder will use assembly to code the speed critical or code bloated sections.

Post Edited (Paul Baker) : 3/10/2005 6:38:47 PM GMT

allanlane5

Since PBasic is 'tokenized', and SX is 'pure assembly', unless you can make your subroutines really small and efficient, I think the program will be larger than 2K. That's one of the benefits of 'tokenized' languages -- the 'tokens' are single bytes, which result in a call into library-code. So the 'pure assembled' version should be larger.

Since SX/B was released relatively recently, I don't think anyone has done such an analysis. Wish I could be more helpful.

PJMonty

Paul,

Slow interpreter/small code versus fast compiler/big code. Nothing in life is ever free.

In addition, while your PBasic source code tokens may be small, there is already a bunch of memory taken up by the interpreter itself. The difference is that with SX/B you can see all the generated executable code, whereas with PBasic you don't really see all the executable code because you can't really "see" the interpreter.

Thanks, PeterM

Bean

Maybe you could use an external eeprom to store your text.
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"

www.sxvm.com
·

Robert Schwartz

You could also learn some assembly and make your code more efficient and compact. The Parallax PBasic compiler for the SX is unoptomized, so there is room left for improvement in the assmebly.

James Newton

http://www.sxlist.com/techref/method/compress/embedded.htm text compression for embedded microcontrollers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james@sxlist.com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!

Paul

Thanks for all the input! Yes SX/B is just a "beginners" language intending to generate more intrest in the SX family. The immediate answer really seems to be add more memory some how (serial eeprom is an excellent idea) or even another SX! something for the orphan SX18's to do! Long term I'm sure SX/B will evolve with more and more features.
IMHO:
*Lots of stuff in life is free. You just gotta be in line at the right time!
*Digital Dice looks the same at 38Khz and 100MIPS.
*Lifes too short to learn assembly..lol (j/k)

PJMonty

Paul,

I know you were kidding about life being too short to learn assembly, but one cool thing about learning almost any assembly language is that makes learning almost any other assembly language pretty easy. Learning the nuts and bolts of assembly (what the various opcodes are, understanding register use and addressing modes, etc) is the easy part. The harder part is learning how to do useful things in a language with no "support" structure.

In a high level language, when you need a variable, you typically tell the compiler to give you one and it does. Where that variable is located in memory, how it is accessed, etc, are all things that the compiler does for you. In assembly, you have to do all of that manually. However, it turns out that this stuff isn't all that hard to do, and the knowledge of "how" to program in assembly is pretty much transferable from one CPU to another. When you want to learn a new assembly language, you mainly have to concern yourself with the new "nuts and bolts" since you'll already understand how to use assembly. Most people are really impressed when they find out you can program in multiple assembly languages. The dirty little secret about this is that it isn't too hard to learn multiple assembly languages once you become proficient in one.

Another very interesting thing that comes out of learning assembly is discovering how shockingly stupid computers are. People get so used to booting up a massive GUI operating system that they think computers are these super bad *** machines that are capable of doing all sorts of things. In truth, CPUs are the world's fastest idiots - they can't do a whole lot, but what they can do they can do really fast. The instructions most CPUs can execute are usually trivial things like load a register with memory, add a couple of values together, stick a register back into memory, etc. However, the key is that everything big/complicated thing in life is made up of smaller/less complicated things. Once you begin to see how to break down a problem into smaller and smaller pieces, you will discover that assembly makes more and more sense.

Of course, having said all that, I wouldn't give up my compilers for anything. I would no sooner go back to writing all assembly than I would give up oxygen. But I'm always glad that I know how to use assembly whenever I want to if I need to accomplish something.

Enough rambling...

Thanks, PeterM

Bean

Every language has it's place. Tokenized BASIC, Compiled BASIC, C and assembler.
The "best" language is the one that YOU personally can write a program to perform the needed task.
Every language has it's strengths and weaknesses, you either figure out how to work around the weaknesses or use a different language.
I agree, after you learn assembly on one CPU the rest are pretty much the same, and it does help with high level languages because you can figure out why something doesn't work.

P.S. I wouldn't call SX/B a "beginners" language. I may be just a little bit biased, but just wait for the next version...
My video module is written mostly in SX/B, and I don't consider it a beginner project.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"

www.sxvm.com
·