guile-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Guile-commits] 181/437: Correct description of the jmpi instruction.


From: Andy Wingo
Subject: [Guile-commits] 181/437: Correct description of the jmpi instruction.
Date: Mon, 2 Jul 2018 05:14:13 -0400 (EDT)

wingo pushed a commit to branch lightning
in repository guile.

commit 708cca94653026874b4c186663bfb71afa308d2c
Author: pcpa <address@hidden>
Date:   Wed Jan 30 18:11:43 2013 -0200

    Correct description of the jmpi instruction.
    
        * doc/body.texi: Correct "jmpi" description that incorrectly
        told it was possible to pass any address as jump target. The
        only way to do that is "movi+jmpr".
---
 ChangeLog     |  6 ++++++
 TODO          | 16 +++++++++++-----
 doc/body.texi | 13 +++++++------
 3 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 0c929d3..fe58a50 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2013-01-30 Paulo Andrade <address@hidden>
 
+       * doc/body.texi: Correct "jmpi" description that incorrectly
+       told it was possible to pass any address as jump target. The
+       only way to do that is "movi+jmpr".
+
+2013-01-30 Paulo Andrade <address@hidden>
+
        * lib/jit_x86-cpu.c: Correct undefined behavior code.
        http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56143
 
diff --git a/TODO b/TODO
index fb21097..30c42c2 100644
--- a/TODO
+++ b/TODO
@@ -1,8 +1,14 @@
-       * Remove JIT_RET and JIT_FRET. Only interface to these should
-       be jit_retval, jit_retval_f and jit_retval_d, otherwise one
-       may use JIT_RET and/or JIT_FRET as argument to other jit calls,
-       what may cause problems at least on the arm backend.
-
        * Update documentation to match new implementation.
 
        * Make an sparc port to not remove previous functionality.
+
+       * Add two new base instructions to help dynamically typed
+       languages, that use two result registers and two argument
+       registers, implementing multiplication and quotient+remainder
+       return from division. Alternatively, can add branch codes
+       for multiplication that overflows (and reverse for no
+       overflow) and division with zero remainder or non zero
+       remainder.
+       Suggested names for now are "qmul" and "qdiv", with "r"
+       and "i" variants, and possibly unsigned version. Branches
+       would use "bo" and "bx" prefix.
diff --git a/doc/body.texi b/doc/body.texi
index af924e8..1c14544 100644
--- a/doc/body.texi
+++ b/doc/body.texi
@@ -488,7 +488,8 @@ callr     (not specified)                @r{function call 
to a register}
 calli     (not specified)                @r{function call to O1}
 finishr   (not specified)                @r{function call to a register}
 finishi   (not specified)                @r{function call to O1}
-jmpi/jmpr (not specified)                @r{unconditional jump to O1}
+jmpr      (not specified)                @r{unconditional jump to register}
+jmpi      (not specified)                @r{unconditional jump}
 ret       (not specified)                @r{return from subroutine}
 retr      _c _uc _s _us _i _ui _l _f _d
 reti      _c _uc _s _us _i _ui _l _f _d
@@ -1067,11 +1068,11 @@ a pointer to a C function. Note that conditional 
branches do not
 receive a label argument, so they must be patched.
 
 You need to call @code{patch_at} on the return of value @code{calli},
address@hidden, @code{jmpi} and @code{calli} if it is actually
-referencing a label in the jit code. All other branch instructions
-do not receive a label argument. Note that @code{movi} is an special
-case, and patching it is usually done to get the final address of
-a label, usually to later call @code{jmpr}.
address@hidden, and @code{calli} if it is actually referencing a label
+in the jit code. All branch instructions do not receive a label
+argument. Note that @code{movi} is an special case, and patching it
+is usually done to get the final address of a label, usually to later
+call @code{jmpr}.
 
 Now, here is the iterative version:
 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]