OK, have code that can jump to any location AKA any part of any table of any length. So..PCLATH is set, PCL is set and BAM we see a RETLW . Obviously that is not a CALL so AFAIK nothing is pushed to the stack. Therefore, it seems that one is exposed to ranDUMB "return" locations being issued from a non-initialized stack ==> anywhere!
Is this interpretation correct?
If so, then how could one issue a (true) CALL to any location AKA any part of any table of any length?
Thanks.
Explains it better than I could. You CALL the table address with an offset loaded in W. The first line of the table is an instruction which adds this offset to the program counter forcing a jump to the appropriate RETLW instruction which then returns with its data in W.
Cheers
-- Syd
It was my understanding that will only get one to the first 256 locations of what i call a page. Therefore, if one had a table that is 7168 long, one would need to access a particular CALL of a set of 14 (512 locations per "page").
Robert Baer wrote in news:xKrPx.6$ snipped-for-privacy@fx28.iad:
The trick is to have *ONE* 'fetch from any address containing RETLW' routine. You need a 16 bit pointer, preferably in the common (shared) GPR (RAM) bank to specify the table address and its convenient to use W as an unsigned positive offset by adding it to the pointer before doing the computed jump by loading PCLATH, PCL. The routine should preserve the 16 bit pointer unchanged.
Call the table access routine from anywhere in your code which automatically stacks the return adress, the access routine does its computed goto, and the RETLW returns, popping the original return address, leaving the stack properly balanced.
If you need to access table objects longer than 256 bytes, you have to add the high byte of the offset to the high byte of the table base address before entry.
-- Ian Malcolm. London, ENGLAND. (NEWSGROUP REPLY PREFERRED) ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk [at]=@, [dash]=- & [dot]=. *Warning* HTML & >32K emails --> NUL
Read top of page 3. You have to figure out before hand if you cross a page boundary and compensate for that. Otherwiase, you'll jump to someother memory location, table or not.
Cheers
Thanks.
Yah! Found out the hard way..could not figure out where..
Out of curiosity, what could one expect if a forced "call" AKA computed goto like that was done? RanDUMB return locations? Could they be controlled?
Not sure exactly what you're asking, but the difference between a CALL and a GOTO is that the CALL saves the current address +1 onto the stack. The RETLW - or ordinary return - pops this address into the program counter and thus resumes execution at the address following the CALL. If you used a GOTO instead of a CALL no return address is pushed, so the RETLW would use whatever happened to be on the stack. IIRC there's no way to push to the stack other than with CALL, so you'd almost certainly be screwed.
And that's not considering the complications of pages.
PICs are often great for high temperature work with certain restrictions, but can be awkward to code.
Cheers
-- Syd
Well, that is not precisely a GOTO - it is what one might call a computed jump, but the net effect is the same. Thanks.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.