ISA,CPU,etc: Create an ISA defined PC type that abstracts out ISA behaviors.

Information
Submitter:	Gabe Black
Repository:	gem5
Branch:
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

ISA,CPU,etc: Create an ISA defined PC type that abstracts out ISA behaviors.



This change is a low level and pervasive reorganization of how PCs are managed
in M5. Back when Alpha was the only ISA, there were only 2 PCs to worry about,
the PC and the NPC, and the lsb of the PC signaled whether or not you were in
PAL mode. As other ISAs were added, we had to add an NNPC, micro PC and next
micropc, x86 and ARM introduced variable length instruction sets, and ARM
started to keep track of mode bits in the PC. Each CPU model handled PCs in
its own custom way that needed to be updated individually to handle the new
dimensions of variability, or, in the case of ARMs mode-bit-in-the-pc hack,
the complexity could be hidden in the ISA at the ISA implementation's expense.
Areas like the branch predictor hadn't been updated to handle branch delay
slots or micropcs, and it turns out that had introduced a significant (10s of
percent) performance bug in SPARC and to a lesser extend MIPS. Rather than
perpetuate the problem by reworking O3 again to handle the PC features needed
by x86, this change was introduced to rework PC handling in a more modular,
transparent, and hopefully efficient way.


PC type:

Rather than having the superset of all possible elements of PC state declared
in each of the CPU models, each ISA defines its own PCState type which has
exactly the elements it needs. A cross product of canned PCState classes are
defined in the new "generic" ISA directory for ISAs with/without delay slots
and microcode. These are either typedef-ed or subclassed by each ISA. To read
or write this structure through a *Context, you use the new pcState() accessor
which reads or writes depending on whether it has an argument. If you just
want the address of the current or next instruction or the current micro PC,
you can get those through read-only accessors on either the PCState type or
the *Contexts. These are instAddr(), nextInstAddr(), and microPC(). Note the
move away from readPC. That name is ambiguous since it's not clear whether or
not it should be the actual address to fetch from, or if it should have extra
bits in it like the PAL mode bit. Each class is free to define its own
functions to get at whatever values it needs however it needs to to be used in
ISA specific code. Eventually Alpha's PAL mode bit could be moved out of the
PC and into a separate field like ARM.

These types can be reset to a particular pc (where npc = pc +
sizeof(MachInst), nnpc = npc + sizeof(MachInst), upc = 0, nupc = 1 as
appropriate), printed, serialized, and compared. There is a branching()
function which encapsulates code in the CPU models that checked if an
instruction branched or not. Exactly what that means in the context of branch
delay slots which can skip an instruction when not taken is ambiguous, and
ideally this function and its uses can be eliminated. PCStates also generally
know how to advance themselves in various ways depending on if they point at
an instruction, a microop, or the last microop of a macroop. More on that
later.

Ideally, accessing all the PCs at once when setting them will improve
performance of M5 even though more data needs to be moved around. This is
because often all the PCs need to be manipulated together, and by getting them
all at once you avoid multiple function calls. Also, the PCs of a particular
thread will have spatial locality in the cache. Previously they were grouped
by element in arrays which spread out accesses.


Advancing the PC:

The PCs were previously managed entirely by the CPU which had to know about PC
semantics, try to figure out which dimension to increment the PC in, what to
set NPC/NNPC, etc. These decisions are best left to the ISA in conjunction
with the PC type itself. Because most of the information about how to
increment the PC (mainly what type of instruction it refers to) is contained
in the instruction object, a new advancePC virtual function was added to the
StaticInst class. Subclasses provide an implementation that moves around the
right element of the PC with a minimal amount of decision making. In ISAs like
Alpha, the instructions always simply assign NPC to PC without having to worry
about micropcs, nnpcs, etc. The added cost of a virtual function call should
be outweighed by not having to figure out as much about what to do with the
PCs and mucking around with the extra elements.

One drawback of making the StaticInsts advance the PC is that you have to
actually have one to advance the PC. This would, superficially, seem to
require decoding an instruction before fetch could advance. This is, as far as
I can tell, realistic. fetch would advance through memory addresses, not PCs,
perhaps predicting new memory addresses using existing ones. More
sophisticated decisions about control flow would be made later on, after the
instruction was decoded, and handed back to fetch. If branching needs to
happen, some amount of decoding needs to happen to see that it's a branch,
what the target is, etc. This could get a little more complicated if that gets
done by the predecoder, but I'm choosing to ignore that for now.


Variable length instructions:

To handle variable length instructions in x86 and ARM, the predecoder now
takes in the current PC by reference to the getExtMachInst function. It can
modify the PC however it needs to (by setting NPC to be the PC + instruction
length, for instance). This could be improved since the CPU doesn't know if
the PC was modified and always has to write it back.


ISA parser:

To support the new API, all PC related operand types were removed from the
parser and replaced with a PCState type. There are two warts on this
implementation. First, as with all the other operand types, the PCState still
has to have a valid operand type even though it doesn't use it. Second, using
syntax like PCS.npc(target) doesn't work for two reasons, this looks like the
syntax for operand type overriding, and the parser can't figure out if you're
reading or writing. Instructions that use the PCS operand (which I've
consistently called it) need to first read it into a local variable,
manipulate it, and then write it back out.


Return address stack:

The return address stack needed a little extra help because, in the presence
of branch delay slots, it has to merge together elements of the return PC and
the call PC. To handle that, a buildRetPC utility function was added. There
are basically only two versions in all the ISAs, but it didn't seem short
enough to put into the generic ISA directory. Also, the branch predictor code
in O3 and InOrder were adjusted so that they always store the PC of the actual
call instruction in the RAS, not the next PC. If the call instruction is a
microop, the next PC refers to the next microop in the same macroop which is
probably not desirable. The buildRetPC function advances the PC intelligently
to the next macroop (in an ISA specific way) so that that case works.


Change in stats:

There were no change in stats except in MIPS and SPARC in the O3 model. MIPS
runs in about 9% fewer ticks. SPARC runs with 30%-50% fewer ticks, which could
likely be improved further by setting call/return instruction flags and taking
advantage of the RAS.


TODO:

Add != operators to the PCState classes, defined trivially to be !(a==b).
Smooth out places where PCs are split apart, passed around, and put back
together later. I think this might happen in SPARC's fault code. Add ISA
specific constructors that allow setting PC elements without calling a bunch
of accessors. Try to eliminate the need for the branching() function. Factor
out Alpha's PAL mode pc bit into a separate flag field, and eliminate places
where it's blindly masked out or tested in the PC.

Testing Done

Quick regressions
At various times long regressions
Running all regressions now
Trace output while debugging

Description:

