<div dir="ltr">... now with added sample!</div><div class="gmail_extra"><br><div class="gmail_quote">On 2 November 2014 12:46, James Molloy <span dir="ltr"><<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Andy, Dave,<div><br></div><div>I've been doing a bit of experimentation trying to understand the schedmodel a bit better and improving modelling of FDIV (on Cortex-A57).</div><div><br></div><div>FDIV is not pipelined, and blocks other FDIV operations (FDIVDrr and FDIVSrr). This seems to be already semi-modelled, with a "ResourceCycles=[18]" line in the SchedWriteRes for this instruction. This doesn't seem to work (a poor schedule is produced) so I changed it to also require another resource that I modelled as unbuffered (BufferSize=0), in the hope that this would "block" other FDIVs... no joy.</div><div><br></div><div>Then I noticed that the MicroOpBufferSize is set to 128, which is wildly high as Cortex-A57 has separated smaller reorder buffers, not one larger reorder buffer.</div><div><br></div><div>Even reducing it down to "2" made no effect, the divs were scheduled in a clump together. But "1" and "0" (denoting in-order) produced a nice schedule.</div><div><br></div><div>I'd expect an OoO machine with a buffer of 2 ops would produce a very similar schedule as an in-order machine. So where am I going wrong?</div><div><br></div><div>Sample attached - I'd expect the FDIVs to be equally spread across the MULs. (The extension to this I want to model is that we can have 2 S-register FDIVs in parallel but only one D-reg FDIV, and never both, but that can wait until I've understood what's going on here!).</div><div><br></div><div>Cheers,</div><div><br></div><div>James</div></div>
</blockquote></div><br></div>