Searching \ for 'Recocatable table read with 16x84 (not a faq!)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/mems.htm?key=table
Search entire site for: 'Recocatable table read with 16x84 (not a faq!)'.

Truncated match.
PICList Thread
'Recocatable table read with 16x84 (not a faq!)'
1998\10\14@103538 by Harri Suomalainen

flavicon
face
I've been writing all the code using MPLAB 3.99. I did choose
relocatable objects so that I could reuse code fragment with
ease (perhaps even make librarys).

Table read has to be made with a jump/call table. (With chips
like 16x84 or 12c50x) This is simple when page boundries are
not crossed. With non-relocatable code it is simple in that
case as well. (Covered well in the Microchip AppNotes)

However, with *relocatable* code it seems impossible. Example
of code:

PROG  CODE      ; Relocatable code
       ....
if ( (HIGH TableStart) & 1 )
       bsf PCLATH,0          ; set PCLATH right eg. this way
endif
       ...
       ...     ; make the computed call here
       ...
TableStart
       retlw 1     ; table here
       retlw 2
       ...

This code makes MPLAB complain about the expression being
too complex. (at the if command) Very logical as address is not
know before linking. Yet, the address is needed at the time of
code assembly.

Unfortunately this problem does arise with every external label,
even if the external label was defined by putting some table at
*known* (fixed) location. Well, it is still external and therefore
not known. A multi-pass assembler would solve this one
with ease.

Anyone found a way around these problems? Perhaps some other
approach that might work? Table reading is very common thing
to need. I'd hate to have to write non-relocatable code just for
that!


--
Harri Suomalainen     spam_OUThabaTakeThisOuTspamcc.hut.fi

We have phone numbers, why'd we need IP-numbers? - a person in a bus

1998\10\27@144616 by John Payson

flavicon
face
>>QUOTING>>
Table read has to be made with a jump/call table. (With chips
like 16x84 or 12c50x) This is simple when page boundries are
not crossed. With non-relocatable code it is simple in that
case as well. (Covered well in the Microchip AppNotes)

However, with *relocatable* code it seems impossible. Example
of code:

PROG  CODE      ; Relocatable code
       ....
if ( (HIGH TableStart) & 1 )
       bsf PCLATH,0          ; set PCLATH right eg. this way
endif

This code makes MPLAB complain about the expression being
too complex.
<<END QUOTE<<

I think you could probably do something like:

       ;movwf  TableOffset,w   ; If needed...
       movlw   HIGH    TableStart
       movwf   PCLATH
       movlw   LOW     TableStart      ; Find out the state of the carry flag
       addwf   TableOffset,w
       btfsc   C
        incf   PCLATH
       movwf   PCL

Pretty annoying code, though, for something which could be written
far better if the linker could ensure that tables didn't hit page
boundaries and if the assembler and linker could support an instruc-
tion:
       bstore  addr,bit,value

which would set or clear the specified bit of /addr/ based upon the
corresponding bit of /value/.  Basically it would require that the
linker have a fixup record type to properly control the bit in the
opcode which differentiates /bsf/ and /bcf/.



Attachment converted: wonderland:WINMAIL.DAT 4 (????/----) (0001BE78)

1998\10\28@023643 by Morgan Olsson

picon face
At 13:46 1998-10-27 -0600, John Payson wrote:
>>Table read has to be made with a jump/call table. (With chips
>>like 16x84 or 12c50x) This is simple when page boundries are
>>not crossed. With non-relocatable code it is simple in that
>>case as well. (Covered well in the Microchip AppNotes)
>
-snip-
>
>I think you could probably do something like:
>
>        ;movwf  TableOffset,w   ; If needed...
>        movlw   HIGH    TableStart
>        movwf   PCLATH
>        movlw   LOW     TableStart      ; Find out the state of the carry
flag
>        addwf   TableOffset,w
>        btfsc   C
>         incf   PCLATH
>        movwf   PCL
>
>Pretty annoying code, though

I can't think of anything more versatile.

But to minimize size and time, we can just let the *compiler* check if the
table crosses a page boundary, and if so warn us.

I use this style:

adtable:
       VARIABLE tablestart = $       ; <-- REMEMBER BEGINNING
       addwf   PCL,F
       retlw   b'00000010'             ; our table...
;etc...
       retlw   b'10010010'
       IF high $ != high adtable     ;<-- COMPARE HIGH BYTE OF START WITH HIG
H BYTE
OF END
               ERROR "addwf PCL overflow in table!"
       ENDIF

So, if we get this error, we either relocate the table, or add Johns code
for run-time method  solution above.

It would have been wonderful if we could have a way to set a variable and
then trigger a second pass for the compiler.  Then we could make some kind
of automated selection of what to  compile, based on earlier compile pass
errors.

(A whish for next MPLAB)

/Morgan
       Morgan Olsson                   ph  +46(0)414 70741
       MORGANS REGLERTEKNIK            fax +46(0)414 70331
       H€LLEKS    (in A-Z letters: "HALLEKAS")
       SE-277 35 KIVIK, SWEDEN         .....mrtKILLspamspam@spam@iname.com
______________________________________________________________

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...