-		Below is the actual change description. THIS IS A BIG, DISRUPTIVE CHANGE. Conceptually it's not that complicated, but it touches just about every part of the simulator outside of the memory system include all the CPU models, all the ISAs, the ISA parser, instruction tracing, remote gdb support, starting processes in SE mode, etc. etc. Basically anything involving a simulated PC. Given the huge reach of this change and its correspondingly huge potential to introduce bugs, if at all possible please help me verify it by downloading it and trying things out. Specifically if you could try checkpointing and/or remote GDB that would be very helpful. If you have a workload you care about that isn't part of the regressions please try that too. I'd much rather work with you to fix bugs before they break your stuff than after.
-
-		This version leaves out stats updates since I'm still running the full regressions, and some nearly trivial changes to the EIO stuff. The TODOs are future TODOs since this change is already very large and I don't want to delay getting it checked in.
-
-
-
-
-
-
-
-
-
		ISA,CPU,etc: Create an ISA defined PC type that abstracts out ISA behaviors.





		This change is a low level and pervasive reorganization of how PCs are managed
		in M5. Back when Alpha was the only ISA, there were only 2 PCs to worry about,
		the PC and the NPC, and the lsb of the PC signaled whether or not you were in
		PAL mode. As other ISAs were added, we had to add an NNPC, micro PC and next
		micropc, x86 and ARM introduced variable length instruction sets, and ARM
		started to keep track of mode bits in the PC. Each CPU model handled PCs in
		its own custom way that needed to be updated individually to handle the new
		dimensions of variability, or, in the case of ARMs mode-bit-in-the-pc hack,
		the complexity could be hidden in the ISA at the ISA implementation's expense.
		Areas like the branch predictor hadn't been updated to handle branch delay
		slots or micropcs, and it turns out that had introduced a significant (10s of
		percent) performance bug in SPARC and to a lesser extend MIPS. Rather than
		perpetuate the problem by reworking O3 again to handle the PC features needed
		by x86, this change was introduced to rework PC handling in a more modular,
		transparent, and hopefully efficient way.



		PC type:

		Rather than having the superset of all possible elements of PC state declared
		in each of the CPU models, each ISA defines its own PCState type which has
		exactly the elements it needs. A cross product of canned PCState classes are
		defined in the new "generic" ISA directory for ISAs with/without delay slots
		and microcode. These are either typedef-ed or subclassed by each ISA. To read
		or write this structure through a Context, you use the new pcState() accessor
		which reads or writes depending on whether it has an argument. If you just
		want the address of the current or next instruction or the current micro PC,
		you can get those through read-only accessors on either the PCState type or
		the Contexts. These are instAddr(), nextInstAddr(), and microPC(). Note the
		move away from readPC. That name is ambiguous since it's not clear whether or
		not it should be the actual address to fetch from, or if it should have extra
		bits in it like the PAL mode bit. Each class is free to define its own
		functions to get at whatever values it needs however it needs to to be used in
		ISA specific code. Eventually Alpha's PAL mode bit could be moved out of the
		PC and into a separate field like ARM.

		These types can be reset to a particular pc (where npc = pc +
		sizeof(MachInst), nnpc = npc + sizeof(MachInst), upc = 0, nupc = 1 as
		appropriate), printed, serialized, and compared. There is a branching()
		function which encapsulates code in the CPU models that checked if an
		instruction branched or not. Exactly what that means in the context of branch
		delay slots which can skip an instruction when not taken is ambiguous, and
		ideally this function and its uses can be eliminated. PCStates also generally
		know how to advance themselves in various ways depending on if they point at
		an instruction, a microop, or the last microop of a macroop. More on that
		later.

		Ideally, accessing all the PCs at once when setting them will improve
		performance of M5 even though more data needs to be moved around. This is
		because often all the PCs need to be manipulated together, and by getting them
		all at once you avoid multiple function calls. Also, the PCs of a particular
		thread will have spatial locality in the cache. Previously they were grouped
		by element in arrays which spread out accesses.



		Advancing the PC:

		The PCs were previously managed entirely by the CPU which had to know about PC
		semantics, try to figure out which dimension to increment the PC in, what to
		set NPC/NNPC, etc. These decisions are best left to the ISA in conjunction
		with the PC type itself. Because most of the information about how to
		increment the PC (mainly what type of instruction it refers to) is contained
		in the instruction object, a new advancePC virtual function was added to the
		StaticInst class. Subclasses provide an implementation that moves around the
		right element of the PC with a minimal amount of decision making. In ISAs like
		Alpha, the instructions always simply assign NPC to PC without having to worry
		about micropcs, nnpcs, etc. The added cost of a virtual function call should
		be outweighed by not having to figure out as much about what to do with the
		PCs and mucking around with the extra elements.

		One drawback of making the StaticInsts advance the PC is that you have to
		actually have one to advance the PC. This would, superficially, seem to
		require decoding an instruction before fetch could advance. This is, as far as
		I can tell, realistic. fetch would advance through memory addresses, not PCs,
		perhaps predicting new memory addresses using existing ones. More
		sophisticated decisions about control flow would be made later on, after the
		instruction was decoded, and handed back to fetch. If branching needs to
		happen, some amount of decoding needs to happen to see that it's a branch,
		what the target is, etc. This could get a little more complicated if that gets
		done by the predecoder, but I'm choosing to ignore that for now.



		Variable length instructions:

		To handle variable length instructions in x86 and ARM, the predecoder now
		takes in the current by reference to the getExtMachInst function. It can
		modify the PC however it needs to (by setting NPC to be the PC + instruction
		length, for instance). This could be improved since the CPU doesn't know if
		the PC was modified and always has to write it back.



		ISA parser:

		To support the new API, all PC related operand types were removed from the
		parser and replaced with a PCState type. There are two warts on this
		implementation. First, as with all the other operand types, the PCState still
		has to have a valid operand type even though it doesn't use it. Second, using
		syntax like PCS.npc(target) doesn't work for two reasons, this looks like the
		syntax for operand type overriding, and the parser can't figure out if you're
		reading or writing. Instructions that use the PCS operand (which I've
		consistently called it) need to first read it into a local variable,
		manipulate it, and then write it back out.



		Return address stack:

		The return address stack needed a little extra help because, in the presence
		of branch delay slots, it has to merge together elements of the return PC and
		the call PC. To handle that, a buildRetPC utility function was added. There
		are basically only two versions in all the ISAs, but it didn't seem short
		enough to put into the generic ISA directory. Also, the branch predictor code
		in O3 and InOrder were adjusted so that they always store the PC of the actual
		call instruction in the RAS, not the next PC. If the call instruction is a
		microop, the next PC refers to the next microop in the same macroop which is
		probably not desirable. The buildRetPC function advances the PC intelligently
		to the next macroop (in an ISA specific way) so that that case works.



		Change in stats:

		There were no change in stats except in MIPS and SPARC in the O3 model. MIPS
		runs in about 9% fewer ticks. SPARC runs with 30%-50% fewer ticks, which could
		likely be improved further by setting call/return instruction flags and taking
		advantage of the RAS.



		TODO:

		Add != operators to the PCState classes, defined trivially to be !(a==b).
		Smooth out places where PCs are split apart, passed around, and put back
		together later. I think this might happen in SPARC's fault code. Add ISA
		specific constructors that allow setting PC elements without calling a bunch
		of accessors. Try to eliminate the need for the branching() function. Factor
		out Alpha's PAL mode pc bit into a separate flag field, and eliminate places
		where it's blindly masked out or tested in the PC.

Diff:

Revision 2 (+2276 -2361)

