In lots of my (assembly) code, I'm creating a "switch" statement manually=
 as=20
follows...
    Case:
    TryOption1:
        movlw=09D'1'
        subwf=09SOME_VAR,W
        btfss=09STATUS,Z
        goto=09TryOption2
        < Do option 1 stuff >
        goto=09EndCase

    TryOption2:
        movlw=09D'2'
        subwf=09SOME_VAR,W
=09btfss=09STATUS,Z
=09goto=09TryOption3
=09<Do option 2 stuff >
=09goto=09EndCase

        ....
        ....
    End Case:


It's a bit inefficient, and illegible (because the options spread over ma=
ny=20
pages of code).  I can put the actions for the options in subroutines and=
=20
call them or goto them, but I'm wondering why I can't do something like=20
function pointers....

Possibility 1....

    Case:
        movf=09=09HIGH FunctionPointers,W
        movwf=09PCLATH
        movf=09=09SOME_VAR,W
        addwf=09PCL,F
    FunctionPointers:
        goto=09=09Option1Actions
        goto=09=09Option2Actions
        ....
        ...
    EndCase:


All Option?Actions will end with "goto EndCase".


Possibility 2....

    Case:
        movf=09=09HIGH FunctionPointers,W
        movwf=09PCLATH
        bcf=09=09STATUS,C
        rlf=09=09SOME_VAR,W=09=09; Multiply by 2
        addwf=09PCL,F
    FunctionPointers:
        call=09=09Option1Actions
=09goto=09=09EndCase=09=09; Or "return" if this case-stmt was called.
        call=09=09Option2Actions
=09goto=09=09EndCase=09=09; Or "return" if this case-stmt was called.
        ....
        ...
    EndCase:


Here, each Option?Actions routine would end with "return".  This second=20
possibility would use up another stack level.  But it seems more modular,=
 and=20
less prone to stupid death in future modifications.

I haven't tested these, and I know I'll have some housekeeping to do with=
=20
PCLATH, aligning to page boundaries, etc.  But can anyone see why this co=
uld=20
not work?

Cheers,
-Neil.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics