I came across another issue recently introduced in the newest manual: The addition of carry/overflow detection to the MAC instructions has broken on of the important aspects of these instructions. They output to the MACLO and MACHI SPRs so that they can commit before the MAC operation has completed. The macrc & mfspr instructions will then wait for any operation to complete before reading the output registers. Now that they set the CY and OV bits, along with potentially triggering AECSR exceptions, the pipeline must wait for the MAC operation to complete before committing the instruction, because any exception must be handled precisely.
I propose solving this by adding hidden registers to be used by the MAC for the CY and OV bits, that are set whenever the appropriate overflow condition is detected. The MAC instructions never clear these hidden bits. Instead, they will be cleared by the macrc instruction, which also causes them to be written out to the SR register, as well as triggering any exceptions that should be triggered according to the AECR register. -Pete On Sun, Oct 6, 2013 at 3:10 PM, Peter Gavin <[email protected]> wrote: > Ok, I've added the things already described to the wiki. > > I have a few other concerns: > > The manual requires that the ESR register be initialized to zero on reset. > Some of the bits in SR are immutable, or reserved, such as the FO bit, for > example. Should it be possible to set the ESR bit in the FO position to > zero? Or is it possible to remove the storage for this ESR bit, and fix it > to one in ESR as well? > > It seems like only the relevant bits in SR should be storable in ESR, and > any bits that are ignored or are fixed should be able to be ignored. > Similarly, can the least significant 2 bits of the EPCR register be fixed > to zero? > > Why is the PPC register writable according to table 4-2? What happens > when it's written to? > > What happens when a misaligned address is written to the NPC register? > Does this trigger an alignment exception? > > Sorry if this has been discussed before. If it has, I missed it :) > > -Pete > > > > > On Tue, Sep 17, 2013 at 5:32 AM, Olof Kindgren <[email protected]>wrote: > >> Hi Peter, >> >> Good to hear from you. We have been ignoring the user/supervisor mode >> privileges for quite some time now, so I think it's time to put some >> pressure on this. What you propose sounds sensible to me, so it would be >> great to have this outlined on the wiki, especially as orconf2013 is coming >> up in a few weeks, and we might have some time to discuss it in detail >> there. >> >> Regards, >> Olof Kindgren >> >> >> >> On Tue, Sep 17, 2013 at 3:09 AM, Peter Gavin <[email protected]> wrote: >> >>> Hello, >>> >>> I know it's been a while since I've been on the list, but I have a few >>> thoughts about exceptions and SPRs that I wanted to discuss. There are some >>> inconsistencies in the manual, and some other things that are unclear. And >>> as has been raised before, there are some problems that may get in the way >>> of virtualization, and I have a few things I'd like to suggest that could >>> be changed in the manual. >>> >>> In short, I think we should actually *use* the definition of >>> "privileged" as given on page 15 of the manual (section 1.6). It is >>> defined, but never used in the manual, from what I've found. Additionally, >>> I think we should raise an exception whenever a privileged instruction has >>> been executed while in user mode. For example, the l.rfe instruction >>> should always raise this exception when executed in user mode. >>> Additionally, in user mode, an attempt to read or write an SPR that is not >>> permitted as indicated on Table 4-2 of the manual should raise this >>> exception. >>> >>> Our list of privileged instructions would be very short. l.rfe would >>> always be privileged. It seems to me that allowing this instruction from >>> user mode makes little sense, and could, in fact, be dangerous. l.mtspr >>> would be privileged whenever the address does not have a W in the "user >>> mode" column of table 4-2, and l.mfspr would be privileged whenever the >>> address does not have an R in that column. The descriptions for these >>> instructions would need to be changed to indicate that they may cause >>> exceptions; it currently says that they do not. >>> >>> The idea with virtualization is to run the virtualized operating >>> system's kernel in user mode. Any non-privileged instructions executed by >>> the guest operating system run normally, and so must behave identically no >>> matter the current privilege mode. Privileged instructions need to be >>> emulated by the host operating system. In order to do this with without >>> translating the binary, it is necessary that these instructions notify the >>> host by raising an exception. I would like to facilitate this by creating >>> a new "privileged instruction" exception that is raised in this case, but >>> the illegal instruction exception is sufficient, as in any case, the host >>> OS must interpret the instruction in order to determine how to proceed. >>> >>> Incidentally, some bits in the SR register (F, CY, OV) are not >>> accessible from user mode, and so these bits should be mirrored in a >>> separate SPR that is R/W from user mode. >>> >>> Also incidentally, I also think l.mtspr/l.mfspr on an unimplemented >>> register should raise an illegal instruction exception. The presence of >>> SPRs that are optional should be indicated by a bit in the UPR, and so this >>> should be checked prior to accessing them. However, the behavior currently >>> defined by the standard is not a problem for virtualization, as far as I >>> can tell, provided that l.mtspr/l.mfspr behave identically on unimplemented >>> registers whether in user or supervisor mode. >>> >>> Any thoughts? Unless there are objections, I'd like to place these >>> suggestions on the wiki. >>> >>> Thanks, >>> -Pete >>> >>> >>> _______________________________________________ >>> OpenRISC mailing list >>> [email protected] >>> http://lists.openrisc.net/listinfo/openrisc >>> >>> >> >
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
