Would it be sensible to architect a variation of the 16-register OpenRISC to allow the other 16 registers to be read-only at least in user mode (possibly ROM or writable only as SPRs in supervisor mode)? (If the zero register had been R31, this would give the reduced context 16 writable registers. Oh, well.) The non-writable registers might be used for constant values like global area pointers (these would not have to be saved on a context switch and some might have the same values for all/many contexts [when they are the same, returning to a context would not require restoring those registers]; with virtual addresses, it is not problematic for different processes to have the same global pointers), process-specific OS information that is readable by the process (e.g., PID, EUID, EGID), or indicators of events (replacing polling via memory access or syscall with polling via a register access, though acknowledging would still require a memory write or a syscall, for polling the non-ready case should be fast [I think]). While this would make for a smaller implementation only when assigning hardwired constants, it could provide some benefits for briefly active contexts or threads that share some active write-once or -rarely/read-often data. (For constants, I would probably suggest two global pointers with LSbs of 0x8000 [providing 64KiB aligned memory areas] and perhaps some masks that might be useful for unpacking data and testing/filtering strings [e.g., a word with the MSb of every byte set]. [Since these constants could be application/ implementation-specific, the architecture need not define the values but perhaps should define some common sets of values as an aid to implementors.]) (If the link register had been defined as a 'high' register, this would provide one more 'real' register in a reduced context. The link register need only be written implicitly and read explicitly, so it could be special-cased.) Reduced contexts could also be useful with SMT, allowing more contexts to be active for a given number of available registers. Providing reduced contexts as a mode might also be useful since some contexts might benefit from more writable registers. Paul A. Clayton just a technophile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20040920/bea3c9bc/attachment-0001.htm

hello! this is actually very easily done in software and for any register it is desired. (in both cases the recompilation of all sw is required). for example, to make r16 constant register just compile with -ffixed-r16 as far as reduced context go you can always save as small context as you need. for example if your timer interrupt only increments some global variable accessible from fixed register you don't need to save anything... best regards, p. * Dysthymicdolt@aol.com (Dysthymicdolt@aol.com) wrote:

pheonix@opencores.org wrote:

But that does not save hardware resources. ROM is significantly
smaller than SRAM.

Except that one cannot always trust another context not to secretly modify unowned registers (or owned registers that are supposed to be constant). (This might not be a problem in the more deeply embedded world where software is actually firmware, but for something like a PDA this could be problematic.) Likewise a context could read registers from another context. (The OS could do a scan at installation time to check for unallowed register reads/writes--one of the advantages of RISC. Oh well.) Paul A. Clayton just a technophile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20040923/3df20e02/attachment.htm

* Dysthymicdolt@aol.com (Dysthymicdolt@aol.com) wrote:

that's true. but then i don't see much use for it...



Except that one cannot always trust another context not to secretly
modify unowned registers (or owned registers that are supposed
to be constant). (This might not be a problem in the more deeply
embedded world where software is actually firmware, but for
something like a PDA this could be problematic.) Likewise a
context could read registers from another context. (The OS could
do a scan at installation time to check for unallowed register
reads/writes--one of the advantages of RISC. Oh well.)

phoenix@opencores.org wrote: Well, I was thinking of the modest benefit of not swapping out almost half of the context for a main/heavy context when one wants to run a bursty activity, light context (e.g., a window manager?). There is also the potential for multiple threads to share some registers (e.g., global pointers) without danger of modification [Register sharing between contexts is provided by some network processors to allow multiple active threads with a lower register count.]. Paul A. Clayton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20041002/868a3220/attachment.htm