On Wed, 2005-09-07 at 10:00 +0200, Nicolas Cannasse wrote:
> > 3. And please can you comment whether you expect this
> > to build on x86_64 so I can be a user instead of a lurker?
> 
> Answer 1 : Not planed right now, since I don't have the hardware
> Answer 2 : I'm accepting patches ;)

You may need to do more than that. You may need to go through
all of the code yourself, since you wrote it, and fix it
to use proper type names 'as if they were abstract'.

Otherwise given the following non-strictly conforming C code,
from vm/alloc.c:

value alloc_module_function( void *m, int pos, int nargs ) {
        vfunction *v;
        if( nargs < 0 && nargs != VAR_ARGS )
                failure("alloc_module_function");
        v = (vfunction*)GC_MALLOC(sizeof(vfunction));
        v->t = VAL_FUNCTION;
        v->addr = (void*)pos; // ERROR!!
        v->nargs = nargs;
        v->env = alloc_array(0);
        v->module = m;
        return (value)v;
}

how could anyone know what you're trying to do??

The argument of this function is plain wrong: pos cannot be
an integer. You need to choose a proper type name, such as
WORD or CELL or something, which fits your abstraction.

Then you have to program 'as if' the type really were abstract;
for example you HAVE to write

        v-> addr = WORD_AS_ADDR(pos)

using a macro. The abstraction, though not enforcible, allows
you to define the macros for different architectures.

The problem with someone *other* than you patching the code
is that we would have to second guess your intent 

-- and there will be a LOT of code patched --

There are hundreds  of these errors in the vm code:
every second or third line is wrong. I can't tell which
ints are intended to be integers, and which are intended
to be addresses with some flags packed into them,
or whether they're actually addresses, which is really
silly, since you can do address calculations with the type:

        typedef unsigned char *addr_t;

in particular you can add offsets .. but NOT multiply.

I suspect if you did this all religiously "as if it were
Ocaml" then the 64 bit port would be a matter of changing
one or two lines of code (which the configure script could
do easily).

-- 
John Skaller <skaller at users dot sourceforge dot net>

Attachment: signature.asc
Description: This is a digitally signed message part

---
Neko : One VM to run them all

Reply via email to