Re: [f-cpu] Supported Instructions

["Christophe" <christophe.avoinne@laposte.net>]

----- 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")



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