Add support for the PowerPC e500

[ayrtonm]

To add support for the PPC e500 we need to port the info in its existing itineraries-based model to the new scheduling machine model required by mcad. We'll also need to add some more info from the e500 manual that the existing info references. We can break this down into a few parts

Basic properties

Some basic properties defined by SchedMachineModel.

• int IssueWidth
• int MicroOpBufferSize
• int LoopMicroOpBufferSize
• int LoadLatency
• int HighLatency
• int MispredictPenalty

Most of the fields missing for the e500 seem optional for getting mcad running except for MicroOpBufferSize (which defaults to -1 triggering this assert). Other .td files base this value on the number of rename registers or issue queue sizes. So we can set it to 14 (the number of rename registers in section 4.3.3.1 of the manual) and drop this commit disabling the assertions.

Processor resources and instruction stages

Models also define processor resources which instructions use and how they use them in various ways. The old itinerary-based models use FuncUnits, BypassUnits (symbolic names for the resources) and InstrStages (how resources are used, i.e. a list of resources and latency). The new scheduling model uses ProcResources (the resources) and SchedReadWrites (how they're used).

resources

FuncUnits and ProcResources don't do anything by themselves. They're just symbolic names for resources in a processor (e.g. ALUs, FP units, DIV units). ProcResources also define a quantity while FuncUnits have the number of that resource defined separately. BypassUnits are similar to FuncUnits but specified in InstrItinData instead of InstrStage and I'm still looking into how exactly they're used.

The e500 model defines resources for the old model and here I started adding definitions for the new model based off the existing FuncUnits and BypassUnits.

stages

We also need to port the InstrStages to SchedReadWrites. InstrStages essentially just contain a list of FuncUnits and a number of cycles for the steps they represent. SchedReadWrite has many subclasses for slight variations in the ProcResource usage. The different SchedReadWrite types we need to add correspond to the different InstrStages already defined for the e500 along with the latency info in the corresponding InstrItinDatas.

Opcode data

Models also need to map opcodes to stages. The old itinerary-based models use InstrItinData to map opcode classes to a list of InstrStages. The new scheduling model uses InstRWs to map opcodes by name to a list of SchedReadWrite. Alternatively the new model may use ItinRWs to map opcode classes to a list of SchedReadWrites. This is useful to avoid changing existing info and it seems the ARM A9 model is the only one doing this for now.

The e500 already defines InstrItinData so the plan is to add ItinRWs to map the existing opcode classes to the new SchedReadWrites mentioned above.

Tasks and current status

e500 SchedMachineModel

• basic properties
  need to set MicroOpBufferSize on am/ppc_e500_sched_model branch, missing some optional properties
• ProcResources
  added FuncUnits on am/ppc_e500_sched_model, missing BypassUnits
• SchedReadWrites
  depends on BypassUnits
• ItinRWs (map opcode classes to SchedReadWrites)
  depends on SchedReadWrites, opcode classes in existing InstrItinData

After setting MicroOpBufferSize to the number of rename registers mcad runs but seems to fail when decoding instructions. The instruction decoding itself doesn't fail since this only happens when an instruction doesn't have an ItinRW or InstRW. To verify this I added an InstRW using some random ProcResource for the first STWU instruction that the CM2350 emulator executes for the kepler's law binary and checked the debug logs. I then switched the InstRW to an ItinRW for STWU and saw the same thing in the logs. Now we just need to add the correct ItinRWs for the opcode classes already defined for the e500 and run it again to see if any opcodes are missing from those classes.

[ayrtonm]

Putting in dummy values for the SchedWriteRes in the ItinRW for each itinerary class and making mcad's MCAWorker.cpp abort on errors from MCA showed that the isync instruction was not included as part of the original e500 itinerary-based model. This instruction does have an itinerary class already (IIC_SprISYNC) and adding an ItinRW for it avoids the abort in mcad, but I'll have to get the resources and latency info from the e500 manual.