Re: [f-cpu] Supported Instructions

[Yann Guidon <whygee@f-cpu.org>]

hi,

it becomes difficult for me to keep up with the discussion.
i just received posts from Michael that were sent yesterday...

Christophe wrote:
> In my mind, invalid instruction always triggers a trap.

so we are all on the same wavelength now :-)

> If you want to emulate some instructions (whatever you want) and be able to
> access the F-CPU registers to read, you can have a speed up using the
> possibility that an invalid instruction traps updates three SRs which will
> contain the contents of three registers fields of an opcode (valid or not for
> this opcode).

That's a difficult thing to do because there are 5 necessary SRs
(reg1 val, reg2 val, reg3 val, IP and instruction) and updating the
register set upon return is not straight forward. Maybe IP is useless.

For the SRs, there is only 1 port to the SR "unit" so we can't write
all the fields in a single clock cycle. generating 4 write cycles to
the SRs would be possible but how ugly...

After the new register value is computed, we have to update the register
set and it's not really easy. Self-modifying code would be better than
creating an instruction that is difficult to implement and schedule :


      get SR_TRAP_VAL1,val1;
      get SR_TRAP_VAL2,val2;
      get SR_TRAP_VAL3,val3;
      get SR_TRAP_INST,rinst;
      get SR_TRAP_IP,IP;

	// jump to the routine that corresponds to the opcode

	// compute rs

      prefetch smc+2, rsmc;
      andi 63,rinst,rinst; // mask out all but the destination register
      loadcons (rs<<6),rrd; // load the immediate value that
                            // corresponds to the instruction to overwite
      or rinst, rrd, rrd;   // build the last part of the instruction
      store.16 [rsmc],rrd;  // smc (expect some cycles of latency
      // put a jump here, just in case, to update the fetcher's buffer

      addi 4,IP,IP:
      put SR_TRAP_IP,IP; // increment the IP

smc:  move rs, rd;
      return_from_trap rrd; // restore all the dirty regs, except rrd;

(here i use symbolic names for the registers).

> So when we execute the handler it can quickly have the contents
> it needs to compute without need to get them from CMB.
it's possible and faster, but can become very difficult to implement
in an architecture that doesn't look like FC0. Do you see the challenge ?

> Of course we still need
> to update those registers in CMB if necessary. If you want to emulate an
> instruction without registers fields, well, just let the emulation ignores
> those three register operands.
> 
> But okay, it is just a suggestion for the problem of a CMB not totally saved
> (when our three registers are not saved yet in the CMB), but, I must admit, I'm
> not totally convinced with this suggestion :).

it's still a problem and we have at least 2 means to solve it, altough they
are both not pretty. But it's a beginning.

i'd like to have some "code", however, before we start to hack into it.
From what Cedric said, Michael's shuffler is not a panacea...

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and now ... let's go back to LFS.
what compiler will we use for F-CPU ? GCC 2.95.3 or 3.0.1 ?
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/