Re: sim/mips patch: add support for more NEC VR targets

[Andrew Cagney <ac131313@redhat.com>]

[See reall comment at the bottom.]


>> - gen-engine.c adds the global prefix to the beginning of
>>   ENGINE_ISSUE_(PREFIX|POSTFIX)_HOOK.  It seems MIPS is the
>>   only back-end to define these macros, and it never adds a
>>   prefix.  The patch adjusts igen accordingly.
> 
> 
> Hmm.  I don't know igen so well.  Andrew?  What are your thoughts
> here?

[I suspect its already been committed]
So, how did it ever build?

Anyway, when someone finds that a prefix is needed, it can be re-visited 
with, probably an extra option or.

>> - The existing vr5000 model selects three-address mult
>>   and dmult instructions, but those instructions aren't
>>   listed in NEC's documentation.  There's a three-address
>>   vr5400 mult instruction, but it has a different opcode.
>> 
>>   The vr5000 model only seems to exist for these instructions,
>>   it would otherwise be a standard mipsIV target.  Would it
>>   be OK to submit a follow-on patch to remove it?
> 
> 
> Well, there are a couple of other differences w.r.t: BC0T, DMFC0,
> DMTC0, COPz...  But I don't know whether they're relevant.
> 
> As far as I'm concerned, if there is no difference, it should probably
> be removed.  Andrew?

Here, I've no idea.

>> - The uses of vr4100 in mips.igen seem to be redundant
>>   with mipsIII.  OK to remove them as well?
> 
> 
> I'm assuming this is a historical thing.
> 
> In the old world order, every processor type had its own model.
> In the new world order, which you seem to be adapting nicely to,
> processors which are "ISA + extensions" use multiple models.

The real world order is: ISA YYY implements MIPS XXX, BUT with a few 
tiny exceptions ....  You end up having to check that every single 
*&@^#$(*&@#$ instruction matches the generic ISA.  Sigh.

:-)


>> ***************
>> *** 229,234 ****
>> --- 232,240 ----
>>   
>>   :function:::int:check_mf_cycles:hilo_history *history, signed64 time, const char *new
>>   {
>> +   /* There are no timing requirements in vr5500 code.  */
>> +   if (STATE_ARCHITECTURE (SD)->mach == bfd_mach_mips5500)
>> +     return 1;
>>     if (history->mf.timestamp + 3 > time)
>>       {
> 
> 
> This is the first case of code like this in the MIPS sim, but it seems
> like the right thing.

Specify two functions.  One for the mips5500 and one for the rest.  That 
way, there isn't any reason for adding TATE_ARCHITECTURE (SD)->mach == 
bfd_mach_mips5500.

It will also solve the default machine problem.

Andrew