Re: [f-cpu] Supported Instructions

[Juergen Goeritz <goeritz@oekomm.de>]

On Sun, 7 Apr 2002, Christophe wrote:

>
>----- Original Message -----
>From: Yann Guidon <whygee@f-cpu.org>
>To: <f-cpu@seul.org>
>Sent: Sunday, April 07, 2002 2:18 AM
>Subject: Re: [f-cpu] Supported Instructions
>
>
>> there is a problem, however : if the code is faster than the SRB mechanism,
>> we'll read the old value from the CMB. worst, we could interrupt the SRB
>> to resume the task, but the result can reside in a register which has not
>> been "touched" by our routine. The effect is that upon return, the result
>> might not be updated.
>
>Sorry, but it is an issue for a programmer : he/she shouldn't try to resume the
>task before setting the result.
>Anyway I supposed that your registers were really saved in the CMB when
>computing them to get the result.
>
>> This means that if SRB is used, there must be a mean to control the
>> SRB tags : on entry, the tags must synchronize the reg1/reg2/reg3
>> entries of the CMB, so we don't read the old value.
>> This could be avoided in a "elegant" way (these values are known
>> at decode stage, so we just have to "latch" them somewhere)
>> but the "where" is a problem (there is not enough "bandwidth"
>> for communicating with the SRs or the LSU).
>
>Well, instead of just having the IP, we can also get the values of the
>concerned registers.
>
>For example, if we have : "mac r16,r4,r5", three SRs would have the contents of
>r16, r4 and r5 while triggering the invalid instruction interruption. Or three
>fields in our CMB to get those contents.
>
>Those SRs could have names like SR_REG1, SR_REG2 and SR_REG3.
>
>(hopefully there is only register operands for other instructions than "load"
>or "store")

Do you think this is a good idea? IMO then you need to know
(i.e. implement) about parts of the opcode already. The
best method would be to just treat it as 'unknown' and
let the emulation take control. In that case you are also
free to add opcodes later that have not been thought of
today, e.g. additional application specific opcodes that
may only be implemented in few members of the f-cpu family
or offsprings. 

<not to offend you or f-cpu>
In leon for example I use some of the coprocessor opcodes
for completely different things. It was not intended by
the SPARC definition that way but helps me to get faster
execution and debugging capabilities for my application.
</not to offend you or f-cpu>

With f-cpu I would wish for such free opcode blocks just
to be able to add e.g. special opcodes for grafical use
when f-cpu is controlling a 3D grafic human interface in
the future. Keep it free to be extendable even in ways
that may not be very common today but may get very much
wanted in the next 30 years (didn't YG intended that?).

JG

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/