This is the mail archive of the
cgen@sources.redhat.com
mailing list for the CGEN project.
Re: make CGEN a less moving target?
Frank Ch. Eigler writes:
> dje wrote:
> > So how about rephrase it as:
> > This is what the h/w first fetches to decode an insn.
>
> Dunno about that.
>
> > For non-liw architectures this is the size of the smallest instruction.
>
> If by "non-liw" you mean "RISC", then all instructions have the same size
> and this is trivial.
> For variable-length instruction sets, things just seem to work best when
> base-insn-size includes all the non-operand bits of the longest instruction.
By liw (*1) I mean things like m32r and ia64 (and crusoe! :-).
Each instruction (or "molecule") actually contains one or more
individual instructions (or "atoms") each executed in parallel.
Thus non-liw = the other guys.
examples of liw = m32r, ia64, crusoe,
examples of non-liw = sparc, mips, ia32, m68k, ppc, yadda yadda yadda
For me, for non-liw variable length ISAs, if base-insn-bitsize isn't
the length of the smallest insn (*2) then there's a problem.
(*1) or epic or vliw or ... Got a prefered term?
I've never put much effort into the pedantically correct use of terms.
(*2) modulo some weird ISA I'm not aware of