Architecture Specification

2012-05-16T09:32:56Z

l.lw assembly mnemonic: Added commentary

← Older revision		Revision as of 09:32, 16 May 2012
Line 82:		Line 82:

	l.lw rD,I(rA)		l.lw rD,I(rA)
		+
		+	''Commentary:'' The downside of this is that it is potentially confusing in a 64-bit implementation, where you want to be explicit about sign extension. If we do go down this route, then for consistency, we should also have l.lh and l.lb as synonyms for l.lhz and l.lbz. [[User:Jeremybennett\|Jeremybennett]] 11:32, 16 May 2012 (CEST)

	==== Unused SPR space read as zero ====		==== Unused SPR space read as zero ====

Architecture Specification

2012-05-16T09:25:44Z

l.trap condition: add section on load word

← Older revision		Revision as of 09:25, 16 May 2012
Line 69:		Line 69:

	This is not obeyed in any implementation and has no good justification for being specified this way. The specification should remove mention of being conditional on SR[K].		This is not obeyed in any implementation and has no good justification for being specified this way. The specification should remove mention of being conditional on SR[K].
		+
		+	==== l.lw assembly mnemonic ====
		+
		+	Add the l.lw assembly mnemonic, which encodes as a l.lwz instruction.
		+
		+	The l.lwz definition page in the spec should have:
		+
		+	Format:
		+	l.lwz rD,I(rA)
		+
		+	or
		+
		+	l.lw rD,I(rA)

	==== Unused SPR space read as zero ====		==== Unused SPR space read as zero ====

Architecture Specification

2012-05-13T17:32:16Z

Exception Vector Base Address:

← Older revision		Revision as of 17:32, 13 May 2012
(One intermediate revision by one user not shown)
Line 130:		Line 130:
	[31:13] Exception Vector Base Address		[31:13] Exception Vector Base Address
	Location for the start of exception vectors.		Location for the start of exception vectors.
−	Reset value: 0	+	Reset value: Implementation specific
	[12:0] Reserved / Constant 0		[12:0] Reserved / Constant 0

Line 138:		Line 138:
	The presence of EVBA can be detected in software by writing a value to it and		The presence of EVBA can be detected in software by writing a value to it and
	see if the same value reads back.		see if the same value reads back.
		+
		+	EVBA is only writable/readable when in supervisor mode (i.e. when SR[SM]=1)

	=== Instruction Classes ===		=== Instruction Classes ===

Architecture Specification

2012-05-13T15:05:57Z

Proposed ORBIS Classifications: update synthesis figures

← Older revision		Revision as of 15:05, 13 May 2012
(8 intermediate revisions by one user not shown)
Line 29:		Line 29:
	==== GPR0 usage, implementation ====		==== GPR0 usage, implementation ====

−	It's ~~not clear at~~ the ~~moment whether GPR0 really should be zero all~~ the ~~time~~ and ~~whether implementations would~~ be ~~free to tie it~~ to zero.	+	To eliminate confusion regarding the behaviour of writes to R0 when it's hardwired in implementation, the mention of its role according to the ABI and the potential implementation shortcuts should be removed. This is intended to imply that R0 must be implemented in the same way as the other general-purpose registers. The mention of its use as constant zero should only be present in the ABI section of the document.

	The following paragraph in 4.4 should be removed:		The following paragraph in 4.4 should be removed:
Line 38:		Line 38:
	319.		319.

−	The following ~~paragraph~~ should replace it:	+	The following sentence should replace it:

−	~~R0 is used as a constant zero according to~~ the ~~ABI. R0 may or may not be hard-wired to zero~~	+	Functions of the registers are explained in chapter Application Binary Interface on page
−	~~in implementation~~. In the ~~case where it is hard-wired~~ to zero~~, no exception will be raised~~	+	319.
−	~~when~~ it is ~~used as a destination register~~.	+
		+	In section 16.2.1, the following:
		+
		+	R0 [Zero] Always fixed to zero.
		+	Even if it is writable in some embedded implementations, the software shouldn’t modify it.

−	~~The following paragraph should~~ be ~~added~~ to ~~the ABI section on GPR0's usage~~:	+	Should be changed to:

−	R0 ~~is used as~~ a ~~constant~~ zero~~. If the register is not hard-wired to zero it should be cleared~~	+	R0 [Zero] Holds a zero value.
−	~~by software on reset, eg. l.movhi r0,0~~.	+

	==== l.trap condition ====		==== l.trap condition ====
Line 79:		Line 82:
	The existing implementation version registers are not as good as they could be, and some proposals for changing them have been made.		The existing implementation version registers are not as good as they could be, and some proposals for changing them have been made.

−	* Add new 32-bit version register, VR2, in SPR space, address 9. It identifies the implementation (model) and version of the OpenRISC 1000 processor.	+	* Add new 32-bit version register, VR2, in SPR space, address 21. It identifies the implementation (model) and version of the OpenRISC 1000 processor.

	[31:24] VER Version		[31:24] VER Version
Line 94:		Line 97:
	* A VR2-presence bit in existing VR register - bit 15 (currently reserved)		* A VR2-presence bit in existing VR register - bit 15 (currently reserved)

