Nabble - Gnu - Lightning

Re: Subtract with borrow

2009-08-04T23:47:23Z

FWIW, here's a test case to verify the bug. It prints -3 (wring) and
not 3 (correct).

I'm not using Lightning except as a quarry for useful bits of code, so I
won't suggest a fix.

"Bad" is a relative term here, and a register allocator can avoid most
of the bad cases in most instructions by making rd = rs1 wherever
possible.

-- Mike

#include <stdio.h>
#include "lightning.h"

static jit_insn codeBuffer[1024];

typedef int (*pifi)(int, int);

int main()
{
pifi subr = (pifi) (jit_set_ip(codeBuffer).iptr);
int in1, in2;

jit_leaf(2);
in1 = jit_arg_i();
in2 = jit_arg_i();
jit_getarg_i(JIT_R0, in1);
jit_getarg_i(JIT_R1, in2);
jit_subcr_i(JIT_R2, JIT_R2, JIT_R2); /* Clear carry */
jit_subxr_i(JIT_R1, JIT_R0, JIT_R1);
jit_movr_i(JIT_RET, JIT_R1);
jit_ret();

jit_flush_code(codeBuffer, jit_get_ip().ptr);

/* call the generated code, passing 5 as an argument */
printf("result = %d\n", subr(5, 2));
return 0;
}

On Wed, 2009-08-05 at 01:10 +0200, Paolo Bonzini wrote:

