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

Re: [f-cpu] Supported Instructions



>>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?

BTW why not implement a v0 version to evaluate these things?
With use of FPGA you could already evaluate some information
about the 'perfectness' of the functional blocks and opcode
encodings.

And just one last thought before I have to leave the house.
What about using 2 stage decoding (or two clock decoding
stage) to be able to convert any software side opcode view
to a hardware internal opcode view? Actually it would just
add another pipeline stage...

;) JG

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