[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...
>>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

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/