Fine with me. I have used it only for testing purposes, mostly because it's so slow.
On Mon, Jan 21, 2019 at 3:48 PM Taylor R Campbell <[email protected]> wrote: > In commit 1496f4c1d507dab5521309520de5c77ba3b5d82d, I changed the > execute cache mechanism in SVM1 to be simpler, probably faster, and > endian-independent, a few hours after struggling with a kludgey > version of execute caches that would work on big-endian systems. > > However, I goofed: I said in the commit message that it's compatible > so that existing unlinked .com files will continue to work, but that's > not true. While I didn't change the meaning of any SVM1 byte code > instructions, the way you invoke the new-style execute caches with an > IJUMP instruction is different, so the old compiled code that jumps to > them with JUMP won't work. > > I can undo this, but it'll be a bit of work and either we'd have to > break big-endian SVM1 again or go back to the larger execute caches I > briefly implemented in e44423bd982a31c6b7db77eaa7f96bbfbc503935 or > something. > > Is anyone likely to have been using SVM1 extensively enough to care? > > > (I used it on my ARM64 laptop, but now that the aarch64 compiler back > end is nearly complete on the riastradh-20190113-aarch64 branch, I > don't need that any more, not even as an intermediate stage now that > cross-compilation works better. I used it on a PowerPC system, but, > well, the old execute caches never worked on big-endian, so it was > only with the new execute cache layout anyway!) > > _______________________________________________ > MIT-Scheme-devel mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/mit-scheme-devel >
_______________________________________________ MIT-Scheme-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
