Well, thanks for the pointers. I think, for completeness, a new Opclass
FloatFMA has to be added to the Opclass enumeration at
src/cpu/FuncUnit.py and a specific FuncUnitConfig.py for PowerPC might
be needed because FloatAdd, FloatMult and FloatFMA are handled by the
same FPU, while division is handled in FXU unit. In my code, I can
modify the files to be like this, but if i want to port my changes back
to tree, what do you think, is the best way to implement it?
Thanks,
Sameh
On Sun, Dec 5, 2010 at 6:27 PM, Timothy M Jones <[email protected]
<mailto:[email protected]>> wrote:
Hi Sameh,
Well, in terms of steering instructions to the correct functional
units, I think you should simply need to go through the decoder.isa
file in src/arch/power/isa and add the correct functional unit flag
to the end of each instruction. Slightly tedious but not too
difficult. If you do that, please post a patch onto the reviewboard
so that we can get your changes incorporated into the repository.
I'm not totally sure I get what you mean about the dependent
accumulation instructions starting earlier. If you mean that you
want them to execute earlier, then you'll have to alter the O3PCU
code to get them marked as ready. I'm by no means an expert on O3,
but I believe you want to look at src/cpu/o3/iew_impl.hh as a
starting point.
Cheers
Tim
On 04/12/2010 17:19, Sameh Galal wrote:
Hi Tim,
Thanks for your response. I am trying different designs of fused
multiply add units in the powerpc architecture using SPEC 2000
floating
point benchmarks. If you were planning to incorporate the functional
units for the powerpc o3 design that will be great. Let me know
if I can
help with that. I am looking at possible designs that allow
dependent
accumulation instructions to start earlier. Do you have an idea
which
files will be best to look at to incorporate this modification.
cheers,
Sameh
On Fri, Dec 3, 2010 at 7:15 AM, Timothy M Jones
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
Hello,
Just to add my clarifications. Firstly, Gabe is right that the
classification of instructions was left out and I haven't
got round
to putting it in. I can do that, but not for a week or so.
Secondly, Steve is also right, the out-of-order scheduling
happens
and instructions do get executed when they become ready.
Power should work just fine with O3CPU and I've used it a
fair bit
without problems. All the SPEC 2000 integer benchmarks work
on it,
for example. However, if you do come across something that
isn't
working just let me know and I'll try to work out a fix with
you.
Cheers
Tim
On Thu, 02 Dec 2010 14:27:32 -0500, Steve Reinhardt
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
No, that's not true... the out-of-order scheduling will
happen
regardless of
functional unit assignment. I'm guessing that what
happens is
that all
instructions get assigned to some default functional
unit type
(probably
integer ALU), and I'm pretty sure the default O3 model has
multiple integer
ALUs, so I'm pretty confident you'd be getting out-of-order
behavior. It's
just not accurately reflecting the resource constraints
of how
instructions
would map to different units.
Steve
On Thu, Dec 2, 2010 at 10:57 AM, Sameh Galal
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
wrote:
Thanks for the info. If that's true, then none of the
instructions are
assigned to any functional unit, i assume the
machine just
behaves like an
in-order machine which is not what the O3 cpu model was
built for ..
Sameh
On Wed, Dec 1, 2010 at 10:58 PM, Gabe Black
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
wrote:
It should work functionally. It's quite possible
classifying
instructions like that in Power was left for after
things worked
functionally and never revisited. This is almost
certainly the case for
some of the other ISAs. You can attempt to
change the
isa description
yourself so that the right op class is used.
Because the
description is
built in a custom language it can be tricky to
figure
out what's going
on, but if Power is structured similar to Alpha
then the
op class
setting code may be pretty easy to port if it
isn't in
there already.
When you configure the functional unit in O3, don't
change the file in
src/ since those files only set the default value.
You'll want to change
the value in the CPU you're instantiating in a
configuration script.
That way you won't have to recompile M5 to try a
new value.
Gabe
Sameh Galal wrote:
> Hi,
> I have a quick question about how PowerPC out of
order cpu model in SE
> mode. Is the out of order model fully supported in
PowerPC
>
> The reason I am asking, is that it is not clear to me
how the
> functional units of the PowerPC architecture are
assigned their
> latencies. I found that the file
src\cpu\o3\FuncUnitConfig.py contains
> the functional unit configuration and which
instructions the units
> handle. For example the FP_MultDiv unit handles the
FloatMult
> instructions among other instructions
>
> class FP_MultDiv(FUDesc):
> opList = [ OpDesc(opClass='FloatMult', opLat=4),
> OpDesc(opClass='FloatDiv', opLat=12,
issueLat=12),
> OpDesc(opClass='FloatSqrt', opLat=24,
issueLat=24) ]
> count = 2
>
> However when I grep the source folder for FloatMult,
I find that only
> the alpha architecture instruction decoder assigns
the Opclass types.
> So how is the simulation of powerpc functional units
done?
>
> [same...@cyclades-master m5]$ grep -r FloatMult ./src
> ./src/arch/alpha/isa/decoder.isa:
0x02: muls({{
> Fc = Fa * Fb; }}, FloatMultOp);
> ./src/arch/alpha/isa/decoder.isa:
0x02: muls({{
> Fc.sf = Fa.sf * Fb.sf; }}, FloatMultOp);
> ./src/arch/alpha/isa/decoder.isa:
0x22: mult({{
> Fc = Fa * Fb; }}, FloatMultOp);
> ./src/cpu/FuncUnit.py: 'FloatCmp', 'FloatCvt',
'FloatMult',
> 'FloatDiv', 'FloatSqrt',
> ./src/cpu/o3/FuncUnitConfig.py: opList = [
> OpDesc(opClass='FloatMult', opLat=4),
> ./src/cpu/op_class.hh:const OpClass FloatMultOp =
Enums::FloatMult;
>
> Thanks for clarifying.
> Sameh
>
------------------------------------------------------------------------
>
> _______________________________________________
> m5-users mailing list
> [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
--
Timothy M. Jones
http://homepages.inf.ed.ac.uk/tjones1
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
m5-users mailing list
[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
--
Timothy M. Jones
http://homepages.inf.ed.ac.uk/tjones1
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
