Hi all I'm preparing what will hopefully be a pretty final draft for the 1.0 spec release. I have come up with a few more points I wouldn't mind getting comment on.
1. Accessing SPRs with insufficient privileges I reckon accessing SPRs which are only accessible in supervisor mode, while in user mode, should basically do nothing - writing should behave like a l.nop and reading should return zero, as if the SPR is unimplemented. http://opencores.org/or1k/Architecture_Specification#Accessing_SPRs_with_insufficient_privileges 2. Optional overflow/carry detection and (range) exception I'm wondering if we want to make this carry/overflow and range exception stuff optional, because in simple and small implementations you may not care, plus if you don't use l.addc then what's the point of the carry flag (our GCC port lives without it at present.) This seems a bit dodgy, but it's basically how we're doing things now ( nothing checks SR[CY] or SR[OV], and GCC doesn't emit l.addc) and you can save logic by omitting carry and overflow checks. (This is not to say we shouldn't make GCC emit l.addc, but it's clear we can live without it.) So I was going to suggest adding a carry/overflow + exception implemented bit, allowing it to be optional. http://opencores.org/or1k/Architecture_Specification#Optional_overflow.2Fcarry_detection_logic_and_exception_trigger 3. Behaviour when AECR/AESR not present When we don't have the new fine-grained control over overflow/carry provided by the AECR/AESR registers, we make any overflow or carry condition (as per the newly defined carry/overflow behaviour in those instructions) will trigger a range exception when SR[OVE] is set. The problem is you just cant' detect what did it, but oh well. Mentioned at the bottom of this wiki entry: http://opencores.org/or1k/Architecture_Specification#Control_of_Carry_and_Overflow_Flags_and_Exceptions 4. "Signed" in name of l.add[ic] and l.sub I've actually already done this, but just checking people are OK with it - I've removed the "Signed" from the name of the l.add instructions in the spec, because the overflow/carry detection logic now behaves as if it's doing both signed and unsigned add, so it makes no sense to have "Signed" in the name. http://opencores.org/or1k/Architecture_Specification#Remove_.22Signed.22_from_name_of_addition_and_subtraction_instructions Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
