Any possible way of accessing the 9th bit of the PC?

Paul Baker

··· I am investigating the feasibility of an ITC (Indirect Threaded Code) engine within SX, where raw addresses are stored in program memory and the interpreter redirects execution to that address. After reviewing the SX documentation (Sections 2.6.3 and 2.6.4) it is clear direct manipulation of 11:9 and 7:0 can be achieved by writing to the Status and PC register, but the only way it seems that the 9th bit can be set is through a jmp instruction and only a jump instruction with an address known at compile time. This is a real bugger for trying to develop the ITC engine,·since the jump address is variable. A work around can be done easily for "system calls" but a serious problem exists for self-referential calls (the ITC address points to another ITC address) and greatly complicates (if not·impossible) the·intelligence needed·for the ITC generator.

··· As an aside, in the SX28 and below the msb of the status register is always zero? It would have been nice for Ubicom to slide the bits down one to construct the 11bit address completely from the Status and·PC registers. I understand they wanted congruence between the <28 and the 48/52, but considering they already have quite a few incongruencies between the two architectures it wouldn't have been that devastating to introduce one more.

Paul

James Newton

We call this the "lower half page" problem. Using anything but a hard coded JMP, you can only get to stuff in the lower half of each 512 byte page.

The problem only shows up with machine code in the upper half page right? You can "jump" to ITC addresses in the upper half page at any time because you aren't really using the SX PC to point to it, but rather the ITC engine has an "instruction pointer" for the IREAD's.

But if an ITC address points to a machine code segment, that segment can't be in the upper half page. The only way around that is to have a hard coded JMP to that upper half page address from some lower half page location. In my macros, I set aside space if the first lower half page for a table of JMPs to subroutines in the upper half pages. When I need to get to one, I actually call the JMP in the first lower half page.

Can you setup such a table as you compile your code? I found it easy with SASM macros.

How about segrigating your memory: All actual machine code must be in lower half pages and all ITC addresses must be in the upper half page? If bit 9 is set, you know you will be IREADing an ITC address to a routine somewhere else. If bit 9 is clear, you will be doing a relative jump to actual machine code.

Would you run out of ITC address space (upper) or machine code space (lower) first? As I mentioned, only the machine code is a problem. ITC could start using lower space once all the upper space was full. If you wanted to keep the 9th bit selector between ITC addresses and machine code, you can simply pre-pend a call to the ITC engine before each section of ITC address code placed in the lower half page.

Any of that make sense?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james@sxlist.com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!

Stephen

This behaviour is simply baggage from the PIC 16C5x that the SX was designed to be compatible to... I think James' suggestions may be the only solution.

Paul Baker

··· Ah, great minds think alike. As I was racking my brain last night, I hit a moment of clarity: pseudo-indirection using a virtual PC and the iread opcode. The 4 cycle overhead of iread is undesirable but acceptable.

··· I calculate the total number of possible system functions to be around 150, so that table will occupy a good portion of one of the lower pages. My intent is to leave (at least) the first half page for a user program's ISR and embedded machine code routines. The upper·half of the first page will contain the interpretive engine and system calls·that are rarely used (as determined·upon examination of user code).·The lower half of the second page will contain the jump table for system calls, the upper half·of the second page will have the code for the most used system calls, and the remainder of the program memory will be reserved for the ITC (or TTC, token threaded code, which·method will be used will either be determined by program code space requirements or forced by a programmer setting an option).

··· So by testing the relevant upper bits of the stored address pointer (since my idea of memory segmentation has all machine code within the first 1k), it can be determined whether it is a system or self-referential call·so it should be relatively straightforward when a pseudo-indirection takes place or a true indirection.

Thanks,
Paul

Post Edited (Paul Baker) : 11/10/2004 3:42:46 PM GMT