> On 08/04/2009 07:19 PM, Mike Spivey wrote:
> > The i386 implementation in GIT contains the definition for
> > subtract-with-carry:
> >
> > #define jit_subxr_i(d, s1, s2) \
> > jit_opr_((d), (s1), (s2), SBBLrr((s1), (d)), SBBLrr((s2), (d)) )
> >
> > Please forgive my not compiling a test, but doesn't this treat
> > subtraction as if it is commutative? Correct code for the case where
> > s1 != d but s2 = d will be embarrassingly bad, but (if I'm right about
> > the error) bad code is better than wrong code, always!
>
> I think you're right... :-(
>
> (The code wouldn't be so bad, it just needs some push/pops).
>
> Paolo

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: Subtract with borrow

2009-08-04T16:10:35Z

On 08/04/2009 07:19 PM, Mike Spivey wrote:

> The i386 implementation in GIT contains the definition for
> subtract-with-carry:
>
> #define jit_subxr_i(d, s1, s2) \
> jit_opr_((d), (s1), (s2), SBBLrr((s1), (d)), SBBLrr((s2), (d)) )
>
> Please forgive my not compiling a test, but doesn't this treat
> subtraction as if it is commutative? Correct code for the case where
> s1 != d but s2 = d will be embarrassingly bad, but (if I'm right about
> the error) bad code is better than wrong code, always!

I think you're right... :-(

(The code wouldn't be so bad, it just needs some push/pops).

Paolo

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Subtract with borrow

2009-08-04T10:19:10Z

The i386 implementation in GIT contains the definition for
subtract-with-carry:

#define jit_subxr_i(d, s1, s2) \
jit_opr_((d), (s1), (s2), SBBLrr((s1), (d)), SBBLrr((s2), (d)) )

Please forgive my not compiling a test, but doesn't this treat
subtraction as if it is commutative? Correct code for the case where
s1 != d but s2 = d will be embarrassingly bad, but (if I'm right about
the error) bad code is better than wrong code, always!

Best wishes,

-- Mike

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: Is anyone still here?

2009-05-26T05:46:15Z

David A. Cobb wrote:
> Pardon the listspam, please. I'm new to lightning.
> It appears the code hasn't been touched since 2004. Of course, maybe
> there's nothing to be done. ;-D

Updated code is in the git repository at
git://git.sv.gnu.org/lightning.git but you can get a snapshot at any
time from
http://git.savannah.gnu.org/cgit/lightning.git/snapshot/lightning-master.tar.gz

> On the other hand, I'm getting a batch of warnings when I make it. I
> would guess, without much research, that perhaps gcc has tightened up
> some standard?

The warnings are expected, you can use -Wno-unused (they all come from
the same source).

Regarding CLISP, post them, but chances are you should go to the CLISP
mailing list.

Paolo

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Is anyone still here?

2009-05-25T12:55:33Z

Pardon the listspam, please. I'm new to lightning.
It appears the code hasn't been touched since 2004. Of course, maybe
there's nothing to be done. ;-D
On the other hand, I'm getting a batch of warnings when I make it. I
would guess, without much research, that perhaps gcc has tightened up
some standard?
When I try to use lightning to build a clisp, I get errors that seem to
be lightning-related.
Is it worth chasing any of these things down?

TIA
--
David A. Cobb, (t-rex, by any other name, is still a dinosaur)

[superbiskit.vcf]

begin:vcard fn:David A. Cobb n:Cobb;David A. email;internet:superbiskit@... tel;home:+1-401-615-3895 tel;cell:+1-401-301-2207 note;quoted-printable:Semi-retired T-Rex Mainframe Programmer=0D=0A= Orthodox Christian=0D=0A= x-mozilla-html:TRUE version:2.1 end:vcard

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: Let's shift again

2009-02-21T04:27:16Z

Alas, that patch doesn't work either in cases such as lshr_i R0 R1 R0. I think
I've fixed the problem, and have written more test cases, but I'll ponder it for a
while before posting more code.

-- Mike

Mike Spivey wrote:

> Dear Paolo and all,
>
> I'm sorry to say it, but the shift instructions still aren't working on i386. In
> particular, "lshr_i V0 R1 V2" results in a message saying that the instruction is
> unimplemented, but in fact "lshr_i R1 V1 V2" gives the wrong answers. (The problem
> arises because i386 insists on having the *third* operand in ECX aka R1, so some
> moves must be inserted if any other register is used.)
>
> I've attached a test case that can be compiled with -DUNFIXED or -DFIX1 or -DFIX2.
> With FIX1, the instruction "lshr_i V0 R1 V2" works correctly, and "lshr_i R1 V1
> V2" is unimplemented. The fix is a simple matter of nesting calls to jit_op_ and
> jit_replace in the opposite order with a couple of adjustments.
>
> A better fix is provided with FIX2, because there R1 can be used as any of the
> registers, but of course with varying penalties in pushes and pops and moves.
>
> Best wishes,
>
> -- Mike
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Lightning mailing list
> Lightning@...
> http://lists.gnu.org/mailman/listinfo/lightning

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Let's shift again

2009-02-20T13:57:24Z

Dear Paolo and all,

I'm sorry to say it, but the shift instructions still aren't working on i386. In
particular, "lshr_i V0 R1 V2" results in a message saying that the instruction is
unimplemented, but in fact "lshr_i R1 V1 V2" gives the wrong answers. (The problem
arises because i386 insists on having the *third* operand in ECX aka R1, so some
moves must be inserted if any other register is used.)

I've attached a test case that can be compiled with -DUNFIXED or -DFIX1 or -DFIX2.
With FIX1, the instruction "lshr_i V0 R1 V2" works correctly, and "lshr_i R1 V1
V2" is unimplemented. The fix is a simple matter of nesting calls to jit_op_ and
jit_replace in the opposite order with a couple of adjustments.

A better fix is provided with FIX2, because there R1 can be used as any of the
registers, but of course with varying penalties in pushes and pops and moves.

Best wishes,

-- Mike

#include <stdio.h>
#include "lightning.h"

#ifdef UNFIXED
/* Existing version of lightning gives wrong results for the PART3 tests,
and wrongly claims that the PART2 tests are not supported */
#define PART3
#endif

#ifdef FIX1
/* This simple fix makes the PART2 tests work, but does not support the
PART3 tests */
#define PART2

#undef jit_lshr_i
#undef jit_rshr_i
#undef jit_rshr_ui

#define jit_lshr_i(d, r1, r2) \
jit_op_((d), (r1), jit_replace((d), (r2), _ECX, SHLLrr(_CL, (d))))
#define jit_rshr_i(d, r1, r2) \
jit_op_((d), (r1), jit_replace((d), (r2), _ECX, SARLrr(_CL, (d))))
#define jit_rshr_ui(d, r1, r2) \
jit_op_((d), (r1), jit_replace((d), (r2), _ECX, SHRLrr(_CL, (d))))

#endif

#ifdef FIX2
/* A better fix that additionally supports having R1 = ECX as the
destination register, passing all tests. */
#define PART2
#define PART3

#undef jit_lshr_i
#undef jit_rshr_i
#undef jit_rshr_ui

#define jit_lshr_i(d, r1, r2) jit_shift(d, r1, r2, SHLLrr)
#define jit_rshr_i(d, r1, r2) jit_shift(d, r1, r2, SARLrr)
#define jit_rshr_ui(d, r1, r2) jit_shift(d, r1, r2, SHRLrr)

#define jit_shift(d, r1, r2, m) \
(((d) == _ECX) \
? (jit_pushr_i(_EAX), jit_shiftop(_EAX, r1, r2, m), \
MOVLrr(_EAX, d), jit_popr_i(_EAX)) \
: jit_shiftop(d, r1, r2, m))

#define jit_shiftop(d, r1, r2, m) \
jit_op_((d), (r1), jit_replace((d), (r2), _ECX, m(_CL, (d))))

#endif

static jit_insn codeBuffer[1024];

typedef int (*pifi)(int); /* Pointer to Int Function of Int */

void test(int n, int r1, int r2, int r3, int res, int exp) {
pifi fun = (pifi) (jit_set_ip(codeBuffer).iptr);
int in, out;

jit_prolog(1);
in = jit_arg_i();
jit_getarg_i(r2, in);

jit_movi_i(r3, 2);
jit_lshr_i(r1, r2, r3);
jit_movr_i(JIT_RET, res);
jit_ret();

jit_flush_code(codeBuffer, jit_get_ip().ptr);

out = fun(-16);
printf("test %d: %d / %d\n", n, out, exp);
}

int main() {
test(11, JIT_V0, JIT_V1, JIT_V2, JIT_V0, -64);
test(12, JIT_V0, JIT_V1, JIT_V2, JIT_V1, -16);
test(13, JIT_V0, JIT_V1, JIT_V2, JIT_V2, 2);

#ifdef PART2
test(21, JIT_V0, JIT_R1, JIT_V2, JIT_V0, -64);
test(22, JIT_V0, JIT_R1, JIT_V2, JIT_R1, -16);
test(23, JIT_V0, JIT_R1, JIT_V2, JIT_V2, 2);
#endif

#ifdef PART3
test(31, JIT_R1, JIT_V1, JIT_V2, JIT_R1, -64);
test(32, JIT_R1, JIT_V1, JIT_V2, JIT_V1, -16);
test(33, JIT_R1, JIT_V1, JIT_V2, JIT_V2, 2);
#endif

test(41, JIT_V0, JIT_V1, JIT_R1, JIT_V0, -64);
test(42, JIT_V0, JIT_V1, JIT_R1, JIT_V1, -16);
test(43, JIT_V0, JIT_V1, JIT_R1, JIT_R1, 2);

return 0;
}

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: Shift instructions

2009-02-19T11:22:06Z

Mike Spivey wrote:
> I spoke five minutes too soon:

... and I spoke five minutes too late. :-)

Thanks.

Paolo

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: Shift instructions

2009-02-19T11:21:30Z

> I am sorry to be always the bearer of bad tidings, but there it is! Can
> anything be done?

I'll take a look.

Paolo

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: Shift instructions

2009-02-19T11:16:55Z

I spoke five minutes too soon:

diff --git a/lightning/i386/core.h b/lightning/i386/core.h
index 86aee39..2f017f9 100644
--- a/lightning/i386/core.h
+++ b/lightning/i386/core.h
@@ -63,7 +63,7 @@
((rd == forced) ? JITSORRY("Register conflict for " # op) : \
(rs == forced) ? op : \
jit_save (forced) \
- ? (jit_pushr_i(forced), jit_movr_l(rs, forced), op, \
+ ? (jit_pushr_i(forced), jit_movr_l(forced, rs), op, \
jit_popr_i(forced)) \
: (jit_movr_l(rs, forced), op))

Best wishes,

-- Mike

Mike Spivey wrote:

> Dear Paolo and all,
>
> Attached is a program that attempts to compute (-16) << 2. The result
> should be -64, but -16 is printed on i386.
>
> I've tried a number of combinations, but haven't quite tracked down the
> problem yet:
>
> * Use JIT_R1 instead of JIT_V0 throughout --> fixed.
>
> * Insert jit_movi_i(JIT_R1, 3); before the shift instruction (but leave
> instruction referring to JIT_V0) --> result is -128.
>
> * Use a jit_mulr_i instruction instead of the shift --> correct result.
>
> * Use jit_lshi_i instead of jit_lshr_i --> correct result.
>
> So it looks like the problem concerns putting the shift amount into the
> ECX register before the actual shift instruction.
>
> I am sorry to be always the bearer of bad tidings, but there it is! Can
> anything be done?
>
> Best wishes,
>
> -- Mike
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Lightning mailing list
> Lightning@...
> http://lists.gnu.org/mailman/listinfo/lightning

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Shift instructions

2009-02-19T11:10:02Z

Dear Paolo and all,

Attached is a program that attempts to compute (-16) << 2. The result
should be -64, but -16 is printed on i386.

I've tried a number of combinations, but haven't quite tracked down the
problem yet:

* Use JIT_R1 instead of JIT_V0 throughout --> fixed.

* Insert jit_movi_i(JIT_R1, 3); before the shift instruction (but leave
instruction referring to JIT_V0) --> result is -128.

* Use a jit_mulr_i instruction instead of the shift --> correct result.

* Use jit_lshi_i instead of jit_lshr_i --> correct result.

So it looks like the problem concerns putting the shift amount into the
ECX register before the actual shift instruction.

I am sorry to be always the bearer of bad tidings, but there it is! Can
anything be done?

Best wishes,

-- Mike

#include <stdio.h>
#include "lightning.h"

static jit_insn codeBuffer[1024];

typedef int (*pifi)(int); /* Pointer to Int Function of Int */

int main()
{
pifi fun = (pifi) (jit_set_ip(codeBuffer).iptr);
int in;

jit_prolog(1);
in = jit_arg_i();
jit_getarg_i(JIT_V2, in);

jit_movi_i(JIT_V0, 2);
jit_lshr_i(JIT_V1, JIT_V2, JIT_V0);
jit_movr_i(JIT_RET, JIT_V1);
jit_ret();

jit_flush_code(codeBuffer, jit_get_ip().ptr);

printf("fun(-16) = %d\n", fun(-16));
return 0;
}

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: Floating point branches

2009-02-17T03:17:30Z

Paolo Bonzini wrote:
> Mike Spivey wrote:
>> I encountered three problems with floating point branches on i386 with
>> the GIT version of lightning. The patches shown below seem to work for
>> me, but I haven't made extensive tests.
>
> Great, thanks. I attach what I applied.
>
> Paolo
>

Sorry, one more correction that you missed in your patch. In the
jit_fp_btest macro:

diff --git a/lightning/i386/fp-32.h b/lightning/i386/fp-32.h
index 71e5677..b957b69 100644
--- a/lightning/i386/fp-32.h
+++ b/lightning/i386/fp-32.h
@@ -262,7 +262,7 @@ union jit_double_imm {
((cmp) ? CMPLir ((cmp), _AL) : 0), \
POPLr(_EAX), \
res ((d)), \
- _jit.x.ppc)
+ _jit.x.pc)

#define jit_nothing_needed(x)

-- Mike

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: Floating point branches

2009-02-17T00:54:34Z

Mike Spivey wrote:
> I encountered three problems with floating point branches on i386 with
> the GIT version of lightning. The patches shown below seem to work for
> me, but I haven't made extensive tests.

Great, thanks. I attach what I applied.

Paolo

diff --git a/ChangeLog b/ChangeLog
index bda065e..a842218 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2009-02-17 Paolo Bonzini <bonzini@...>
+
+ * lightning/fp-common.h: Define double branches if missing.
+ * lightning/i386/asm.h: Define JC and JNC mnemonics.
+ * lightning/i386/fp-32.h: Fix jit_fp_btest. All reported
+ by Mike Spivey.
+
2008-10-09 Paolo Bonzini <bonzini@...>

* lightning/ppc/funcs.h (jit_flush_code): Subtract 1 from end.
diff --git a/THANKS b/THANKS
index 0276167..fe8ad1e 100644
--- a/THANKS
+++ b/THANKS
@@ -5,6 +5,7 @@ Eli Barzilay <eli@...>
Ludovic Courtes <ludo@...>
Matthew Flatt <mflatt@...>
Laurent Michel <ldm@...>
+Mike Spivey <mike@...>
Basile Starynkevitch <basile@...>
Sam Steingold <sds@...>
Jens Troeger <savage@...>
diff --git a/doc/version.texi b/doc/version.texi
index bbcbdc5..a763770 100644
--- a/doc/version.texi
+++ b/doc/version.texi
@@ -1,4 +1,4 @@
-@set UPDATED 9 January 2008
-@set UPDATED-MONTH January 2008
+@set UPDATED 13 June 2008
+@set UPDATED-MONTH June 2008
@set EDITION 1.2c
@set VERSION 1.2c
diff --git a/lightning/fp-common.h b/lightning/fp-common.h
index d65d160..0847ceb 100644
--- a/lightning/fp-common.h
+++ b/lightning/fp-common.h
@@ -85,6 +85,23 @@
#define jit_retval_f(rs) jit_retval_d(rs)
#endif

+#ifndef jit_beqr_f
+#define jit_beqr_f(lab, a, b) jit_beqr_d(lab, a, b)
+#define jit_bner_f(lab, a, b) jit_bner_d(lab, a, b)
+#define jit_bgtr_f(lab, a, b) jit_bgtr_d(lab, a, b)
+#define jit_bger_f(lab, a, b) jit_bger_d(lab, a, b)
+#define jit_bltr_f(lab, a, b) jit_bltr_d(lab, a, b)
+#define jit_bler_f(lab, a, b) jit_bler_d(lab, a, b)
+#define jit_buneqr_f(lab, a, b) jit_buneqr_d(lab, a, b)
+#define jit_bltgtr_f(lab, a, b) jit_bltgtr_d(lab, a, b)
+#define jit_bungtr_f(lab, a, b) jit_bungtr_d(lab, a, b)
+#define jit_bunger_f(lab, a, b) jit_bunger_d(lab, a, b)
+#define jit_bunltr_f(lab, a, b) jit_bunltr_d(lab, a, b)
+#define jit_bunler_f(lab, a, b) jit_bunler_d(lab, a, b)
+#define jit_bordr_f(lab, a, b) jit_bordr_d(lab, a, b)
+#define jit_bunordr_f(lab, a, b) jit_bunordr_d(lab, a, b)
+#endif
+
#ifndef jit_retval_f
#define jit_retval_f(op1) jit_movr_f((op1), JIT_FPRET)
#endif
diff --git a/lightning/i386/asm.h b/lightning/i386/asm.h
index ad404fc..2dec4b9 100644
--- a/lightning/i386/asm.h
+++ b/lightning/i386/asm.h
@@ -915,8 +915,10 @@ enum {
#define JOSm(D) JCCSim(0x0, D)
#define JNOSm(D) JCCSim(0x1, D)
#define JBSm(D) JCCSim(0x2, D)
+#define JCSm(D) JCCSim(0x2, D)
#define JNAESm(D) JCCSim(0x2, D)
#define JNBSm(D) JCCSim(0x3, D)
+#define JNCSm(D) JCCSim(0x3, D)
#define JAESm(D) JCCSim(0x3, D)
#define JESm(D) JCCSim(0x4, D)
#define JZSm(D) JCCSim(0x4, D)
@@ -946,8 +948,10 @@ enum {
#define JOm(D) JCCim(0x0, D)
#define JNOm(D) JCCim(0x1, D)
#define JBm(D) JCCim(0x2, D)
+#define JCm(D) JCCim(0x2, D)
#define JNAEm(D) JCCim(0x2, D)
#define JNBm(D) JCCim(0x3, D)
+#define JNCm(D) JCCim(0x3, D)
#define JAEm(D) JCCim(0x3, D)
#define JEm(D) JCCim(0x4, D)
#define JZm(D) JCCim(0x4, D)
diff --git a/lightning/i386/fp-32.h b/lightning/i386/fp-32.h
index ff59631..71e5677 100644
--- a/lightning/i386/fp-32.h
+++ b/lightning/i386/fp-32.h
@@ -261,7 +261,7 @@ union jit_double_imm {
((_and) ? ANDLir ((_and), _EAX) : 0), \
((cmp) ? CMPLir ((cmp), _AL) : 0), \
POPLr(_EAX), \
- res ((d), 0, 0, 0), \
+ res ((d)), \
_jit.x.ppc)

#define jit_nothing_needed(x)

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Floating point branches

2009-02-17T00:32:24Z

I encountered three problems with floating point branches on i386 with
the GIT version of lightning. The patches shown below seem to work for
me, but I haven't made extensive tests.

-- Mike

(i) Instructions beqr_f, ... are not defined, but only beqr_d, ... On
i386, they are the same, but maybe not on other architectures.
Solution:

#ifndef jit_beqr_f
#define jit_beqr_f(lab, a, b) jit_beqr_d(lab, a, b)
#define jit_bner_f(lab, a, b) jit_bner_d(lab, a, b)
#define jit_bgtr_f(lab, a, b) jit_bgtr_d(lab, a, b)
#define jit_bger_f(lab, a, b) jit_bger_d(lab, a, b)
#define jit_bltr_f(lab, a, b) jit_bltr_d(lab, a, b)
#define jit_bler_f(lab, a, b) jit_bler_d(lab, a, b)
#endif

(ii) The floating point branches depend on the existence of operations
JCm and JNCm that don't exist. They should be synonyms for JBm and
JNBm. Solution:

#ifndef JCm
#define JCm JBm
#define JNCm JNBm
#endif

(iii) The macro jit_fp_btest wrongly ends with a call to
res ((d), 0, 0, 0). This should read res (d). Solution:

#undef jit_fp_btest

#define jit_fp_btest(d, s1, s2, n, _and, cmp, res) \
(((s1) == 0 ? FUCOMr((s2)) : (FLDr((s1)), FUCOMPr((s2) + 1))), \
PUSHLr(_EAX), \
FNSTSWr(_EAX), \
SHRLir(n, _EAX), \
((_and) ? ANDLir ((_and), _EAX) : 0), \
((cmp) ? CMPLir ((cmp), _AL) : 0), \
POPLr(_EAX), \
res (d), \
_jit.x.pc)

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Floating point branches

2009-02-16T10:02:41Z

Re: Releases?

2009-02-03T00:58:56Z

Hi,

"Tobias C. Rittweiler" <tcr@...>
writes:

> In that thread, it's mentioned there's a release 1.2c, but I cannot find
> any newer release on
>
> http://ftp.gnu.org/gnu/lightning/

Try ftp://alpha.gnu.org/gnu/lightning/.

Thanks,
Ludo'.

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Releases?

2009-02-02T11:20:53Z

I'm using the Lightning's Debian package which says it's version
"1.2-4"; it seems to be from 2004.

I encountered the same problem as the the OP in

http://www.nabble.com/jit_allocai-instruction-macro-td18253220.html

In that thread, it's mentioned there's a release 1.2c, but I cannot find
any newer release on

http://ftp.gnu.org/gnu/lightning/

What do I miss?

-T.

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: how does one implement exceptions?

2008-11-23T07:09:34Z

> (Based on what I've read in the
> mailing list archives, another alternative would be doing a full
> conversion into CPS, having all stack frames in the heap etc.. but I'd
> like to avoid this if at all possible.)

Well, this is just what GNU Smalltalk does. It does not have all stack
frames in the heap, it has stack frames on a separate stack that *are*
allocated/deallocated LIFO. This is what you meant by "using another
memory area for a custom data stack".

> Actually, it seemed to me that Lightning doesn't even let one have
> direct access to the stack pointer and push/pop operations (I suppose
> for platform independence reasons).

It has access to the native stack via a frame pointer. See jit_allocai
and JIT_FP in the manual.

Paolo

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

how does one implement exceptions?

2008-11-22T15:18:47Z

Hiho,
so I'm toying with my Lisp interpreter (yes, another one...), and
thought of using Lightning as a JIT solution. I have no previous
experience with JIT or Lightning, so bear with me :)

I have mostly read the Lightning info pages and documentation I saw,
and I haven't found any hints on how people would implement exceptions
with this toolset. At the very least, this would require something like
setjmp/longjmp, or access to stack frames (reading return IPs, and
doing lookups in tables based on them, oslt). I haven't found anything
in the docs that looked like these.. (Based on what I've read in the
mailing list archives, another alternative would be doing a full
conversion into CPS, having all stack frames in the heap etc.. but I'd
like to avoid this if at all possible.)

Actually, it seemed to me that Lightning doesn't even let one have
direct access to the stack pointer and push/pop operations (I suppose
for platform independence reasons). At least with the naive ways I can
come up with, this makes it hard to generate code for a language with
full lexical scoping and closure support, in such a way that the
generated code used the process' own stack. (Using another memory area
for a custom data stack is a solution for this, of course.)

So, does anyone have any pointers for me regarding these issues?
Thanks,
Mate

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: PPC problem

2008-10-09T22:02:00Z

> Hmm, we have:
>
> start -= ((long) start) & (cache_line_size - 1);
> end -= ((long) end - 1) & (cache_line_size - 1);
>
> which is different. (I'm not too familiar with this code, so I'm
> CCing Matthew too, in case there is something wrong in our version of
> the file.)

No, it was this change:

2008-07-02 Laurent Michel <ldm@...>

* lightning/ppc/funcs.h (jit_flush_code): modified the computation
of start/end. The pointer arithmetic was done without casting. It
prevented compilation with recent gcc versions.

If you have time, I think syncing MzScheme's lightning now would not be
a bad idea.

Paolo

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: PPC problem

2008-10-09T21:49:57Z

On Oct 9, Paolo Bonzini wrote:

> Eli Barzilay wrote:
> >
> > The fix is in "lightning/ppc/funcs.h": subtract 1 from `end' here:
> >
> > end -= ((long) end - 1) & (cache_line_size - 1);
>
> Thanks, here's what I applied:
>
> diff --git a/lightning/ppc/funcs.h b/lightning/ppc/funcs.h
> index 9f3df90..ae9301f 100644
> --- a/lightning/ppc/funcs.h
> +++ b/lightning/ppc/funcs.h
> @@ -67,6 +67,9 @@ jit_flush_code(void *start, void *end)
> break;
> }
>
> + /* Point end to the last byte being flushed. */
> + end =(void*)( (long)(end - 1));
> +
> start =(void*)( (long)start - (((long) start) & (cache_line_size - 1)));
> end =(void*)( (long)end - (((long) end) & (cache_line_size - 1)));

Hmm, we have:

start -= ((long) start) & (cache_line_size - 1);
end -= ((long) end - 1) & (cache_line_size - 1);

which is different. (I'm not too familiar with this code, so I'm
CCing Matthew too, in case there is something wrong in our version of
the file.)

--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: PPC problem

2008-10-09T01:19:35Z

Eli Barzilay wrote:

> There was a PPC problem that we've just fixed, and I'm forwarding it
> here in case it's not fixed in the lightning repository:
>
> (Quoting Matthew Flatt)
>
> The problem was a bug in lightning's icache-flushing code (used by the
> JIT) It could walk one word past the end of an allocated page onto an
> unallocated page. The bug was exposed by yesterday's change to the way
> that memory is allocated to hold JIT-generated native code.
>
> The fix is in "lightning/ppc/funcs.h": subtract 1 from `end' here:
>
> end -= ((long) end - 1) & (cache_line_size - 1);

Thanks, here's what I applied:

diff --git a/lightning/ppc/funcs.h b/lightning/ppc/funcs.h
index 9f3df90..ae9301f 100644
--- a/lightning/ppc/funcs.h
+++ b/lightning/ppc/funcs.h
@@ -67,6 +67,9 @@ jit_flush_code(void *start, void *end)
break;
}

+ /* Point end to the last byte being flushed. */
+ end =(void*)( (long)(end - 1));
+
start =(void*)( (long)start - (((long) start) & (cache_line_size - 1)));
end =(void*)( (long)end - (((long) end) & (cache_line_size - 1)));

Paolo

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

PPC problem

2008-10-08T08:53:02Z

There was a PPC problem that we've just fixed, and I'm forwarding it
here in case it's not fixed in the lightning repository:

(Quoting Matthew Flatt)

The problem was a bug in lightning's icache-flushing code (used by the
JIT) It could walk one word past the end of an allocated page onto an
unallocated page. The bug was exposed by yesterday's change to the way
that memory is allocated to hold JIT-generated native code.