Show changes

	src/arch/isa_parser.py
	src/arch/alpha/ev5.cc
	src/arch/alpha/faults.cc
	src/arch/alpha/interrupts.hh
	src/arch/alpha/predecoder.hh
	src/arch/alpha/process.cc
	src/arch/alpha/remote_gdb.cc
	src/arch/alpha/stacktrace.cc
	161 more

Change Summary:

Change the description back.

Description:

	+	Below is the actual change description. THIS IS A BIG, DISRUPTIVE CHANGE. Conceptually it's not that complicated, but it touches just about every part of the simulator outside of the memory system include all the CPU models, all the ISAs, the ISA parser, instruction tracing, remote gdb support, starting processes in SE mode, etc. etc. Basically anything involving a simulated PC. Given the huge reach of this change and its correspondingly huge potential to introduce bugs, if at all possible please help me verify it by downloading it and trying things out. Specifically if you could try checkpointing and/or remote GDB that would be very helpful. If you have a workload you care about that isn't part of the regressions please try that too. I'd much rather work with you to fix bugs before they break your stuff than after.
	+
	+	This version leaves out stats updates since I'm still running the full regressions, and some nearly trivial changes to the EIO stuff. The TODOs are future TODOs since this change is already very large and I don't want to delay getting it checked in.
	+
	+
	+
	+
	+
	+
	+
	+
	+
		ISA,CPU,etc: Create an ISA defined PC type that abstracts out ISA behaviors.





		This change is a low level and pervasive reorganization of how PCs are managed
		in M5. Back when Alpha was the only ISA, there were only 2 PCs to worry about,
		the PC and the NPC, and the lsb of the PC signaled whether or not you were in
		PAL mode. As other ISAs were added, we had to add an NNPC, micro PC and next
		micropc, x86 and ARM introduced variable length instruction sets, and ARM
		started to keep track of mode bits in the PC. Each CPU model handled PCs in
		its own custom way that needed to be updated individually to handle the new
		dimensions of variability, or, in the case of ARMs mode-bit-in-the-pc hack,
		the complexity could be hidden in the ISA at the ISA implementation's expense.
		Areas like the branch predictor hadn't been updated to handle branch delay
		slots or micropcs, and it turns out that had introduced a significant (10s of
		percent) performance bug in SPARC and to a lesser extend MIPS. Rather than
		perpetuate the problem by reworking O3 again to handle the PC features needed
		by x86, this change was introduced to rework PC handling in a more modular,
		transparent, and hopefully efficient way.



		PC type:

		Rather than having the superset of all possible elements of PC state declared
		in each of the CPU models, each ISA defines its own PCState type which has
		exactly the elements it needs. A cross product of canned PCState classes are
		defined in the new "generic" ISA directory for ISAs with/without delay slots
		and microcode. These are either typedef-ed or subclassed by each ISA. To read
		or write this structure through a Context, you use the new pcState() accessor
		which reads or writes depending on whether it has an argument. If you just
		want the address of the current or next instruction or the current micro PC,
		you can get those through read-only accessors on either the PCState type or
		the Contexts. These are instAddr(), nextInstAddr(), and microPC(). Note the
		move away from readPC. That name is ambiguous since it's not clear whether or
		not it should be the actual address to fetch from, or if it should have extra
		bits in it like the PAL mode bit. Each class is free to define its own
		functions to get at whatever values it needs however it needs to to be used in
		ISA specific code. Eventually Alpha's PAL mode bit could be moved out of the
		PC and into a separate field like ARM.

		These types can be reset to a particular pc (where npc = pc +
		sizeof(MachInst), nnpc = npc + sizeof(MachInst), upc = 0, nupc = 1 as
		appropriate), printed, serialized, and compared. There is a branching()
		function which encapsulates code in the CPU models that checked if an
		instruction branched or not. Exactly what that means in the context of branch
		delay slots which can skip an instruction when not taken is ambiguous, and
		ideally this function and its uses can be eliminated. PCStates also generally
		know how to advance themselves in various ways depending on if they point at
		an instruction, a microop, or the last microop of a macroop. More on that
		later.

		Ideally, accessing all the PCs at once when setting them will improve
		performance of M5 even though more data needs to be moved around. This is
		because often all the PCs need to be manipulated together, and by getting them
		all at once you avoid multiple function calls. Also, the PCs of a particular
		thread will have spatial locality in the cache. Previously they were grouped
		by element in arrays which spread out accesses.



		Advancing the PC:

		The PCs were previously managed entirely by the CPU which had to know about PC
		semantics, try to figure out which dimension to increment the PC in, what to
		set NPC/NNPC, etc. These decisions are best left to the ISA in conjunction
		with the PC type itself. Because most of the information about how to
		increment the PC (mainly what type of instruction it refers to) is contained
		in the instruction object, a new advancePC virtual function was added to the
		StaticInst class. Subclasses provide an implementation that moves around the
		right element of the PC with a minimal amount of decision making. In ISAs like
		Alpha, the instructions always simply assign NPC to PC without having to worry
		about micropcs, nnpcs, etc. The added cost of a virtual function call should
		be outweighed by not having to figure out as much about what to do with the
		PCs and mucking around with the extra elements.

		One drawback of making the StaticInsts advance the PC is that you have to
		actually have one to advance the PC. This would, superficially, seem to
		require decoding an instruction before fetch could advance. This is, as far as
		I can tell, realistic. fetch would advance through memory addresses, not PCs,
		perhaps predicting new memory addresses using existing ones. More
		sophisticated decisions about control flow would be made later on, after the
		instruction was decoded, and handed back to fetch. If branching needs to
		happen, some amount of decoding needs to happen to see that it's a branch,
		what the target is, etc. This could get a little more complicated if that gets
		done by the predecoder, but I'm choosing to ignore that for now.



		Variable length instructions:

		To handle variable length instructions in x86 and ARM, the predecoder now
		takes in the current by reference to the getExtMachInst function. It can
		modify the PC however it needs to (by setting NPC to be the PC + instruction
		length, for instance). This could be improved since the CPU doesn't know if
		the PC was modified and always has to write it back.



		ISA parser:

		To support the new API, all PC related operand types were removed from the
		parser and replaced with a PCState type. There are two warts on this
		implementation. First, as with all the other operand types, the PCState still
		has to have a valid operand type even though it doesn't use it. Second, using
		syntax like PCS.npc(target) doesn't work for two reasons, this looks like the
		syntax for operand type overriding, and the parser can't figure out if you're
		reading or writing. Instructions that use the PCS operand (which I've
		consistently called it) need to first read it into a local variable,
		manipulate it, and then write it back out.



		Return address stack:

		The return address stack needed a little extra help because, in the presence
		of branch delay slots, it has to merge together elements of the return PC and
		the call PC. To handle that, a buildRetPC utility function was added. There
		are basically only two versions in all the ISAs, but it didn't seem short
		enough to put into the generic ISA directory. Also, the branch predictor code
		in O3 and InOrder were adjusted so that they always store the PC of the actual
		call instruction in the RAS, not the next PC. If the call instruction is a
		microop, the next PC refers to the next microop in the same macroop which is
		probably not desirable. The buildRetPC function advances the PC intelligently
		to the next macroop (in an ISA specific way) so that that case works.



		Change in stats:

		There were no change in stats except in MIPS and SPARC in the O3 model. MIPS
		runs in about 9% fewer ticks. SPARC runs with 30%-50% fewer ticks, which could
		likely be improved further by setting call/return instruction flags and taking
		advantage of the RAS.



		TODO:

		Add != operators to the PCState classes, defined trivially to be !(a==b).
		Smooth out places where PCs are split apart, passed around, and put back
		together later. I think this might happen in SPARC's fault code. Add ISA
		specific constructors that allow setting PC elements without calling a bunch
		of accessors. Try to eliminate the need for the branching() function. Factor
		out Alpha's PAL mode pc bit into a separate flag field, and eliminate places
		where it's blindly masked out or tested in the PC.

