Alex --
> The MIPSPro compiler is not happy with Parrot (it used to be though).
> Everything is fine with gcc on the same system, which implies that some
> nastiness has slipped in at some point.
> ...
Sure enough. 'nm -u interpreter.o | grep runops' shows runops_cores is
not unresolved. I just
At 12:30 PM 10/18/2001 +0100, Simon Cozens wrote:
>On Mon, Oct 08, 2001 at 06:36:32PM -0400, Dan Sugalski wrote:
> > P1->vtable_funcs[VTABLE_ADD + P2->num_type](P1, P2, P0);
>
>Uhm, since num_type and vtable_funcs are part of the vtable
>structure, that would be more like
> P1->vtable->vt
The MIPSPro compiler is not happy with Parrot (it used to be though).
Everything is fine with gcc on the same system, which implies that some
nastiness has slipped in at some point.
I think it may have something to do with these warnings:
[gcc] ld32: WARNING 105: Common symbol "runops_cores" def
http://www-124.ibm.com/developerworks/oss/jikesrvm/
The JikesT Research Virtual Machine (Jikes RVM) provides the academic and
research communities with a flexible open testbed to prototype new virtual
machine technologies and experiment with a large variety of design
alternatives.
The virtual mac
I've committed the following patch, which allows vtable
ops to be called for some of the simpler functions. Yes,
I know we don't actually have the vtable methods yet, but
I'm working on it; I'll try and have some of them done by
the end of the day.
The tricky part is making them maintainable.
On Mon, Oct 08, 2001 at 06:36:32PM -0400, Dan Sugalski wrote:
> P1->vtable_funcs[VTABLE_ADD + P2->num_type](P1, P2, P0);
Uhm, since num_type and vtable_funcs are part of the vtable
structure, that would be more like
P1->vtable->vtable_funcs[VTABLE_ADD + P2->vtable->num_type](P1, P2, P0);