The fix is in "lightning/ppc/funcs.h": subtract 1 from `end' here:

end -= ((long) end - 1) & (cache_line_size - 1);

--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: attempt to build clisp on mingw without debug with lightning is crash

2008-09-17T06:51:27Z

Yaroslav Kavenchuk wrote:

> ;; Loading file C:\gnu\home\src\clisp\clisp\src\clos-genfun1.lisp ...
> *** - handle_fault error2 ! address = 0x9ef50021 not in
> [0x5fde75d8,0x60000000) !
> SIGSEGV cannot be cured. Fault address = 0x9ef50021.
> GC count: 51
> Space collected by GC: 0 23993120
> Run time: 0 66718750
> Real time: 0 72656250
> GC time: 0 3593750
> Permanently allocated: 90304 bytes.
> Currently in use: 3158036 bytes.
> Free space: 752430 bytes.
> make: *** [interpreted.mem] Error 5
>
>
> with debug - all ok.
>
> Any suggestions - how debug it?

rm -f *.o
edit Makefile and replace -O2 with -g in the CFLAGS and run under gdb.

also, take a look at the porting suggestions at the end of unix/PLATFORMS.

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

attempt to build clisp on mingw without debug with lightning is crash

2008-09-17T02:41:36Z

;; Loading file C:\gnu\home\src\clisp\clisp\src\clos-genfun1.lisp ...
*** - handle_fault error2 ! address = 0x9ef50021 not in
[0x5fde75d8,0x60000000) !
SIGSEGV cannot be cured. Fault address = 0x9ef50021.
GC count: 51
Space collected by GC: 0 23993120
Run time: 0 66718750
Real time: 0 72656250
GC time: 0 3593750
Permanently allocated: 90304 bytes.
Currently in use: 3158036 bytes.
Free space: 752430 bytes.
make: *** [interpreted.mem] Error 5

with debug - all ok.

Any suggestions - how debug it?

--
WBR, Yaroslav Kavenchuk.

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: jit_allocai instruction macro

2008-07-09T02:32:37Z

Hello,

PieSquared <piesquared@...> writes:

> The GNU Lightning manual (here:
> http://www.gnu.org/software/lightning/manual/lightning.html) mentions and
> uses the jit_allocai instruction macro, for example in the reverse polish
> notation calculator. However, I cannot seem to find that anywhere...

Make sure you use the latest version of lightning, which must be 1.2c
(1.2c does include it for sure).

> Instead, I see uses of jit_push... and jit_pop..., which aren't really
> documented anywhere, it seems. In a previous mailing list post, it is
> suggested that you use JIT_SP (and subtract from it) in order to achieve
> similar functionality. Am I missing something, or using an out-dated
> version of lightning? Or of it's manual?

Use of `jit_{push,pop} ()' is discouraged because that can't work
portably on all arches, most notably on SPARC (see [0,1] for details).
Likewise, fiddling with `JIT_SP' is not a good idea. So `jit_allocai'
is the recommended way to allocate room on the stack.

