[m-dev.] for review: new method of handling failures, part 1 of 6
Zoltan Somogyi
zs at cs.mu.OZ.AU
Sat Jul 4 15:40:17 AEST 1998
> Why not do it this way:
>
> - in runtime/mercury_stacks.h, always define a redofr slot;
> don't make this conditional on MR_USE_REDOFR.
> (This should still work fine, even when compiling with
> the old compiler.)
>
> - in runtime/mercury_grade.h, always include `redofr_' in the
> mangled grade identifier (this prevents linking
> code compiled with the old version of the runtime with
> code compiled with the new version of the runtime)
>
> (Note that even linking files compiled with the new compiler with files
> compiled with the old compiler should be fine, so long as they were
> all compiled with the new runtime.)
The problem is not the addition of the redofr slot; I agree that by itself
this would not present any problems. The problem is: what does fail() set
curfr to? Code generated by the old version of the compiler expects fail()
to set curfr to maxfr, while the new version expects it to set it to
bt_redofr(maxfr). The choice is made in the runtime, when we expand the
fail() macro in mercury_engine.c. This is why the one runtime grade - two
compiler grades (one for stage1 and one for stages 2&3) approach won't work.
Zoltan.
More information about the developers
mailing list