Description:

-		Below is the actual change description. THIS IS A BIG, DISRUPTIVE CHANGE. Conceptually it's not that complicated, but it touches just about every part of the simulator outside of the memory system include all the CPU models, all the ISAs, the ISA parser, instruction tracing, remote gdb support, starting processes in SE mode, etc. etc. Basically anything involving a simulated PC. Given the huge reach of this change and its correspondingly huge potential to introduce bugs, if at all possible please help me verify it by downloading it and trying things out. Specifically if you could try checkpointing and/or remote GDB that would be very helpful. If you have a workload you care about that isn't part of the regressions please try that too. I'd much rather work with you to fix bugs before they break your stuff than after.
-
-		This version leaves out stats updates since I'm still running the full regressions, and some nearly trivial changes to the EIO stuff. The TODOs are future TODOs since this change is already very large and I don't want to delay getting it checked in.
-
-
-
-
-
-
-
-
-
		ISA,CPU,etc: Create an ISA defined PC type that abstracts out ISA behaviors.





		This change is a low level and pervasive reorganization of how PCs are managed
		in M5. Back when Alpha was the only ISA, there were only 2 PCs to worry about,
		the PC and the NPC, and the lsb of the PC signaled whether or not you were in
		PAL mode. As other ISAs were added, we had to add an NNPC, micro PC and next
		micropc, x86 and ARM introduced variable length instruction sets, and ARM
		started to keep track of mode bits in the PC. Each CPU model handled PCs in
		its own custom way that needed to be updated individually to handle the new
		dimensions of variability, or, in the case of ARMs mode-bit-in-the-pc hack,
		the complexity could be hidden in the ISA at the ISA implementation's expense.
		Areas like the branch predictor hadn't been updated to handle branch delay
		slots or micropcs, and it turns out that had introduced a significant (10s of
		percent) performance bug in SPARC and to a lesser extend MIPS. Rather than
		perpetuate the problem by reworking O3 again to handle the PC features needed
		by x86, this change was introduced to rework PC handling in a more modular,
		transparent, and hopefully efficient way.



		PC type:

		Rather than having the superset of all possible elements of PC state declared
		in each of the CPU models, each ISA defines its own PCState type which has
		exactly the elements it needs. A cross product of canned PCState classes are
		defined in the new "generic" ISA directory for ISAs with/without delay slots
		and microcode. These are either typedef-ed or subclassed by each ISA. To read
		or write this structure through a Context, you use the new pcState() accessor
		which reads or writes depending on whether it has an argument. If you just
		want the address of the current or next instruction or the current micro PC,
		you can get those through read-only accessors on either the PCState type or
		the Contexts. These are instAddr(), nextInstAddr(), and microPC(). Note the
		move away from readPC. That name is ambiguous since it's not clear whether or
		not it should be the actual address to fetch from, or if it should have extra
		bits in it like the PAL mode bit. Each class is free to define its own
		functions to get at whatever values it needs however it needs to to be used in
		ISA specific code. Eventually Alpha's PAL mode bit could be moved out of the
		PC and into a separate field like ARM.

		These types can be reset to a particular pc (where npc = pc +
		sizeof(MachInst), nnpc = npc + sizeof(MachInst), upc = 0, nupc = 1 as
		appropriate), printed, serialized, and compared. There is a branching()
		function which encapsulates code in the CPU models that checked if an
		instruction branched or not. Exactly what that means in the context of branch
		delay slots which can skip an instruction when not taken is ambiguous, and
		ideally this function and its uses can be eliminated. PCStates also generally
		know how to advance themselves in various ways depending on if they point at
		an instruction, a microop, or the last microop of a macroop. More on that
		later.

		Ideally, accessing all the PCs at once when setting them will improve
		performance of M5 even though more data needs to be moved around. This is
		because often all the PCs need to be manipulated together, and by getting them
		all at once you avoid multiple function calls. Also, the PCs of a particular
		thread will have spatial locality in the cache. Previously they were grouped
		by element in arrays which spread out accesses.



		Advancing the PC:

		The PCs were previously managed entirely by the CPU which had to know about PC
		semantics, try to figure out which dimension to increment the PC in, what to
		set NPC/NNPC, etc. These decisions are best left to the ISA in conjunction
		with the PC type itself. Because most of the information about how to
		increment the PC (mainly what type of instruction it refers to) is contained
		in the instruction object, a new advancePC virtual function was added to the
		StaticInst class. Subclasses provide an implementation that moves around the
		right element of the PC with a minimal amount of decision making. In ISAs like
		Alpha, the instructions always simply assign NPC to PC without having to worry
		about micropcs, nnpcs, etc. The added cost of a virtual function call should
		be outweighed by not having to figure out as much about what to do with the
		PCs and mucking around with the extra elements.

		One drawback of making the StaticInsts advance the PC is that you have to
		actually have one to advance the PC. This would, superficially, seem to
		require decoding an instruction before fetch could advance. This is, as far as
		I can tell, realistic. fetch would advance through memory addresses, not PCs,
		perhaps predicting new memory addresses using existing ones. More
		sophisticated decisions about control flow would be made later on, after the
		instruction was decoded, and handed back to fetch. If branching needs to
		happen, some amount of decoding needs to happen to see that it's a branch,
		what the target is, etc. This could get a little more complicated if that gets
		done by the predecoder, but I'm choosing to ignore that for now.



		Variable length instructions:

		To handle variable length instructions in x86 and ARM, the predecoder now
		takes in the current by reference to the getExtMachInst function. It can
		modify the PC however it needs to (by setting NPC to be the PC + instruction
		length, for instance). This could be improved since the CPU doesn't know if
		the PC was modified and always has to write it back.



		ISA parser:

		To support the new API, all PC related operand types were removed from the
		parser and replaced with a PCState type. There are two warts on this
		implementation. First, as with all the other operand types, the PCState still
		has to have a valid operand type even though it doesn't use it. Second, using
		syntax like PCS.npc(target) doesn't work for two reasons, this looks like the
		syntax for operand type overriding, and the parser can't figure out if you're
		reading or writing. Instructions that use the PCS operand (which I've
		consistently called it) need to first read it into a local variable,
		manipulate it, and then write it back out.



		Return address stack:

		The return address stack needed a little extra help because, in the presence
		of branch delay slots, it has to merge together elements of the return PC and
		the call PC. To handle that, a buildRetPC utility function was added. There
		are basically only two versions in all the ISAs, but it didn't seem short
		enough to put into the generic ISA directory. Also, the branch predictor code
		in O3 and InOrder were adjusted so that they always store the PC of the actual
		call instruction in the RAS, not the next PC. If the call instruction is a
		microop, the next PC refers to the next microop in the same macroop which is
		probably not desirable. The buildRetPC function advances the PC intelligently
		to the next macroop (in an ISA specific way) so that that case works.



		Change in stats:

		There were no change in stats except in MIPS and SPARC in the O3 model. MIPS
		runs in about 9% fewer ticks. SPARC runs with 30%-50% fewer ticks, which could
		likely be improved further by setting call/return instruction flags and taking
		advantage of the RAS.



		TODO:

		Add != operators to the PCState classes, defined trivially to be !(a==b).
		Smooth out places where PCs are split apart, passed around, and put back
		together later. I think this might happen in SPARC's fault code. Add ISA
		specific constructors that allow setting PC elements without calling a bunch
		of accessors. Try to eliminate the need for the branching() function. Factor
		out Alpha's PAL mode pc bit into a separate flag field, and eliminate places
		where it's blindly masked out or tested in the PC.

