[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] Supported Instructions

hi !

Juergen Goeritz wrote:
> On Sun, 7 Apr 2002, Christophe wrote:
> >In fact, whatever is the opcode, F-CPU just extracts the three fields and give
> >us their contents. The opcode could never use one or two of those registers
> >(one or two operands instructions) so it doesn't make a difference. It is the
> >software to do whatever it wants with this info. So F-CPU really lets the
> >emulation take control, because it is only the emulation code which knows what
> >to do with. Such a feature could be disabled or better thought.
> My idea is to implement nothing at all for unimplemented
> opcodes to be free for future changes. And unimplemented
> opcodes should always generate an exception.

good sense is with us this evening :-)

> >> 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?).
> >
> >Do such free opcode blocks trigger an exception anyhow ?
> Häh? What else? Any unimplemented opcode should trigger
> an exception. Otherwise it would be implemented. Shrug,
> maybe I didn't quite understand your question?

i think you're ok, because
 - there are at least 100 free opcodes left
 - as you say, any unimplemented opcode traps.
so it should be relatively easy to reserve 32 opcodes for later
stuffs, but as a rule of thumb, it is better to do "generic"
instructions that can be used many in different contexts.
If it's too specific, it must be either tagged as "optional" or
handed to a coprocessor... Or it must be so simple to implement
that there is almost no overhead.

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