−	* Implementation revision/build information registers, REVIR0-REVIR4, SPR addresses 10-14. These 5 registers provide detailed information on the CPU's revision. The exact use of these registers is implementation-specific but are big enough to store a 160-bit SHA1 hash value.	+	* Implementation revision/build information registers, REVIR0-REVIR4, SPR addresses 22-26. These 5 registers provide detailed information on the CPU's revision. The exact use of these registers is implementation-specific but are big enough to store a 160-bit SHA1 hash value.

	The REVI registers helps us use that neat trick with git, but is mostly designed to help keep track of local modifications to the project before synthesis is performed. If people aren't using git locally there's many other ways to store local modifications there. For or1ksim, it's a way of getting a useful size amount of information into registers which the software can read.		The REVI registers helps us use that neat trick with git, but is mostly designed to help keep track of local modifications to the project before synthesis is performed. If people aren't using git locally there's many other ways to store local modifications there. For or1ksim, it's a way of getting a useful size amount of information into registers which the software can read.
Line 101:		Line 104:

	As the architecture is modified and possibly expanded there needs to be a way of tracking the various versions of the architecture, both in implementation (eg. via a register) and in the document itself.		As the architecture is modified and possibly expanded there needs to be a way of tracking the various versions of the architecture, both in implementation (eg. via a register) and in the document itself.
		+
		+	Although optional individual features will all have newly added presence bits to test, adherence to other architectural advances will need to be conveyed via a register for quick and easy determination by software.
		+
		+	For example, the GPR0 issue - there can be assurance that any implementation with an architecture revision value above 0 will adhere to the clarified definition of its implementation and use.
		+
		+	===== Architecture Revision Register =====
		+
		+	A new register, the Architecture Revision Register (ARR) should be added at address 27.
		+
		+	This register will contain the latest architecture revision the implementation contains features from. This will allow software to broadly detect which generation of CPU it is running on, and so which assumptions are safe.

	==== Architecture Document Versions ====		==== Architecture Document Versions ====

−	The document itself will change over time as its contents are amended, clarified or expanded. There needs to be a clear way of tracking the versions of the document. At present, the ~~current draft~~ document is revision 0 ~~pending~~ the ~~first set of~~ updates to the architecture.	+	The document itself will change over time as its contents are amended, clarified or expanded. There needs to be a clear way of tracking the versions of the document.
		+
		+	As the document is amended at present, the document revision history table in section 1.3 must be updated. However the only way to track the document revision is by the recorded date of the edit. It is proposed a new column is added to table 1-2 with an entry for each document revision of the format X-Y where X is the architecture revision the document is at that point and Y is an integer beginning at 0 for each new revision and incrementing by 1 per document update. This would mean the existing document revision is '0-17' (17 recorded updates since March 2000.) The update corresponding with the addition of new features for architecture revision 1 would mean the document revision changes to '1-0'.

	=== Exception Vector Base Address ===		=== Exception Vector Base Address ===
Line 160:		Line 175:
	A new classification is proposed:		A new classification is proposed:

−	* Class II - Optional Maths: l.div, l.mul	+	* Class II - Optional Maths: l.div, l.mul (in OR1200 on Virtex 5, serial l.div, full mult costs 265FF, 550LUT - respectively 71FF, 173LUT and 194FF, 377 LUT)
−	* Class III - Optional Bit Manipulation: l.ext[bwh]*, l.ff1, l.fl1, l.ror, l.rori	+	* Class III - Optional Bit Manipulation: l.ext[bwh]*, l.ff1, l.fl1, l.ror, l.rori (in OR1200 on Virtex 5 they cost 183 LUT)
	* Class IV - MAC Instructions - l.mac*, l.msb		* Class IV - MAC Instructions - l.mac*, l.msb
	* Class V - Remaining Optional Instructions: l.cmov, l.csync, l.msync, l.psync, l.cust1-8		* Class V - Remaining Optional Instructions: l.cmov, l.csync, l.msync, l.psync, l.cust1-8
Line 172:		Line 187:

	Presence bits in a new register should be added for classes II-IV, with a bit for each instruction in class V.		Presence bits in a new register should be added for classes II-IV, with a bit for each instruction in class V.
		+
		+	The CPUCFGR should be extended beyond bit 9 to contain:
		+
		+	[25] l.cust1 instruction supported
		+	[24] l.cust2 instruction supported
		+	[23] l.cust3 instruction supported
		+	[22] l.cust4 instruction supported
		+	[21] l.cust5 instruction supported
		+	[20] l.cust6 instruction supported
		+	[19] l.cust7 instruction supported
		+	[18] l.cust8 instruction supported
		+	[17] l.cmov instruction supported
		+	[16] l.csync instruction supported
		+	[15] l.msync instruction supported
		+	[14] l.psync instruction supported
		+	[13] Class IV instruction supported
		+	[12] Class IV instruction supported
		+	[11] Class III instruction supported
		+	[10] Class II instruction supported

	=== Delay Slot Optional ===		=== Delay Slot Optional ===

OR1K - Recent changes [en]

Architecture Specification

Architecture Specification

Architecture Specification

Architecture Specification