Re: [f-cpu] Supported Instructions

[Yann Guidon <whygee@f-cpu.org>]

'Mojn !

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

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 :-)

@+

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