Diff:

Revision 3 (+2276 -2361)

Show changes

	src/arch/isa_parser.py
	src/arch/alpha/ev5.cc
	src/arch/alpha/faults.cc
	src/arch/alpha/interrupts.hh
	src/arch/alpha/predecoder.hh
	src/arch/alpha/process.cc
	src/arch/alpha/remote_gdb.cc
	src/arch/alpha/stacktrace.cc
	161 more

Diff:

Revision 4 (+2283 -2361)

Show changes

	src/arch/isa_parser.py
	src/arch/alpha/ev5.cc
	src/arch/alpha/faults.cc
	src/arch/alpha/interrupts.hh
	src/arch/alpha/predecoder.hh
	src/arch/alpha/process.cc
	src/arch/alpha/remote_gdb.cc
	src/arch/alpha/stacktrace.cc
	161 more

Diff:

Revision 5 (+2284 -2362)

Show changes

	src/arch/isa_parser.py
	src/arch/alpha/ev5.cc
	src/arch/alpha/faults.cc
	src/arch/alpha/interrupts.hh
	src/arch/alpha/predecoder.hh
	src/arch/alpha/process.cc
	src/arch/alpha/remote_gdb.cc
	src/arch/alpha/stacktrace.cc
	161 more

Diff:

Revision 6 (+2284 -2362)

Show changes

	src/arch/isa_parser.py
	src/arch/alpha/ev5.cc
	src/arch/alpha/faults.cc
	src/arch/alpha/interrupts.hh
	src/arch/alpha/predecoder.hh
	src/arch/alpha/process.cc
	src/arch/alpha/remote_gdb.cc
	src/arch/alpha/stacktrace.cc
	161 more

Diff:

Revision 7 (+2288 -2362)

Show changes

	src/arch/isa_parser.py
	src/arch/alpha/ev5.cc
	src/arch/alpha/faults.cc
	src/arch/alpha/interrupts.hh
	src/arch/alpha/predecoder.hh
	src/arch/alpha/process.cc
	src/arch/alpha/remote_gdb.cc
	src/arch/alpha/stacktrace.cc
	161 more

Diff:

Revision 8 (+2424 -2470)

Show changes

	src/arch/isa_parser.py
	src/arch/alpha/ev5.cc
	src/arch/alpha/faults.cc
	src/arch/alpha/interrupts.hh
	src/arch/alpha/predecoder.hh
	src/arch/alpha/process.cc
	src/arch/alpha/remote_gdb.cc
	src/arch/alpha/stacktrace.cc
	165 more

Diff:

Revision 9 (+2442 -2476)

Show changes

	src/arch/isa_parser.py
	src/arch/alpha/ev5.cc
	src/arch/alpha/faults.cc
	src/arch/alpha/interrupts.hh
	src/arch/alpha/predecoder.hh
	src/arch/alpha/process.cc
	src/arch/alpha/remote_gdb.cc
	src/arch/alpha/stacktrace.cc
	165 more

Diff:

Revision 10 (+2442 -2476)

Show changes

	src/arch/isa_parser.py
	src/arch/alpha/ev5.cc
	src/arch/alpha/faults.cc
	src/arch/alpha/interrupts.hh
	src/arch/alpha/predecoder.hh
	src/arch/alpha/process.cc
	src/arch/alpha/remote_gdb.cc
	src/arch/alpha/stacktrace.cc
	165 more

Diff:

Revision 11 (+2442 -2476)

Show changes

	src/arch/isa_parser.py
	src/arch/alpha/ev5.cc
	src/arch/alpha/faults.cc
	src/arch/alpha/interrupts.hh
	src/arch/alpha/predecoder.hh
	src/arch/alpha/process.cc
	src/arch/alpha/remote_gdb.cc
	src/arch/alpha/stacktrace.cc
	165 more

So overall this is great, I love how it gets rid of the setNextPC & setNextNPC stuff all over the place, and the '#if ISA_HAS_DELAY_SLOT' in the bpred, etc.  Most of my concerns are just superficial issues, like making the syntax a little easier.

> If you just
> want the address of the current or next instruction or the current micro PC,
> you can get those through read-only accessors on either the PCState type or
> the *Contexts. These are instAddr(), nextInstAddr(), and microPC().

What's the distinction between calling instAddr() and pc() (and similarly nextInstAddr() vs npc())?  It looks to me like they're currently interchangeable, yet sometimes one is used and sometimes the other.

> The PCs were previously managed entirely by the CPU which had to know about PC
> semantics, try to figure out which dimension to increment the PC in, what to
> set NPC/NNPC, etc. These decisions are best left to the ISA in conjunction
> with the PC type itself. Because most of the information about how to
> increment the PC (mainly what type of instruction it refers to) is contained
> in the instruction object, a new advancePC virtual function was added to the
> StaticInst class. Subclasses provide an implementation that moves around the
> right element of the PC with a minimal amount of decision making. In ISAs like
> Alpha, the instructions always simply assign NPC to PC without having to worry
> about micropcs, nnpcs, etc. The added cost of a virtual function call should
> be outweighed by not having to figure out as much about what to do with the
> PCs and mucking around with the extra elements.

Does it make sense to go through an ISA-specific function, for example:

inline
TheISA::advancePC(PCState &pcState, StaticInstPtr inst)
{
    pcState.advance();
OR
    inst->advancePC(pcState);
}

> One drawback of making the StaticInsts advance the PC is that you have to
> actually have one to advance the PC. This would, superficially, seem to
> require decoding an instruction before fetch could advance. This is, as far as
> I can tell, realistic. fetch would advance through memory addresses, not PCs,
> perhaps predicting new memory addresses using existing ones. More
> sophisticated decisions about control flow would be made later on, after the
> instruction was decoded, and handed back to fetch. If branching needs to
> happen, some amount of decoding needs to happen to see that it's a branch,
> what the target is, etc. This could get a little more complicated if that gets
> done by the predecoder, but I'm choosing to ignore that for now.

Sounds reasonable to me.

> Variable length instructions:
> 
> To handle variable length instructions in x86 and ARM, the predecoder now
> takes in the current by reference to the getExtMachInst function. It can

You're missing "PC" after "current" here.

