variable length insns
Doug Evans
dje@transmeta.com
Thu Mar 29 23:30:00 GMT 2001
Ben Elliston writes:
> Despite fche's "Eureka!" the other day, things still don't quite work
> with respect to variable length instructions. I currently have my
> 16/32 bit ISA split thusly (insn-lsb0? #t):
>
> 16 0 31 15
> +-----------+ +----------+
> | base-insn | | optional |
> +-----------+ +----------+
>
> In its internal representation (an int), should I expect the
> instruction to be represented as (base_insn << 16) | optional? Or
> will it assume the correct bit order of 31 .. 0? That's my first
> question.
Trying to keep such insns in an int is problematic.
Dunno what the "correct" bit order should be in this context.
What would you want for a little vs big endian host?
For ISA's like these, just think of insns as a byte stream.
> I realise this aspect of cgen is frought with danger, but I'd
> appreciate any guidance in order to make the necessary enhancements.
I dunno about danger.
Suppose you take the route of not trying to keep a 32 bit insn
in an int (maybe ditto for 16 bit insns).
More information about the Cgen
mailing list