deSilva said...
... and every author invents his own idioms. You can be sure, that when something "senseless" is stated in an address field it is a hint that it will be patched.
Ex.:
0 highly improbably address value, as the first instruction is located here
0-0 absolutely redundant because 0-0 == 0
#18/16/13 makes no sense, as yields 0; wants to say: "Will be patched with 18 or 16 or 13 respectively"
Edit:
RDLONG .., #0
might also be confusing, though is well commented
Ref. to the manual "....There are two values stored in the initialization area that might be of interest to your program:
a long at $0000 contains the initial master clock frequency, in Hertz, and a byte following it
at $0004 contains the initial value written into the CLK register. These two values can be
read/written using their physical addresses (LONG[noparse][[/noparse]$0] and BYTE[noparse][[/noparse]$4])"
My two cents: the label ought to include the initials SM_ -- self-modifying. That way it stands out both
at the actual line and, importantly, as a destination elsewhere. So in this case, SM_napshr.
I do wish the author·had been·a little more verbose.·His·comment didn't help.
<I>He probably concentrated on writing an efficient program rather than a tutorial on what Propeller assembly is all about </I>
The way it was written is confusing even to those who understand Prop ASM self modifying code. This is where coding standards help. It wouldn't have taken any more time to put #0-0 rather than #18/16/13.
(That's an eg, as we don't actually have any coding standards for the Prop.)
Comments
at the actual line and, importantly, as a destination elsewhere. So in this case, SM_napshr.
I do wish the author·had been·a little more verbose.·His·comment didn't help.
The way it was written is confusing even to those who understand Prop ASM self modifying code. This is where coding standards help. It wouldn't have taken any more time to put #0-0 rather than #18/16/13.
(That's an eg, as we don't actually have any coding standards for the Prop.)