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

Re: [f-cpu] Supported Instructions



Hi,

On Sun, 7 Apr 2002, Yann Guidon wrote:
>Juergen Goeritz wrote:
>> >> 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.

The coprocessor idea was e.g. used in the sparc architecture.
There are two optional blocks for that purpose (co + fpu).

But what I want to suggest is that there could be more 'blocks
of opcodes'. As I posted in a previus reply, a simple opcode
block may come with very few instructions (but don't take it
as if I want you to have it implemented this way though ;)

What about arranging the f-cpu opcodes in several blocks,
each with the necessary functionality to run already?

I do not mean by that to make the hardware inefficient. You
could always implement opcodes from different 'blocks' in
the same functional blocks later. It's just for the start
with a 'real' running f-cpu.

JG

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