Re: Simulator: base_insn and insn in decode.c

[Ronald Hecht <ronald.hecht@uni-rostock.de>]

Dave Brolley wrote:

> I've been looking at what other ports do and it seems that most are 
> able to pass the same value base_insn and entire_insn because the 
> opcode bits are scattered throughout the insns. The ones which aren't 
> so lucky do one of two things:
>
> 1) Write some ugly code which examines the base_insn bits in order to 
> decide how to position entire_insn.


This sounds good, but it would be helpful to have the instruction size 
in the automatically generated instruction descriptor table. I say this 
in the disassembler code. This way a lookup would be easier. The 
instruction size may be also used in the <cpu>-sem.cxx code.

>
> 2) Set base-insn-bitsize in the define-isa of the .cpu file to be the 
> size of the largest insn. For SID, base_insn and entire_insn can then 
> be passed identically as the insn bits aligned at the 
> 'base-insn-bitsize' bit. For example, in your case, the max insn 
> length appears to be 24, so you could simply read 3 bytes individually 
> (to avoid endianness problems) and place them sequentially in the low 
> order bytes of base_insn and entire_insn.
>

This actually works for me! Thanks alot for the help. Now, my code looks 
like this:

      try
        {
          // Fetch 24-bit pieces separately, so endianness
          // conversions can be done on this chunk size.
          UQI insn0 = this->GETIMEMQI (pc, pc);
          UQI insn1 = this->GETIMEMQI (pc, pc+1);
          UQI insn2 = this->GETIMEMQI (pc, pc+2);
          USI insn = (insn0 << 16) | (insn1 << 8) | insn2;

          sem->decode (this, pc, insn, insn);

        }
      catch (cpu_memory_fault& t)
        {
          this->memory_trap (t);
          break;
        }

The file can be found on 
http://www-md.e-technik.uni-rostock.de/lehre/vlsi_i/proc8/src/sid/component/cgen-cpu/proc8/proc8bf.cxx
The simulator also works with gdb except for a "Memory access error 
while loading section .text." occuring some times. But I suspect, this 
is out of the scope of this mailing list.

Thanks again
Ronald