Thanks,
Ludovic.

[0] http://lists.gnu.org/archive/html/lightning/2006-10/msg00046.html
[1] http://lists.gnu.org/archive/html/lightning/2006-10/msg00047.html

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

jit_allocai instruction macro

2008-07-03T00:18:01Z

The GNU Lightning manual (here: http://www.gnu.org/software/lightning/manual/lightning.html) mentions and uses the jit_allocai instruction macro, for example in the reverse polish notation calculator. However, I cannot seem to find that anywhere... Instead, I see uses of jit_push... and jit_pop..., which aren't really documented anywhere, it seems. In a previous mailing list post, it is suggested that you use JIT_SP (and subtract from it) in order to achieve similar functionality. Am I missing something, or using an out-dated version of lightning? Or of it's manual?

Thanks.

PS. Here is where I downloaded lightning from: http://ftp.gnu.org/gnu/lightning/ (the previous to last link)

--
~Andrew Gibiansky
_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Patch for PPC-32

2008-07-02T07:28:02Z

Good morning Paolo,

I attach below a patch containing two bug fixes for PPC.

1) The first is related to a compilation problem with a recent gcc version. Fixed by simply adding more casting.

2) The macros for push/pop on PPC were using incorrect offsets.

PS/The x86_64 works great for me now! With the patches sent in the past weeks, everything works!

