This is the mail archive of the cgen@sources.redhat.com mailing list for the CGEN project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]