Speed Theory: Comparing SX/B and PBASIC
John Kauffman
Posts: 653
I'm thinking through the relative speeds of BASIC STAMP and SX. Some of these thoughts reflect my lack of a degree in Comp Sci, so please correct me when wrong.
·
The catalog specs are something like:
STAMP··· speed = 20-50 Mhz···········
SX········· ··speed = up to 74 MHz
·
This implies the SX is up to four times faster. Are we actually comparing apples to apples?
·
For·the STAMP:
Obviously·each cycle / sec can not be execution of a BASIC command / sec (or even of tokens / sec)
I assume the stated speeds are for processor cycles / sec and that it takes several cycles for each Token.
I'm thinking it would take many cycles to make the several assembly commands need to execute one BASIC command.
·
SX:
Again, the 75 Mhz must be the number of processor cycles per second
Again, 2-5 cycles per assembly command
Again, several assembly commands per SX/B command
So I am thinking that in the end ·the actual number of SX/B commands executed per second is similar to the STAMP
·
What I am wondering:
1 - If code is written in PBASIC and SX/B and then executed on a 50 Mhz STAMP and a 75 Mhz SX, is there really much difference in the speed that tasks are completed? Is the ratio of tasks completed any more then the ration of MHz (75/50)?
2 -·Is the main speed difference the fact that you have the option of writing assembly for SX?
3 - But even if you do write for SX in assembly, can you really cut down on the number of cycles needed to perform a task?
4 - Could the SX running SX/B actually be slower because its compiler is not optimized and, presumably, the STAMP tokenizer & interpreter are better optimized?
5 - Am I right to conclude that for users of PBASIC on 50 Mhz STAMPS moving to SX/B on SX at 75 MHz, speed is not a major difference.
6 – To bring to a practically example, if I am timing very short events (microseconds), can I get significantly better resolution in SX/B on a SX running at 75Mhz then in PBASIC on a·50Mhz stamp?
·
Having said that, the different architectures lead to other speed advantages, like the speed of an SX table look-up compared to STAMP getting the data from a table in EEPROM.
·
- Thanks
·
The catalog specs are something like:
STAMP··· speed = 20-50 Mhz···········
SX········· ··speed = up to 74 MHz
·
This implies the SX is up to four times faster. Are we actually comparing apples to apples?
·
For·the STAMP:
Obviously·each cycle / sec can not be execution of a BASIC command / sec (or even of tokens / sec)
I assume the stated speeds are for processor cycles / sec and that it takes several cycles for each Token.
I'm thinking it would take many cycles to make the several assembly commands need to execute one BASIC command.
·
SX:
Again, the 75 Mhz must be the number of processor cycles per second
Again, 2-5 cycles per assembly command
Again, several assembly commands per SX/B command
So I am thinking that in the end ·the actual number of SX/B commands executed per second is similar to the STAMP
·
What I am wondering:
1 - If code is written in PBASIC and SX/B and then executed on a 50 Mhz STAMP and a 75 Mhz SX, is there really much difference in the speed that tasks are completed? Is the ratio of tasks completed any more then the ration of MHz (75/50)?
2 -·Is the main speed difference the fact that you have the option of writing assembly for SX?
3 - But even if you do write for SX in assembly, can you really cut down on the number of cycles needed to perform a task?
4 - Could the SX running SX/B actually be slower because its compiler is not optimized and, presumably, the STAMP tokenizer & interpreter are better optimized?
5 - Am I right to conclude that for users of PBASIC on 50 Mhz STAMPS moving to SX/B on SX at 75 MHz, speed is not a major difference.
6 – To bring to a practically example, if I am timing very short events (microseconds), can I get significantly better resolution in SX/B on a SX running at 75Mhz then in PBASIC on a·50Mhz stamp?
·
Having said that, the different architectures lead to other speed advantages, like the speed of an SX table look-up compared to STAMP getting the data from a table in EEPROM.
·
- Thanks
Comments
· The biggest difference is that the PBASIC is interpeted and SX/B is compiled.
· PBASIC commands are converted to tokens and placed in EEPROM. Retrieving these token from EEPROM takes quite a bit of time. SX/B code is native processor instructions stored in processor flash memory.
· So simple commands (like A=5) will execute very fast with SX/B, but will be many times slower on a stamp.
· Complex timing commands have relativly little overhead on the stamp (because the time to retreive the command from eeprom is small compared to the time it takes to execute the command).
1) As mentioned above, it depends on what the code is doing. Bit-banging code for example will be hundreds of times faster in SX/B. Serial input or output code will be pretty much the same on both.
2) As above, the main difference is interpeted vs compiled code.
3) SX/B generates pretty tight code, but you could get better performance with assembly.
4) Because the stamp(PBASIC) must retreive tokens from the EEPROM, I don't see how it could be faster.
5) With proper SX code, yes you should be able to measure @ the clock frequency (13.333nSec @ 75MHz) resolution.
You really are trying to compare apples to oranges though...
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
Don't mistake experience for intelligence. And vis-vera.
·
I think it may be more a case of comparing apples to orangutans. SX/B should be waaaaaaayyyyy faster since it is not interpreted, and it runs directly out of the full speed on-board EEPROM.
Thanks, PeterM
Don't get wrapped around the axle with "not optimized." What this means is that SX/B doesn't call libraries for functions, it simply compiles in place. What we can do, then, is put "heavy" instructions (things like PAUSE, PAUSEUS, SERIN, SEROUT, etc.) into subroutines so that they are compiled just once (minimizing code space use). The advantage of self-optimization is that we have complete control over things and can in fact add functionality to SX/B.
The truth is that SX/B is quite efficient and you'll be happily surprised when you start looking at the output -- which is exactly the point. The original intent of SX/B was to provide a platform that allowed student programmers to see how BASIC can be effectively translated to assembly, helping them make the move to assembly if desired.
I like your term "in-place compiler". I think that really tells what the compiler does.
And like you say, if you use subroutines you will be amazed how much functionallity you can get into 2K of code space.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
Don't mistake experience for intelligence. And vis-vera.
·