Laurent

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

patch-ppc32 (2K) Download Attachment
smime.p7s (5K) Download Attachment

Fwd: [patch/rfa]: Add _setjmp/_longjmp macros

2008-06-22T01:21:48Z

This recent cygwin change will clarify recent discussion.

---------- Forwarded message ----------
From: Corinna Vinschen <vinschen@...>
Date: 2008/6/21
Subject: Re: [patch/rfa]: Add _setjmp/_longjmp macros
To: newlib@...

On Jan 13 17:32, Corinna Vinschen wrote:

> Hi,
>
> SUSv3 defines a _setjmp/_longjmp pair of functions, which are equivalent
> to setjmp/longjmp, except that they shall never manipulate the signal
> mask:
>
> http://www.opengroup.org/onlinepubs/009695399/functions/_setjmp.html
>
> The below patch adds _setjmp and _longjmp as macros calling
> sigsetjmp/siglongjmp.

I applied the below additional patch as obvious. It defines both
interfaces as functions when building for Cygwin.

Corinna

* libc/include/machine/setjmp.h (_longjmp): Define as function on
Cygwin.
(_setjmp): Ditto.

Index: libc/include/machine/setjmp.h
===================================================================
RCS file: /cvs/src/src/newlib/libc/include/machine/setjmp.h,v
retrieving revision 1.35
diff -u -p -r1.35 setjmp.h
--- libc/include/machine/setjmp.h 15 Jan 2008 09:41:06 -0000 1.35
+++ libc/include/machine/setjmp.h 21 Jun 2008 18:45:53 -0000
@@ -307,11 +307,16 @@ typedef int sigjmp_buf[_JBLEN+2];

#endif

-/* POSIX _setjmp/_longjmp macros, maintained for XSI compatibility. These
+/* POSIX _setjmp/_longjmp, maintained for XSI compatibility. These
are equivalent to sigsetjmp/siglongjmp when not saving the signal mask.
New applications should use sigsetjmp/siglongjmp instead. */
+#ifdef __CYGWIN__
+extern void _longjmp(jmp_buf, int);
+extern int _setjmp(jmp_buf);
+#else
#define _setjmp(env) sigsetjmp ((env), 0)
#define _longjmp(env, val) siglongjmp ((env), (val))
+#endif

#ifdef __cplusplus
}

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

--
Reini Urban
http://phpwiki.org/ http://murbreak.at/

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: Re: Still problems.

2008-06-17T06:50:57Z

You're the King ;-)

Thanks!

---
Laurent

On Jun 17, 2008, at 9:25 AM, Paolo Bonzini wrote:

