Re: made up byte code: registers vs. literals

jon klein wrote:
>
> The interpreter has a couple of virtual registers to store intermediate
> results. The was I'm doing it, each 8-bit operator has 3 8-bit operands,
> so that each instruction is 32 bits wide.
>
> ADD %r1,%r2,%r3 ; r3 = r1 + r2


Right, a 3-address code; not real efficient for space, but very flexible.


> The problem deals with literals. Say I want to:
>
> ADD 5, %r2, %r3
>
> or the more important problem
>
> MOV 10, %r1
>
> The general question then, is: how does the Sparc (or any... I'm just
> familiar with Sparc) assembler handle this?


I can't speak to the sparc, but the way most assemblers handle it is that
there are different opcodes for operations on literals than for operations
on registers. The assembler tries to 'hide' this fact from you to make
the language easier to conceptualize. But when you write


ADD %3 %5 %2


the assembler uses a different add instruction than when you write


ADD 3 %5 %2


There's also some rewrites that go the other way; typically a Code which
supports the operation of adding a literal to a register and storing the
result in a register has only one instruction that does it; so the exact
same bitcode is generated, for example when you write


ADD 3 %5 %2


and


ADD %5 3 %2


Addressing modes and their use and representation was the subject of much
contention and hair in compiler design until RISC architectures came along;
In a RISC architecture there *are no* instructions that deal with literals,
except one: it loads a literal value into a register. Also, there are
exactly two instructions that deal with main memory; load and store.


I won't *tell* you what to do, but I find that intermediate representations
are a whole lot easier to work with when you don't try to make every
instruction have multiple forms for different addressing modes.


Bear
--

Return to the comp.compilers page.
Search the comp.compilers archives again.