Re: Reduced Machine Description

In article <3365@ima.ima.isc.com> martins@rwthinf.uucp (Martin Schoenert) writes:
[stuff deleted]
> My idea is a reduced machine description. It consists of the
>following functions, which emit corresponding instructions for say a MC68000:
>
>load( size, dest, src, offset )
> Load a word, signed halfword, unsigned halfword, signed byte or
> unsigned byte from the address pointed to by the <src> register plus
> the signed <offset> into the <dest> register.
>store( size, src, dest, off )
> Store a word, halfword or byte from the <src> register at the address
> pointed to by the <dest> register plus the signed <offset>.
>
>add( dest, src1, src2, imm )
> If <imm> == 0 then add the contents of register <src1> and <src2> and
> put the result into register <dest>. If <imm> == 1 then add the
> immediate value <src2> to the register <src1> and put the result into
> register <dest>.
[rest deleted]


I think a more general pseudo-machine is a top-of-stack machine. This way,
no assumptions are made about what types of registers exist. You mentioned
that the number of registers would have to be specified. For machines like
the 68000 which have separate address and data registers, simply the number of
registers is not enough. Other problems are limited branch ranges, limited
offset sizes, word alignment problems, etc. Accessing the stack also has to
be considered carefully. It can't be a simple byte offset since the elements
on the stack might have to be word aligned. The most general way would be to
specify the nth element on the stack and have the code generator keep track of
what types of elements are already on the stack. Also, when operand address
are specified, the full path (all indirections and offsets) should be
specified to give the code generator all the information possible so that
optimizers have a lot to work with.


Of course, this gives the code generator a lot of work to do. Making one for
each machine would be a difficult task. Although, for similer machines, the
code generators would probably be similer enough to simply be reconfigured.


I'm interested in target execution speed, compiler speed and portability.
Portability is satisfied by using the pseudo-machine above (except that it
takes a lot of work to port to a new machine). Compiler speed is at least
satisfied by transferring between the source language and the pseudo-machine
language. I'm not sure how fast a translator from the pseudo-machine to an
actual machine language would be. Target execution speed is satisfied in that
an optimizer has all possible information from the source program.


Another advantage of the above approach is that the pseudo-machine is portable
in the other direction. That is, you only need one pseudo-machine translator
for each target machine for all source languages (well almost all: fortran,
cobal, c, pascal, modula, ada would all be compatible. Lisp and prolog
wouldn't.
[From jhallen@wpi.wpi.edu (Joseph H Allen)]
--

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