> ISA parser:
> 
> To support the new API, all PC related operand types were removed from the
> parser and replaced with a PCState type. There are two warts on this
> implementation. First, as with all the other operand types, the PCState still
> has to have a valid operand type even though it doesn't use it. Second, using
> syntax like PCS.npc(target) doesn't work for two reasons, this looks like the
> syntax for operand type overriding, and the parser can't figure out if you're
> reading or writing. Instructions that use the PCS operand (which I've
> consistently called it) need to first read it into a local variable,
> manipulate it, and then write it back out.

See my comments below... I don't see why this change is necessary or even desirable as opposed to just making the existing PC/NPC/NNPC/UPC etc. operands do the right thing, at least in the common cases.

> The return address stack needed a little extra help because, in the presence
> of branch delay slots, it has to merge together elements of the return PC and
> the call PC. To handle that, a buildRetPC utility function was added. There
> are basically only two versions in all the ISAs, but it didn't seem short
> enough to put into the generic ISA directory. Also, the branch predictor code
> in O3 and InOrder were adjusted so that they always store the PC of the actual
> call instruction in the RAS, not the next PC. If the call instruction is a
> microop, the next PC refers to the next microop in the same macroop which is
> probably not desirable. The buildRetPC function advances the PC intelligently
> to the next macroop (in an ISA specific way) so that that case works.

I don't know that it matters, but just as a sanity check: wouldn't it be equivalent to call buildRetPC on the call PC beforehand, then store the result in the RAS?  I.e., it's not what gets stored that matters, it's using the buildRetPC() logic as opposed to just using nextPC()?

src/arch/alpha/ev5.cc (Diff revision 11)

Why not just redefine setPC() to do this PCState update, then just delete the setNextPC() line?  In general I feel like a lot of the syntax changes are bigger than necessary.  I'm fine with renaming methods for clarity (e.g., readPC() -> instAddr()) but taking simple functions/assignments and replacing them with multi-stmt sequences seems like a step backwards.

Gabe Black Oct. 23, 2010, 4:33 p.m. (Oct. 23, 2010, 4:33 p.m.)

This is already very close to that. The only difference is that the new version was split into two lines to keep it from getting unmanageably long. I'm not sure if g++ would figure out that it needed to build a PCState object it could attach a const reference to if the function was called with just an address. There's a constructor to create a PCState from an address which you see used here, I just don't know if the language would make that logical leap.

src/arch/alpha/faults.cc (Diff revision 11)

Why is readPC() replaced by pc.instAddr() in one place and pc.pc() in the other? pc.pc() seems like an odd accessor anyway.

Gabe Black Oct. 23, 2010, 4:33 p.m. (Oct. 23, 2010, 4:33 p.m.)

This is a mistake. it should be pc.pc() in both places since this is ISA specific code. pc.pc() does look a little strange, but it does the job and is clear enough I think.

src/arch/alpha/isa/branch.isa (Diff revision 11)

e.g., don't see why this needs to change if we just redefine NPC properly

Gabe Black Oct. 23, 2010, 4:34 p.m. (Oct. 23, 2010, 4:34 p.m.)
```
See my response in email.
```

src/arch/alpha/tlb.cc (Diff revision 11)

Why is this instAddr()?  The implication to me is that instAddr is an actual address, where if you want the PC with all its various mode bits you'd call pc() or something else.

Gabe Black Oct. 23, 2010, 4:38 p.m. (Oct. 23, 2010, 4:38 p.m.)
```
You're right, pc() is better.
```

src/arch/isa_parser.py (Diff revision 11)

Why not leave NPC/UPC/NNPC etc as operands, but just redefine makeRead/makeWrite to do the right thing to the PCState object?  Seems like that would reduce the number of ISA changes dramatically.

Gabe Black Oct. 23, 2010, 4:39 p.m. (Oct. 23, 2010, 4:39 p.m.)

I mention this in the email, but that introduces a significant amount of copying down, making one change, copying it back, over and over. That could be fixed by making the ISA parser smarter, but I'd rather do that with a follow on change.

src/arch/mips/process.cc (Diff revision 11)

one more example: why not just delete the last two lines here, or replace them all with:
tc->setPC(objFile->entryPoint());

Gabe Black Oct. 23, 2010, 4:42 p.m. (Oct. 23, 2010, 4:42 p.m.)

We're moving away from setXXX, I thought. Also the fewer methods that need to be plumbed all over the place the better. tc->pcState is basically already what you're talking about turning tc->setPC into, I think. The difference is that the new name is more appropriate, and it takes a PC state object instead of an address.

src/arch/power/isa/decoder.isa (Diff revision 11)

more syntax changes that look superfluous to me...

Gabe Black Oct. 23, 2010, 4:42 p.m. (Oct. 23, 2010, 4:42 p.m.)
```
See email response.
```

src/cpu/thread_context.cc (Diff revision 11)

Does the PCState patch really obviate the need to check CPUIDs and contextIDs too?  This seems unrelated to me.

Gabe Black Oct. 23, 2010, 4:42 p.m. (Oct. 23, 2010, 4:42 p.m.)
```
No, this was a mistake. I've readded those lines.
```

Overall, I really like the idea of this patch.  My biggest concern is the added verbosity for some of the operations.  Especially the change in the ISA description.

src/arch/alpha/ev5.cc (Diff revision 11)

Not a big deal, but it seems like you should be able to update the pcState object in place.  Is there a reason to provide accessors rather than just expose the object directly?

Gabe Black Oct. 23, 2010, 4:46 p.m. (Oct. 23, 2010, 4:46 p.m.)

Yeah. With all the proxy this and thread that and exec the other thing, the PC needs to be behind an accessor so it can be drawn from wherever is appropriate.

src/arch/alpha/isa/branch.isa (Diff revision 11)

Would it not make sense to provide operators on PCState for doing stuff like this?

Gabe Black Oct. 23, 2010, 4:48 p.m. (Oct. 23, 2010, 4:48 p.m.)

You mean to create a copy PC set to the old PC plus something? Yeah, that's probably a good idea.

src/arch/alpha/isa/decoder.isa (Diff revision 11)

I'm also wondering about the utility of having accessors for pc and npc instead of just having them directly visible in a struct.

Gabe Black Oct. 23, 2010, 4:50 p.m. (Oct. 23, 2010, 4:50 p.m.)

It's probably not truly necessary, but it's good practice, no?

src/arch/alpha/process.cc (Diff revision 11)

Is there no implicit cast allowed?

Gabe Black Oct. 23, 2010, 4:51 p.m. (Oct. 23, 2010, 4:51 p.m.)

I don't know. When I was first doing this I didn't want to mess around with it until I got it working, and then once I got it working I didn't want to take a chance on breaking it. I'll try removing those, and if things work without them that's what I'll commit.

src/arch/alpha/utility.hh (Diff revision 11)

For your education, if you had passed callCP by value, the copy would have been implicit and you could have updated the copy.

Gabe Black Oct. 23, 2010, 4:52 p.m. (Oct. 23, 2010, 4:52 p.m.)

Yes, but if the copy wasn't necessary (like for absolute branch targets) then it would be a waste, and the signatures have to be consistent between the different implementations.

src/arch/alpha/utility.cc (Diff revision 11)

