Re: Simulator: base_insn and insn in decode.c

[Ronald Hecht <ronald dot hecht at uni-rostock dot 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