[Libre-soc-bugs] [Bug 1039] add hardware-cycle-accurate stastistical modelling to ISACaller for an in-order core

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1039

Luke Kenneth Casson Leighton <lkcl at lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|lkcl at lkcl.net               |ghostmansd at gmail.com

--- Comment #3 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
ghostmansd, these two instructions are where insndb comes into play:
first decoding the instruction and then identifying its registers.
the register nomenclature will need to be unique: it doesn't have
to be a string, it can be a tuple.  so add 1,2,3 could be converted
to ("GPR", 1) and 2 and 3 or it could be converted to "r1" "r2" "r3"
it doesn't matter which as long as, later, back in reads_possible()
and writes_possible() it is easy to identify which register is
associated with which regfile.

  99         # get the read and write regs
 100         writeregs = get_input_regs(insn)
 101         readregs = get_output_regs(insn)

this assumes a *global* regfile which is clearly false.

 164         while len(possible) < 3 and len(r) > 0:

it is here that the number of *GPRs* has to be less than (e.g.) 3
but if there happens also to be cr0 read then obviously that is
permitted *at the same time* as 3 GPR reads, as it is a totally
separate regfile.

so perhaps a spec of ("GPR", n) and ("CR", m) would be better?

-- 
You are receiving this mail because:
You are on the CC list for the bug.