Starting to more strongly believe that the pcState object should just be directly accessible

src/arch/arm/isa/operands.isa (Diff revision 11)

Might it makes more sense to use a constant of some sort and change that?  Avoiding this sort of hundred lines of change is exactly why people do that.

As it is, I have no clue what's going on here and it looks mighty suspicious.

Gabe Black Oct. 23, 2010, 4:56 p.m. (Oct. 23, 2010, 4:56 p.m.)

It's a limitation (or at least a convention to date) of the ISA parser. Those values are used to sort the operands and determine what order they get handled in generated code. Those values are slid down by one to make space for the PC object. The comment -way- down at the end of the operand list has more information about why it's necessary.

    #PCS needs to have a sorting index (the number at the end) less than all
    #the integer registers which might update the PC. That way if the flag
    #bits of the pc state are updated and a branch happens through R15, the
    #updates are layered properly and the R15 update isn't lost.

src/arch/arm/system.hh (Diff revision 11)

Does this really no longer matter?  Does it belong in this diff?  This seems like it could be a functionality change.

Gabe Black Oct. 23, 2010, 4:59 p.m. (Oct. 23, 2010, 4:59 p.m.)

The PcTBit was a hack I used to keep track of the current thumb mode bit speculatively. The issue is that many otherwise innocuous instructions can change the mode by doing what's called an interworking branch (I think that's what they're called) and they can't possibly all make the pipeline wait to see what happens before decoding later instructions. These are basic things like add and subtract instructions. By making the thumb mode bit part of the PC, the branch prediction logic takes care of everything. Cooping a bit of the PC was sort of a gross hack, though, and the PCState structure created a better place to put it. This is the purpose of the "flags" and "newFlags" or "nextFlags" or whatever I called it in the ARM PCState structure.

src/arch/arm/table_walker.cc (Diff revision 11)

ditto

src/arch/arm/tlb.cc (Diff revision 11)

ditto

src/arch/arm/tlb.cc (Diff revision 11)

ditto

src/arch/arm/types.hh (Diff revision 11)

Hrm.  Not supposed to indent a namespace.  I guess it's already done though.

src/arch/arm/types.hh (Diff revision 11)

If you're sticking all of these flags in there, should we really be calling it PCState?  (I'm not sure I have a better name of course.  I'd normally not care except that this is all over the place.)

Gabe Black Oct. 23, 2010, 5 p.m. (Oct. 23, 2010, 5 p.m.)
```
See above comment about these bits.
```

src/arch/arm/types.hh (Diff revision 11)

I guess we do need accessor methods.  Bummer.  Proxy class might be nicer, but I guess that's a bit of a PITA.  Though, this would fit nicely with my idea on the mailing list of having the PC itself be an object type.  You could also add the arithmetic to the PC object type.

Gabe Black Oct. 23, 2010, 5:02 p.m. (Oct. 23, 2010, 5:02 p.m.)

Lets start simple and make life harder as necessary :-). I want the PC to be sort of an opaque box to the non-ISA code, and I'd like it to have to be deliberate and obvious when mucking with it.

src/arch/arm/types.hh (Diff revision 11)

I like to put a typedef near the top of:
typedef GenericISA::UPCState<MachInst> Base;

Then you can do Base::  and it is clearer what's going on.

Gabe Black Oct. 23, 2010, 5:02 p.m. (Oct. 23, 2010, 5:02 p.m.)
```
Good idea. Done.
```

src/arch/generic/types.hh (Diff revision 11)

Please do not indent inside a namespace.

Gabe Black Oct. 23, 2010, 5:05 p.m. (Oct. 23, 2010, 5:05 p.m.)
```
Fixed.
```

src/arch/generic/types.hh (Diff revision 11)

I'd say no spaces around << since we don't do it elsewhere.

Gabe Black Oct. 23, 2010, 5:05 p.m. (Oct. 23, 2010, 5:05 p.m.)
```
Ok.
```

src/arch/mips/isa/formats/branch.isa (Diff revision 11)

This is the sort of thing that code_formatter is good for.

Gabe Black Oct. 23, 2010, 5:09 p.m. (Oct. 23, 2010, 5:09 p.m.)

I'm not familiar with it, but I'm interested. In general I tried not to muck with MIPS too much. Our test coverage for it isn't great, and I didn't want to break things that were once working. Perhaps that could be a follow up change?

src/arch/mips/isa/formats/branch.isa (Diff revision 11)

And this.

src/arch/mips/process.cc (Diff revision 11)

Sounds good to me.

src/arch/power/isa/decoder.isa (Diff revision 11)

I agree.  One of the nice things about the language is the expressiveness of these sorts of statements.  It would be a shame to lose that.

src/cpu/exetrace.cc (Diff revision 11)

This stuff really feels like it's a separate change.

src/cpu/inorder/resource_pool.9stage.cc (Diff revision 11)

Unrelated?

Gabe Black Oct. 23, 2010, 5:24 p.m. (Oct. 23, 2010, 5:24 p.m.)

Vestigial. It took two tries to get InOrder converted, and this is left over from the first I think.

src/cpu/inorder/resource_pool.9stage.cc (Diff revision 11)

Unrelated?

src/cpu/o3/rob_impl.hh (Diff revision 11)

Good idea, but unrelated.

Gabe Black Oct. 23, 2010, 5:30 p.m. (Oct. 23, 2010, 5:30 p.m.)

I'll clear out these commented out lines now and take them out of this patch.

src/cpu/o3/rob_impl.hh (Diff revision 11)

ditto

src/cpu/o3/rob_impl.hh (Diff revision 11)

ditto.

src/cpu/o3/rob_impl.hh (Diff revision 11)

Seems like you've got a bunch of this that can just be committed now in a different changeset.

src/cpu/o3/thread_context.hh (Diff revision 11)

As steve said, these are probably worth keeping.  Of course they could now just be inlined and need not be virtual.

