EMIT would empty a register of its contents (leaving it zero). The hardware may do something reversible with the contents (like send them to some large storage it has available), or do something irreversible. The user should be aware that if he does lots of EMIT operations in a sufficiently large 3-D array of Pendlum processors running at constant speed, physics (heat) will inevitably force the EMIT operations to eventually not work any more, and the register will not always be zero after the EMIT.
EMIT removes the data whether run in ``forwards'' or in ``reverse'' PC updating mode---the data cannot be reobtained by executing the REMOVE instruction backwards. The user should be aware of this as well.
The point of EMIT is to provide a way to compare partial reversibility with full reversibility. A program running outside the simulator can easily measure the total amount of data emitted, and we can collect statistics on how low the rate of emission can be reduced without impacting speed or space requirements too much.
Of course, programs that use EMIT cannot necessarily reverse themselves, although depending on whether the implementation really keeps the data around or not, we may be able to still reverse the system as a whole.
Note that we don't call the instruction ERASE, because we want to emphasize that physics forbids information erasure; the closest thing we can do with information is to emit it out into some system we don't control and can't reverse (thermal motions).
Note that with the entire architecture guaranteed reversible except for EMIT, we have left open all possibilities yet wrapped up all the irreversibility into a neat package. A pendulum program is reversible iff it never uses EMIT. A pure-reversible version of Pendulum is just a Pendulum in which EMIT isn't provided.
A good implementation of EMIT will attempt to tie up as
little energy as possible in the removed data, though
of course this can never be less than 
times
the temperature of the system where the data finally
ends up.