I found some "long 0-0" in the declairations area in PASM that I am not familar
Octahedron
Posts: 18
I was looking in N&V Spin Zone article·on SIRCS·and was making my way though the DAT code and ran across some long declarations that I have not seen before.· Here is the complete declaration section of the code:
DONE···················long··· true
NEG_DETECT·········long··· %01100 << 26··················· ' ctr neg detector
FREE_RUN·············long··· %11111 << 26··················· ' ctr logic always mode
START_BIT···········long··· 0-0···························· ' counts in 80% of 2.4ms
ONE_BIT·············· long··· 0-0···························· ' counts in 80% of 1.2ms
MS_044··············· long··· 0-0···························· ' counts in 44ms··
irmask················· long··· 0-0···························· ' pin mask for ir input
okpntr················· long··· 0-0···························· ' pointer to ready flag
codepntr·············· long··· 0-0···························· ' pointer to ir code
bitspntr··············· long··· 0-0···························· ' pointer to bit count of code
irwork·················· res···· 1······························ ' workspace for ir input
bits····················· res···· 1······························ ' # bits in input
tmp1··················· res···· 1
tmp2··················· res···· 1
··························fit···· 492
Now I have seen and used·all of them except for the "long 0-0".· Does someone have a quick explanation?
Thanks for your time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
DONE···················long··· true
NEG_DETECT·········long··· %01100 << 26··················· ' ctr neg detector
FREE_RUN·············long··· %11111 << 26··················· ' ctr logic always mode
START_BIT···········long··· 0-0···························· ' counts in 80% of 2.4ms
ONE_BIT·············· long··· 0-0···························· ' counts in 80% of 1.2ms
MS_044··············· long··· 0-0···························· ' counts in 44ms··
irmask················· long··· 0-0···························· ' pin mask for ir input
okpntr················· long··· 0-0···························· ' pointer to ready flag
codepntr·············· long··· 0-0···························· ' pointer to ir code
bitspntr··············· long··· 0-0···························· ' pointer to bit count of code
irwork·················· res···· 1······························ ' workspace for ir input
bits····················· res···· 1······························ ' # bits in input
tmp1··················· res···· 1
tmp2··················· res···· 1
··························fit···· 492
Now I have seen and used·all of them except for the "long 0-0".· Does someone have a quick explanation?
Thanks for your time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Comments
Is a convention that has grown up among Propeller programmers to indicate to the reader that the variable is subject to being changed as part of a self-modifying code sequence. You will often see this where source or destinations addresses of an instruction are modified to create indexed addressing and such. e.g
MOVS get, #3 'Set source address of instruction at "get" to 3
.
.
.
get MOV A, #0-0 'When executed this instruction will have the source address modified.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
In those cases AFAICT they do not mean nothing special.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
pPropellerSim - A propeller simulator for ASM development sourceforge.net/projects/ppropellersim
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
Post Edited (JonnyMac) : 2/14/2010 11:09:12 PM GMT