[m-dev.] MR_{save/restore}_transient_hp().

Paul Bone paul at bone.id.au
Thu Jul 24 19:22:48 AEST 2014

On Thu, Jul 24, 2014 at 10:07:10AM +0200, Zoltan Somogyi wrote:
> On Thu, 24 Jul 2014 12:17:30 +1000, Paul Bone <paul at bone.id.au> wrote:
> > What I don't know is when this says "from C" does it mean from foreign_proc
> > macros?  And do I understand correctly that the concern is that the heap
> > pointer is saved in a register that may be clobbered by external C code, and
> > therefore I need to restore that pointer before allocating memory and save
> > it again after allocating the memory?
> The macros that have "transient" in their name are there to allow code to handle
> a mismatch between the register model used by the Mercury low level abstract
> machine (i.e. the registers are always there, and are modified only by explicit
> assignments to them), and the sliding register windows on SPARC (the set of
> visible registers changes with every call and return instruction, and therefore
> those instructions implicitly change the values stored in the windowed registers).
> The relevant criterion is not C code versus Mercury code, but code that can
> make ISA calls and code that cannot. In grade asm_fast, Mercury does not
> make ISA calls; it just does jumps. Foreign code that does not make calls
> is the same. Foreign code that does make calls, and parts of the runtime
> that make calls, do need to be protected against registers changing as if
> by magic. If I recall correctly, the protocol is to save any transient registers
> before the call or return (which copies them to the global variable or global
> array slot reserved for them), and restore them after the call/return. Restore
> is needed only before code that may use the relevant register. If Mercury
> calls f which calls g, and only g uses a register, then g needs to restore it,
> but f does not. If g can modify the register, then it needs to save it when it is
> done, and the Mercury code calling f must restore it on return from f.
> The relevant comment is this one in mercury_regs.h:


Is SPARC the only not-completely-dead architecture to use register windows?

> ** The MR_save_transient_registers() and MR_restore_transient_registers()
> ** macros are similar to MR_save_mhal_registers() and
> ** MR_restore_mhal_registers() except that they only save/restore registers
> ** which can be affected by calling or returning from a C function (e.g.
> ** by sliding register windows on SPARCs).
> Note that transient registers are a fruitful source of obscure and hard-to-
> track-down bugs on SPARCs. Code that does not use them properly (or at
> all) often works just fine on every ISA except SPARC, and there is no practical
> way to track down or even detect such bugs without a SPARC machine.
> Since SPARC is a dying architecture, it makes me wonder whether anyone
> is still using Mercury on SPARC. If not, we should probably stop supporting it.

Didn't someone contact us a few years ago about Mercury on something like a
SPARC?  Or was it just SunOS or Solaris that they wanted support with?

We can always support things like this via some other backend, like hlc.gc,
although there are some missing features.

Paul Bone

More information about the developers mailing list