Description:

		ISA,CPU,etc: Create an ISA defined PC type that abstracts out ISA behaviors.





		This change is a low level and pervasive reorganization of how PCs are managed
		in M5. Back when Alpha was the only ISA, there were only 2 PCs to worry about,
		the PC and the NPC, and the lsb of the PC signaled whether or not you were in
		PAL mode. As other ISAs were added, we had to add an NNPC, micro PC and next
		micropc, x86 and ARM introduced variable length instruction sets, and ARM
		started to keep track of mode bits in the PC. Each CPU model handled PCs in
		its own custom way that needed to be updated individually to handle the new
		dimensions of variability, or, in the case of ARMs mode-bit-in-the-pc hack,
		the complexity could be hidden in the ISA at the ISA implementation's expense.
		Areas like the branch predictor hadn't been updated to handle branch delay
		slots or micropcs, and it turns out that had introduced a significant (10s of
		percent) performance bug in SPARC and to a lesser extend MIPS. Rather than
		perpetuate the problem by reworking O3 again to handle the PC features needed
		by x86, this change was introduced to rework PC handling in a more modular,
		transparent, and hopefully efficient way.



		PC type:

		Rather than having the superset of all possible elements of PC state declared
		in each of the CPU models, each ISA defines its own PCState type which has
		exactly the elements it needs. A cross product of canned PCState classes are
		defined in the new "generic" ISA directory for ISAs with/without delay slots
		and microcode. These are either typedef-ed or subclassed by each ISA. To read
		or write this structure through a Context, you use the new pcState() accessor
		which reads or writes depending on whether it has an argument. If you just
		want the address of the current or next instruction or the current micro PC,
		you can get those through read-only accessors on either the PCState type or
		the Contexts. These are instAddr(), nextInstAddr(), and microPC(). Note the
		move away from readPC. That name is ambiguous since it's not clear whether or
		not it should be the actual address to fetch from, or if it should have extra
		bits in it like the PAL mode bit. Each class is free to define its own
		functions to get at whatever values it needs however it needs to to be used in
		ISA specific code. Eventually Alpha's PAL mode bit could be moved out of the
		PC and into a separate field like ARM.

		These types can be reset to a particular pc (where npc = pc +
		sizeof(MachInst), nnpc = npc + sizeof(MachInst), upc = 0, nupc = 1 as
		appropriate), printed, serialized, and compared. There is a branching()
		function which encapsulates code in the CPU models that checked if an
		instruction branched or not. Exactly what that means in the context of branch
		delay slots which can skip an instruction when not taken is ambiguous, and
		ideally this function and its uses can be eliminated. PCStates also generally
		know how to advance themselves in various ways depending on if they point at
		an instruction, a microop, or the last microop of a macroop. More on that
		later.

		Ideally, accessing all the PCs at once when setting them will improve
		performance of M5 even though more data needs to be moved around. This is
		because often all the PCs need to be manipulated together, and by getting them
		all at once you avoid multiple function calls. Also, the PCs of a particular
		thread will have spatial locality in the cache. Previously they were grouped
		by element in arrays which spread out accesses.



		Advancing the PC:

		The PCs were previously managed entirely by the CPU which had to know about PC
		semantics, try to figure out which dimension to increment the PC in, what to
		set NPC/NNPC, etc. These decisions are best left to the ISA in conjunction
		with the PC type itself. Because most of the information about how to
		increment the PC (mainly what type of instruction it refers to) is contained
		in the instruction object, a new advancePC virtual function was added to the
		StaticInst class. Subclasses provide an implementation that moves around the
		right element of the PC with a minimal amount of decision making. In ISAs like
		Alpha, the instructions always simply assign NPC to PC without having to worry
		about micropcs, nnpcs, etc. The added cost of a virtual function call should
		be outweighed by not having to figure out as much about what to do with the
		PCs and mucking around with the extra elements.

		One drawback of making the StaticInsts advance the PC is that you have to
		actually have one to advance the PC. This would, superficially, seem to
		require decoding an instruction before fetch could advance. This is, as far as
		I can tell, realistic. fetch would advance through memory addresses, not PCs,
		perhaps predicting new memory addresses using existing ones. More
		sophisticated decisions about control flow would be made later on, after the
		instruction was decoded, and handed back to fetch. If branching needs to
		happen, some amount of decoding needs to happen to see that it's a branch,
		what the target is, etc. This could get a little more complicated if that gets
		done by the predecoder, but I'm choosing to ignore that for now.



		Variable length instructions:

		To handle variable length instructions in x86 and ARM, the predecoder now
~		takes in the current by reference to the getExtMachInst function. It can
	~	takes in the current PC by reference to the getExtMachInst function. It can
		modify the PC however it needs to (by setting NPC to be the PC + instruction
		length, for instance). This could be improved since the CPU doesn't know if
		the PC was modified and always has to write it back.



		ISA parser:

		To support the new API, all PC related operand types were removed from the
		parser and replaced with a PCState type. There are two warts on this
		implementation. First, as with all the other operand types, the PCState still
		has to have a valid operand type even though it doesn't use it. Second, using
		syntax like PCS.npc(target) doesn't work for two reasons, this looks like the
		syntax for operand type overriding, and the parser can't figure out if you're
		reading or writing. Instructions that use the PCS operand (which I've
		consistently called it) need to first read it into a local variable,
		manipulate it, and then write it back out.



		Return address stack:

		The return address stack needed a little extra help because, in the presence
		of branch delay slots, it has to merge together elements of the return PC and
		the call PC. To handle that, a buildRetPC utility function was added. There
		are basically only two versions in all the ISAs, but it didn't seem short
		enough to put into the generic ISA directory. Also, the branch predictor code
		in O3 and InOrder were adjusted so that they always store the PC of the actual
		call instruction in the RAS, not the next PC. If the call instruction is a
		microop, the next PC refers to the next microop in the same macroop which is
		probably not desirable. The buildRetPC function advances the PC intelligently
		to the next macroop (in an ISA specific way) so that that case works.



		Change in stats:

		There were no change in stats except in MIPS and SPARC in the O3 model. MIPS
		runs in about 9% fewer ticks. SPARC runs with 30%-50% fewer ticks, which could
		likely be improved further by setting call/return instruction flags and taking
		advantage of the RAS.



		TODO:

		Add != operators to the PCState classes, defined trivially to be !(a==b).
		Smooth out places where PCs are split apart, passed around, and put back
		together later. I think this might happen in SPARC's fault code. Add ISA
		specific constructors that allow setting PC elements without calling a bunch
		of accessors. Try to eliminate the need for the branching() function. Factor
		out Alpha's PAL mode pc bit into a separate flag field, and eliminate places
		where it's blindly masked out or tested in the PC.

Diff:

Revision 12 (+2511 -2301)

Show changes

	src/arch/isa_parser.py
	src/arch/alpha/ev5.cc
	src/arch/alpha/faults.cc
	src/arch/alpha/interrupts.hh
	src/arch/alpha/predecoder.hh
	src/arch/alpha/process.cc
	src/arch/alpha/remote_gdb.cc
	src/arch/alpha/stacktrace.cc
	163 more

src/arch/arm/faults.cc (Diff revision 12)

This doesn't look light.... SCTLR.ThumbExceptions isn't ever checked

Gabe Black Oct. 30, 2010, 8:16 a.m. (Oct. 30, 2010, 8:16 a.m.)

CPSR's thumb mode bit is being set to it up higher in the function. My thinking was that the thumb mode was more directly linked with the current CPSR value than what SCTLR's thumb exception bit was forcing it to, although they're (at least supposed to be) functionally equivalent I think.

src/arch/arm/faults.cc (Diff revision 12)

ahh sure... only other thing is that this does't compile.... curPC doesn't exist, but curPc does.

Gabe Black Oct. 30, 2010, 12:10 p.m. (Oct. 30, 2010, 12:10 p.m.)

Whoops. I thought I compiled and ran ARM_FS, but apparently not. This is now fixed locally.

You have a pending review.

Review Board 2.0.15

This change has been marked as submitted.

Screenshots

Files

Description:

Diff:

Change Summary:

Description:

Description:

Diff:

Diff:

Diff:

Diff:

Diff:

Diff:

Diff:

Diff:

Diff:

Description:

Diff:

src/arch/alpha/tlb.cc (Diff revision 11)

src/arch/mips/process.cc (Diff revision 11)

src/cpu/thread_context.cc (Diff revision 11)

src/arch/alpha/utility.hh (Diff revision 11)