On Wed, 13 Mar 2002, Anthony Hannan wrote:

> Below is a small C program that copies some of its machine code to
> dynamic memory and executes it.  It works on my Linux-i86.  I was
> thinking we could use this technique to dynamically translate bytecodes
> into native code, without using machine-dependent assembly language.  I
> would like to find out if this C example works on other platforms.  I

In practice, not likely, for a few reasons.. First, not all platforms have
pc-relative jumps, or will use PC-relative jumps for cross-module jumps..

They may, for example, use runtime-computed jumps for cross module jumps.
(Or relative jumps from a register that points to the start of code for
this module (file)

Another issue is that many architectures have a GOT.. Basically, when you
compile several modules, each module finds its global (or file-local)
variables by indexing off of a GOT pointer. (stored in a register).. This
pointer must be set upon function entry, and restored on function exit (as
part of the ABI.

Copying binary code won't necessarly work in this case.

Another thing that can make code not-relocatable would be if the linker
directly patches up executable with absolute addresses. All in all, this
probalby won't work, or if it does in one particular case, it is likely to
be fragile and break, for example when global variables are added to a
module or other things.

> would appreciate people testing it.  Note, it does use a GNU C
> extension, namely goto expressions.  But we use goto expressions already

May I suggest looking at how gforth is implemented. (GNU Forth is a forth
interpreter/compiler that I looked at for ideas in helping the squeak VM.)
It includes several interpreter engines and can handle both indirect and
direct threaded. It also runs on a huge number of platforms. I *HIGHLY*
suggest you look at it, both the implementation docs and the code
implementing the design.

I'd considered something similar for squeak, but I don't think
the gains would be all that high, compared to having to redo an entire
interpreter.

> in gnuify.  Is GNU used/available for most other platforms.  Ie. can we
> base our portability on GNU-C instead of just ANSI-C?

This was my other question... I thought it would be hard, politically, to
do this.

Scott