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

Re: [f-cpu] Supported Instructions



On Mon, 8 Apr 2002, Yann Guidon wrote:
>> >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.
>
>The current approach is to use ONLY symbolic names before F-CPU v.1
>These opcode/name bindings are defined in a specific, user-modifiable file
>of the main source tree so everybody can try his definitions, test,
>compare, measure, propose etc...

Ok.

>This decouples the function from the implementation. There are a lot
>of constraints on the opcode encoding and grouping, mainly concerning
>how the other fields are decoded (immediates, registers...) so we leave
>that to a final census and a testing script (running different boolean
>optimisers in parallel with different settings and proposed encodings).
>It is probable that a human-made, straight-forward encoding of the opcodes
>is under-efficient. I don't want to use the Alliance toolchain but they
>have a few tools (bool/boom/boog) which can give some numbers before
>we ask "big iron" synthesisers to make some attempts (on the best candidates
>found by Alliancee).
>
>But before doing that, we need the complete census of the opcodes, no ?
>This domain evolves quickly so speaking about that now is really premature.
>But keep your idea for the pre-v1 debate :-)

Actually I think it's a NO here. You need a basic set of
opcodes running to start. Why? Because from the history
of todays processors you can extract that they did never
finish their opcode range completely. Just imagine they
would have waited with 8086 implementation until they had
defined the MMX extension? (oops, no uproar please for
mentioning that architecture again).

So for when is the pre-v1 debate targeted?

JG

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