Is there a speed penalty when using a Word when a Byte will do?
- Thread starter wapo54001
- Start date
inglewoodpete
Senior Member
The underlying PIC12s and PIC18s use 8-bit memory. So the fastest memory accesses will be for byte memory.
Having said that, the overhead for word (2-byte) access is quite small. Most of the operating overhead with the PICAXE is in the unpacking and interpreting the tokenised program.
I would not share your concern unless there is a performance problem. However, I allocate byte variables from the lower registers upwards and word variables from the higher numbers downwards.
Having said that, the overhead for word (2-byte) access is quite small. Most of the operating overhead with the PICAXE is in the unpacking and interpreting the tokenised program.
I would not share your concern unless there is a performance problem. However, I allocate byte variables from the lower registers upwards and word variables from the higher numbers downwards.
Probably. I don't actually know.
There will be a few microsecond's more in writing two bytes to memory rather than one, but there may be a few microseconds less in deciding to write two bytes rather than one, even if longer it's still only a few microseconds.
I don't know because I've never really considered it worthwhile to find out. It's likely such an insignificant difference that it never really matters.
There may be some cases such as writing data in a loop where it might seem to matter more, but any saving would likely still be a very small amount compared to the rest of the loop's execution time.
For streaming data into memory; @ptrInc or @bPtrInc are probably going to be used anyway. The gain there is it's short and simple and has a fast implied increment.
Not having enough variables when using all words is the main reason I'd not do that.
Hi,
PICaxe's internal mathematical operations always use Words anyway, so the word calculations might actually be (very slightly) faster than byte maths (because byte-word-byte conversions are not required).
However, the WORD qualifier used in some of the memory DATA operations appears to be only a "pseudo" command (generated by the compiler) so can be significantly slower than the individual byte commands (because the "pointer" address needs to be restored after the second byte operation).
Cheers, Alan.
PICaxe's internal mathematical operations always use Words anyway, so the word calculations might actually be (very slightly) faster than byte maths (because byte-word-byte conversions are not required).
However, the WORD qualifier used in some of the memory DATA operations appears to be only a "pseudo" command (generated by the compiler) so can be significantly slower than the individual byte commands (because the "pointer" address needs to be restored after the second byte operation).
Cheers, Alan.
Yikes! Not a simple answer, but it seems that a) it could go either way and, b) it really doesn't matter enough to change one's practices. I'm luxuriating in my current project -- automated photography for picture stacking a la Picaxe -- because I have a surfeit of variable storage and speed really is not a big deal. I am glad to know that it doesn't seem to matter enough to worry about it. Thanks for the most interesting insight.