>
>> Here is the relevant macro. Both references to RD use the same
>> masking
>> #define IMULQir(IM, RD) (_REXQrr(0, RD), _Os_Mrm_sL
>> (0x69 ,_b11,_r8(RD),_r8(RD) ,IM ))
>
> As Murphy's law goes, the only wrong ones were IMULQir and IMULQirr--
> checked against as+objdump with the following assembly source code
> (stuff after # is a comment):
>
> movq %r10, %rdx #define MOVQrr(RS, RD) (_REXQrr(RS, RD)
> testq %r10, %rdx #define TESTQrr(RS, RD) (_REXQrr(RS, RD)
> cmpxchgq %r10, %rdx #define CMPXCHGQrr(RS, RD) (_REXQrr(RS, RD)
> xaddq %r10, %rdx #define XADDQrr(RS, RD) (_REXQrr(RS, RD)
> xchgq %r10, %rdx #define XCHGQrr(RS, RD) (_REXQrr(RS, RD)
>
> imulq %r10, %rdx #define IMULQrr(RS, RD) (_REXQrr(RD, RS)
> imulq $10, %r10, %rdx #define IMULQirr(IM,RS,RD) (_REXQrr(RS, RD)
> <<< WRONG!
> cmovbq %r10, %rdx #define CMOVQrr(CC,RS,RD) (_REXQrr(RD, RS)
> bsfq %r10, %rdx #define BSFQrr(RS, RD) (_REXQrr(RD, RS)
> bsrq %r10, %rdx #define BSRQrr(RS, RD) (_REXQrr(RD, RS)
> movsbq %r10b, %rdx #define MOVSBQrr(RS, RD) (_REXQrr(RD, RS)
> movzbq %r10b, %rdx #define MOVZBQrr(RS, RD) (_REXQrr(RD, RS)
> movswq %r10w, %rdx #define MOVSWQrr(RS, RD) (_REXQrr(RD, RS)
> movzwq %r10w, %rdx #define MOVZWQrr(RS, RD) (_REXQrr(RD, RS)
> movslq %r10d, %rdx #define MOVSLQrr(RS, RD)
> _m64only((_REXQrr(RD, RS)
>
> Fix committed & pushed.
>
> Paolo
>
>
> _______________________________________________
> Lightning mailing list
> Lightning@...
> http://lists.gnu.org/mailman/listinfo/lightning

--
Laurent

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

smime.p7s (6K) Download Attachment

Re: Still problems.

2008-06-17T06:25:31Z

> Here is the relevant macro. Both references to RD use the same masking
>
> #define IMULQir(IM, RD) (_REXQrr(0, RD), _Os_Mrm_sL (0x69
> ,_b11,_r8(RD),_r8(RD) ,IM ))

As Murphy's law goes, the only wrong ones were IMULQir and
IMULQirr--checked against as+objdump with the following assembly source
code (stuff after # is a comment):

movq %r10, %rdx #define MOVQrr(RS, RD)
(_REXQrr(RS, RD)
testq %r10, %rdx #define TESTQrr(RS, RD)
(_REXQrr(RS, RD)
cmpxchgq %r10, %rdx #define CMPXCHGQrr(RS, RD)
(_REXQrr(RS, RD)
xaddq %r10, %rdx #define XADDQrr(RS, RD)
(_REXQrr(RS, RD)
xchgq %r10, %rdx #define XCHGQrr(RS, RD)
(_REXQrr(RS, RD)

imulq %r10, %rdx #define IMULQrr(RS, RD)
(_REXQrr(RD, RS)
imulq $10, %r10, %rdx #define IMULQirr(IM,RS,RD)
(_REXQrr(RS, RD) <<< WRONG!
cmovbq %r10, %rdx #define CMOVQrr(CC,RS,RD)
(_REXQrr(RD, RS)
bsfq %r10, %rdx #define BSFQrr(RS, RD)
(_REXQrr(RD, RS)
bsrq %r10, %rdx #define BSRQrr(RS, RD)
(_REXQrr(RD, RS)
movsbq %r10b, %rdx #define MOVSBQrr(RS, RD)
(_REXQrr(RD, RS)
movzbq %r10b, %rdx #define MOVZBQrr(RS, RD)
(_REXQrr(RD, RS)
movswq %r10w, %rdx #define MOVSWQrr(RS, RD)
(_REXQrr(RD, RS)
movzwq %r10w, %rdx #define MOVZWQrr(RS, RD)
(_REXQrr(RD, RS)
movslq %r10d, %rdx #define MOVSLQrr(RS, RD)
_m64only((_REXQrr(RD, RS)

Fix committed & pushed.

Paolo

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: Still problems.

2008-06-17T06:05:22Z

> Here is the relevant macro. Both references to RD use the same masking
>
> #define IMULQir(IM, RD) (_REXQrr(0, RD), _Os_Mrm_sL (0x69
> ,_b11,_r8(RD),_r8(RD) ,IM ))

Even better, as the disassembly suggests:

#define IMULQir(IM, RD) IMULQir(IM, (RD), (RD))

There seem to be other problems in the encoding of the REX bits though.

Paolo

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: Still problems.

2008-06-17T05:59:32Z

> #define IMULQir(IM, RD) (_REXQrr(0, RD), _Os_Mrm_sL (0x69
> ,_b11,_r8(RD),_r8(RD) ,IM ))

I tried assembling two instructions and got;

0: 4d 6b d2 0a imul $0xa,%r10,%r10
4: 49 6b d2 0a imul $0xa,%r10,%rdx

I think the _REXQrr arguments should be "RD, RD".

Paolo

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

Re: Still problems.

2008-06-17T05:52:31Z

I tried the patch. The call goes through, but I'm afraid something else is interfering. The code fragment:

_code->getarg_p(CJIT_V0, ofs4);

_code->ldxi_l(CJIT_R0,CJIT_V2,LocRuntime::offsetOfST());

_code->ldxi_l(CJIT_R1,CJIT_R0,LocRTStackI::offsetOfMX());

_code->ldxi_l(CJIT_R2,CJIT_R0,LocRTStackI::offsetOfST());

_code->muli_l(CJIT_R1,CJIT_R1,sizeof(ColSlotI));

Now generates:

0x1000300002: mov %rcx,%rbx

0x1000300005: mov 0x48(%r13),%rax

0x1000300009: mov 0x8(%rax),%r10

0x100030000d: mov 0x10(%rax),%r11

0x1000300011: imul $0x10,%r10,%rdx

The last instruction is of interest. It should be R1 <- R1 * $0x10. Now it somehow gets translated into a write into RDX rather than into R10. I checked the macro in core-64.h

#define jit_muli_l(d, rs, is) jit_op_ ((d), (rs), IMULQir((is), (d)) )

and it looks fine.

The jit_op_ looks fine too:

/* 3-parameter operation, with immediate */

#define jit_op_(d, s1, op2d) \

((s1 == d) ? op2d : (MOVLrr(s1, d), op2d))

I double checked and the first arguments to the macro are indeed equal and equal to 0x4A (R10).

Here is the relevant macro. Both references to RD use the same masking

#define IMULQir(IM, RD) (_REXQrr(0, RD), _Os_Mrm_sL (0x69 ,_b11,_r8(RD),_r8(RD) ,IM ))

The _r8(RD) macro tests RD to decide how to mask it and it appears that it elects to use _r4(RD) for its encoding. Which produces:

(gdb) p /t CJIT_R1 & 0x07

$19 = 10

I checked how RDX would be masked and of course I get:

(gdb) p /t 0x52 & 0x07

$20 = 10

So it would sound like R10 is not really a GPR. It cannot appear anywhere ? Either that is the case, or the instruction should use _r4 to encode the destination register. I'll try to get the intel spec to check, but I thought I'd report now anyhow.

On Jun 17, 2008, at 3:34 AM, Paolo Bonzini wrote:

3) modified jit_shift_args to use nbargs instead.
#define jit_shift_args() \
  ((_jitl.nbargs >= 3 ? (void) (MOVQrr(_R10D, _RDX)) : (void) 0), \
   (_jitl.nbargs >= 4 ? (void) (MOVQrr(_R11D, _RCX)) : (void) 0))
With this change, it moves the values as expected.

It turns out that with JIT_Rx mapped to RAX/R10/R11 there is no need for jit_shift_args anymore. That's good!

I attach the patch I committed so that you can see what's going on.

Paolo
diff --git a/ChangeLog b/ChangeLog
index 1e05fe1..0d0f86a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2008-06-16 Paolo Bonzini <bonzini@...>
+
+ * lightning/i386/core.h: Use jit_save in jit_replace. Move JIT_R
+ definition...
+ * lightning/i386/core-32.h: ... here; define jit_save so that
+ the core.h has no effect on the 32-bit backend.
+ * lightning/i386/core-64.h: Place JIT_R1/JIT_R2 in R10/R11,
+ place outgoing arguments in the right spot from the beginning,
+ define jit_save, fix jit_reg8/jit_reg16.
+
2008-06-15 Paolo Bonzini <bonzini@...>

        * lightning/i386/core-64.h: Rewrite argument passing to
diff --git a/lightning/i386/core-32.h b/lightning/i386/core-32.h
index 9775fc8..46b3516 100644
--- a/lightning/i386/core-32.h
+++ b/lightning/i386/core-32.h
@@ -36,6 +36,9 @@

#define JIT_CAN_16 1
#define JIT_AP _EBP
+
+#define JIT_R_NUM 3
+#define JIT_R(i) (_EAX + (i))
#define JIT_V_NUM 3
#define JIT_V(i) ((i) == 0 ? _EBX : _ESI + (i) - 1)

@@ -46,6 +49,9 @@ struct jit_local_state {
  int alloca_slack;
};

+/* Whether a register is used for the user-accessible registers. */
+#define jit_save(reg) 1
+
#define jit_base_prolog() (_jitl.framesize = 20, _jitl.alloca_offset = 0, \
  PUSHLr(_EBX), PUSHLr(_ESI), PUSHLr(_EDI), PUSHLr(_EBP), MOVLrr(_ESP, _EBP))
#define jit_base_ret(ofs) \
diff --git a/lightning/i386/core-64.h b/lightning/i386/core-64.h
index 173a229..5da7535 100644
--- a/lightning/i386/core-64.h
+++ b/lightning/i386/core-64.h
@@ -38,6 +38,8 @@
#define JIT_CAN_16 0
#define JIT_REXTMP _R9D

+#define JIT_R_NUM 3
+#define JIT_R(i)                ((i) == 0 ? _EAX : _R9D + (i))
#define JIT_V_NUM               3
#define JIT_V(i)                ((i) == 0 ? _EBX : _R11D + (i))

@@ -51,6 +53,9 @@ struct jit_local_state {
  int   alloca_slack;
};

+/* Whether a register in the "low" bank is used for the user-accessible
+   registers. */
+#define jit_save(reg) ((reg) == _EAX || (reg) == _EBX)

/* Keep the stack 16-byte aligned, the SSE hardware prefers it this way. */
#define jit_allocai_internal(amount, slack)                           \
@@ -128,19 +133,13 @@ struct jit_local_state {
/* Stack isn't used for arguments: */
#define jit_prepare_i(ni) (_jitl.argssize = (ni))

-#define jit_pusharg_i(rs) (--_jitl.argssize, MOVQrr(rs, jit_arg_reg_temp[_jitl.argssize]))
-#define jit_finish(sub)         (jit_shift_args(), \
- MOVQir((long) (sub), JIT_REXTMP), \
+#define jit_pusharg_i(rs) (--_jitl.argssize, MOVQrr(rs, jit_arg_reg_order[_jitl.argssize]))
+#define jit_finish(sub)         (MOVQir((long) (sub), JIT_REXTMP), \
CALLsr(JIT_REXTMP))
#define jit_reg_is_arg(reg)     ((reg) == _ECX || (reg) == _EDX)
#define jit_finishr(reg) ((jit_reg_is_arg((reg)) ? MOVQrr(reg, JIT_REXTMP) : (void)0), \
-                                 jit_shift_args(), \
                                 CALLsr(jit_reg_is_arg((reg)) ? JIT_REXTMP : (reg)))

-#define jit_shift_args() \
-   ((_jitl.argssize >= 3 ? (void) (MOVQrr(_R10D, _RDX)) : (void) 0), \
-    (_jitl.argssize >= 4 ? (void) (MOVQrr(_R11D, _RCX)) : (void) 0))
-
#define jit_retval_l(rd) ((void)jit_movr_l ((rd), _EAX))
#define jit_arg_c()        (jit_arg_reg_order[_jitl.nextarg_geti++])
#define jit_arg_uc()        (jit_arg_reg_order[_jitl.nextarg_geti++])
@@ -152,7 +151,6 @@ struct jit_local_state {
#define jit_arg_ul()        (jit_arg_reg_order[_jitl.nextarg_geti++])
#define jit_arg_p()        (jit_arg_reg_order[_jitl.nextarg_geti++])

-static int jit_arg_reg_temp[] = { _EDI, _ESI, _R10D, _R11D, _R8D, _R9D };
static int jit_arg_reg_order[] = { _EDI, _ESI, _EDX, _ECX, _R8D, _R9D };

#define jit_negr_l(d, rs) jit_opi_((d), (rs), NEGQr(d), (XORQrr((d), (d)), SUBQrr((rs), (d))) )
@@ -185,8 +183,8 @@ static int jit_arg_reg_order[] = { _EDI, _ESI, _EDX, _ECX, _R8D, _R9D };

/* Used to implement ldc, stc, ... We have SIL and friends which simplify it all. */
#define jit_check8(rs)          1
-#define jit_reg8(rs)            (_rN(rs) | _AL )
-#define jit_reg16(rs)           (_rN(rs) | _AX )
+#define jit_reg8(rs)            (_rR(rs) | _AL )
+#define jit_reg16(rs)           (_rR(rs) | _AX )
#define jit_movbrm(rs, dd, db, di, ds)         MOVBrm(jit_reg8(rs), dd, db, di, ds)

#define jit_ldi_c(d, is)                (_u32P((long)(is)) ? MOVSBLmr((is), 0,    0,    0, (d)) : (jit_movi_l(JIT_REXTMP, is), jit_ldr_c(d, JIT_REXTMP)))
diff --git a/lightning/i386/core.h b/lightning/i386/core.h
index ad99d4d..64f8e80 100644
--- a/lightning/i386/core.h
+++ b/lightning/i386/core.h
@@ -38,9 +38,6 @@
#define JIT_SP _ESP
#define JIT_RET _EAX

-#define JIT_R_NUM 3
-#define JIT_R(i) (_EAX + (i))
-

/* 3-parameter operation */
#define jit_opr_(d, s1, s2, op1d, op2d) \
@@ -64,7 +61,11 @@
/* An operand is forced into a register */
#define jit_replace(rd, rs, forced, op) \
((rd == forced) ? JITSORRY("Register conflict for " # op) : \
- (rs == forced) ? op : (jit_pushr_i(forced), MOVLrr(rs, forced), op, jit_popr_i(forced)))
+ (rs == forced) ? op : \
+ jit_save (forced) \
+ ? (jit_pushr_i(forced), jit_movr_l(rs, forced), op, \
+     jit_popr_i(forced)) \
+ : (jit_movr_l(rs, forced), op))

/* For LT, LE, ... */
#define jit_replace8(d, cmp, op) \

Laurent

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

smime.p7s (5K) Download Attachment

Re: Still problems.

2008-06-17T04:14:08Z

On Jun 17, 2008, at 3:34 AM, Paolo Bonzini wrote:

3) modified jit_shift_args to use nbargs instead.
#define jit_shift_args() \
((_jitl.nbargs >= 3 ? (void) (MOVQrr(_R10D, _RDX)) : (void) 0), \
(_jitl.nbargs >= 4 ? (void) (MOVQrr(_R11D, _RCX)) : (void) 0))
With this change, it moves the values as expected.

It turns out that with JIT_Rx mapped to RAX/R10/R11 there is no need for jit_shift_args anymore. That's good!

Wonderful. I'll update. Looks like the other small patch is no longer necessary since there is no shifting ;-) Good all around!

I attach the patch I committed so that you can see what's going on.

Paolo
diff --git a/ChangeLog b/ChangeLog
index 1e05fe1..0d0f86a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2008-06-16 Paolo Bonzini <bonzini@...>
+
+ * lightning/i386/core.h: Use jit_save in jit_replace. Move JIT_R
+ definition...
+ * lightning/i386/core-32.h: ... here; define jit_save so that
+ the core.h has no effect on the 32-bit backend.
+ * lightning/i386/core-64.h: Place JIT_R1/JIT_R2 in R10/R11,
+ place outgoing arguments in the right spot from the beginning,
+ define jit_save, fix jit_reg8/jit_reg16.
+
2008-06-15 Paolo Bonzini <bonzini@...>

        * lightning/i386/core-64.h: Rewrite argument passing to
diff --git a/lightning/i386/core-32.h b/lightning/i386/core-32.h
index 9775fc8..46b3516 100644
--- a/lightning/i386/core-32.h
+++ b/lightning/i386/core-32.h
@@ -36,6 +36,9 @@

#define JIT_CAN_16 1
#define JIT_AP _EBP
+
+#define JIT_R_NUM 3
+#define JIT_R(i) (_EAX + (i))
#define JIT_V_NUM 3
#define JIT_V(i) ((i) == 0 ? _EBX : _ESI + (i) - 1)

@@ -46,6 +49,9 @@ struct jit_local_state {
  int alloca_slack;
};

+/* Whether a register is used for the user-accessible registers. */
+#define jit_save(reg) 1
+
#define jit_base_prolog() (_jitl.framesize = 20, _jitl.alloca_offset = 0, \
  PUSHLr(_EBX), PUSHLr(_ESI), PUSHLr(_EDI), PUSHLr(_EBP), MOVLrr(_ESP, _EBP))
#define jit_base_ret(ofs) \
diff --git a/lightning/i386/core-64.h b/lightning/i386/core-64.h
index 173a229..5da7535 100644
--- a/lightning/i386/core-64.h
+++ b/lightning/i386/core-64.h
@@ -38,6 +38,8 @@
#define JIT_CAN_16 0
#define JIT_REXTMP _R9D

+#define JIT_R_NUM 3
+#define JIT_R(i)                ((i) == 0 ? _EAX : _R9D + (i))
#define JIT_V_NUM               3
#define JIT_V(i)                ((i) == 0 ? _EBX : _R11D + (i))

@@ -51,6 +53,9 @@ struct jit_local_state {
  int   alloca_slack;
};

+/* Whether a register in the "low" bank is used for the user-accessible
+   registers. */
+#define jit_save(reg) ((reg) == _EAX || (reg) == _EBX)

/* Keep the stack 16-byte aligned, the SSE hardware prefers it this way. */
#define jit_allocai_internal(amount, slack)                           \
@@ -128,19 +133,13 @@ struct jit_local_state {
/* Stack isn't used for arguments: */
#define jit_prepare_i(ni) (_jitl.argssize = (ni))

-#define jit_pusharg_i(rs) (--_jitl.argssize, MOVQrr(rs, jit_arg_reg_temp[_jitl.argssize]))
-#define jit_finish(sub)         (jit_shift_args(), \
- MOVQir((long) (sub), JIT_REXTMP), \
+#define jit_pusharg_i(rs) (--_jitl.argssize, MOVQrr(rs, jit_arg_reg_order[_jitl.argssize]))
+#define jit_finish(sub)         (MOVQir((long) (sub), JIT_REXTMP), \
CALLsr(JIT_REXTMP))
#define jit_reg_is_arg(reg)     ((reg) == _ECX || (reg) == _EDX)
#define jit_finishr(reg) ((jit_reg_is_arg((reg)) ? MOVQrr(reg, JIT_REXTMP) : (void)0), \
-                                 jit_shift_args(), \
                                 CALLsr(jit_reg_is_arg((reg)) ? JIT_REXTMP : (reg)))

-#define jit_shift_args() \
-   ((_jitl.argssize >= 3 ? (void) (MOVQrr(_R10D, _RDX)) : (void) 0), \
-    (_jitl.argssize >= 4 ? (void) (MOVQrr(_R11D, _RCX)) : (void) 0))
-
#define jit_retval_l(rd) ((void)jit_movr_l ((rd), _EAX))
#define jit_arg_c()        (jit_arg_reg_order[_jitl.nextarg_geti++])
#define jit_arg_uc()        (jit_arg_reg_order[_jitl.nextarg_geti++])
@@ -152,7 +151,6 @@ struct jit_local_state {
#define jit_arg_ul()        (jit_arg_reg_order[_jitl.nextarg_geti++])
#define jit_arg_p()        (jit_arg_reg_order[_jitl.nextarg_geti++])

-static int jit_arg_reg_temp[] = { _EDI, _ESI, _R10D, _R11D, _R8D, _R9D };
static int jit_arg_reg_order[] = { _EDI, _ESI, _EDX, _ECX, _R8D, _R9D };

#define jit_negr_l(d, rs) jit_opi_((d), (rs), NEGQr(d), (XORQrr((d), (d)), SUBQrr((rs), (d))) )
@@ -185,8 +183,8 @@ static int jit_arg_reg_order[] = { _EDI, _ESI, _EDX, _ECX, _R8D, _R9D };

/* Used to implement ldc, stc, ... We have SIL and friends which simplify it all. */
#define jit_check8(rs)          1
-#define jit_reg8(rs)            (_rN(rs) | _AL )
-#define jit_reg16(rs)           (_rN(rs) | _AX )
+#define jit_reg8(rs)            (_rR(rs) | _AL )
+#define jit_reg16(rs)           (_rR(rs) | _AX )
#define jit_movbrm(rs, dd, db, di, ds)         MOVBrm(jit_reg8(rs), dd, db, di, ds)

#define jit_ldi_c(d, is)                (_u32P((long)(is)) ? MOVSBLmr((is), 0,    0,    0, (d)) : (jit_movi_l(JIT_REXTMP, is), jit_ldr_c(d, JIT_REXTMP)))
diff --git a/lightning/i386/core.h b/lightning/i386/core.h
index ad99d4d..64f8e80 100644
--- a/lightning/i386/core.h
+++ b/lightning/i386/core.h
@@ -38,9 +38,6 @@
#define JIT_SP _ESP
#define JIT_RET _EAX

-#define JIT_R_NUM 3
-#define JIT_R(i) (_EAX + (i))
-

/* 3-parameter operation */
#define jit_opr_(d, s1, s2, op1d, op2d) \
@@ -64,7 +61,11 @@
/* An operand is forced into a register */
#define jit_replace(rd, rs, forced, op) \
((rd == forced) ? JITSORRY("Register conflict for " # op) : \
- (rs == forced) ? op : (jit_pushr_i(forced), MOVLrr(rs, forced), op, jit_popr_i(forced)))
+ (rs == forced) ? op : \
+ jit_save (forced) \
+ ? (jit_pushr_i(forced), jit_movr_l(rs, forced), op, \
+     jit_popr_i(forced)) \
+ : (jit_movr_l(rs, forced), op))

/* For LT, LE, ... */
#define jit_replace8(d, cmp, op) \

Laurent

_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

smime.p7s (5K) Download Attachment