[kaffe] AWT problem
Hello all, I'm having a problem with a small awt proram I'm wri ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] AWT problem
--- Justin Dearing [EMAIL PROTECTED] wrote: Hello all, I'm having a problem with a small awt proram I'm wri You may have a problem with your internet connection as well ;) please repost your bug report. cheers, dalibor topic __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: AWT problem
Hi Dalibor, On 10-Mar-03, you wrote: --- Justin Dearing [EMAIL PROTECTED] wrote: Hello all, I'm having a problem with a small awt proram I'm wri You may have a problem with your internet connection as well ;) Ah, that's a relief. I thought there must be a large fly sitting on my glasses. tony ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] JIT3 Questions
I've been looking at the problem with JIT3 on MIPS platforms,
and have come across something distinctly suspicious that I know
how to fix in the abstract. I could use some guidance from other
more experienced JIT hands as to how to best deal with it in practice.
In the generated function prologue in config/mips/jit3-mips.def,
we have...
=== Begin Source Fragment
define_insn(prologue, prologue_xxC) {
label* l;
Method* meth;
int limit;
int haveint;
int j;
int i;
int fi;
int a;
/* Max_args is the maximum number of arguments this method pushed
* onto the stack (allowing for alignment). We always allow for
* the 4 argument registers.
*/
max_args = NR_ARGUMENTS;
debug_name((prologue:\n));
/* Save and move sp, fp r31 */
insn_RRR(_ADDU, REG_i1, REG_fp, REG_i0);
insn_RRR(_ADDU, REG_fp, REG_sp, REG_i0);
/* Remember where the framesize should go */
l = (label*)const_int(1);
l-type = Lframe|Labsolute|Lgeneral;
l-at = (uintp)CODEPC;
insn_RRC(_ADDIU, REG_sp, REG_sp, 0); /* framesize */
ldst_RRC(_SW, REG_ra, REG_fp, -4); /* save $ra */
ldst_RRC(_SW, REG_i1, REG_fp, -8); /* save old $fp */
ldst_RRC(_SW, REG_gp, REG_fp, -12); /* save $gp */
debug((mov i1,fp\n));
debug((mov fp,sp\n));
debug((addiu sp,sp,-framesize\n));
debug((sw ra,-4(fp)\n));
debug((sw i1,-8(fp)\n));
debug((sw gp,-12(fp)\n));
#if defined(USE_JIT_CONSTANT_POOL)
/* Get pointer to constant pool */
insn_RRR(_ADDU, CONSTPOOL_BASE, REG_i25, REG_i0);
ldst_RRC(_SW, REG_gp, REG_fp, -16);
debug((movegp,i25\n));
debug((sw gp,-16(fp)\n));
#endif
/* Save callee save regs */
for (i = 0; i 8; i++) {
ldst_RRC(_SW, REG_s0+i, REG_fp, -SLOTSIZE*(5+i));
debug((sw
%s,%d(fp)\n,regname(REG_s0+i),-SLOTSIZE*(4+i)));
}
== End Source Fragment ===
Now, as it happens, the offset generated to save register $16, i=0 in the for
loop above, ends up being -16. Which is to say, if USE_JIT_CONSTANT_POOL
is defined (which it is by default), the same storage location in the frame is used
for
both $16 and $25. Unfortunately, if I undefine USE_JIT_CONSTANT_POOL
in jit.h, where it is defined, the resulting JIT doesn't work. In the abstract, it
should
be a simple problem of upping the frame size by 8 bytes (8 not 4, to preserve
alignment),
and using a new offset for $25. However, in the code above, the frame size seems
to be generated automagically to replace a zero constant in the instruction generation
macro with some method-dependent frame size that I speculate somehow already
allows for some number of saved registers in the frame. Where is this defined?
Are the offsets into the frame for the con
Is the relationship between the saved register context and other values on the
frame fixed, such that I cannot insert a new storage element between them?
I've been trying to code something really sneaky to save/restore the register
behind the back of the rest of the frame management code in a sort of
sub-frame, but the first cut at that doesn't work, and frankly, it's not what
I would consider to be wholesome coding. How can I adjust the total frame
size to add a new element?
Kevin K.
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] JIT3 Questions
Never mind. It looks as if there was a bug in the JIT diagnostic trace
that isn't in the generated code itself. Note:
/* Save callee save regs */
for (i = 0; i 8; i++) {
ldst_RRC(_SW, REG_s0+i, REG_fp, -SLOTSIZE*(5+i));
debug((sw
%s,%d(fp)\n,regname(REG_s0+i),-SLOTSIZE*(4+i)));
}
SLOTSIZE*(4+i) is being reported as the frame offset used, but it's the
(arguably more correct) value of SLOTSIZE*(5+i) that was being used.
Kevin K.
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] JIT3 Questions
I've been looking at the problem with JIT3 on MIPS platforms,
and have come across something distinctly suspicious that I know
how to fix in the abstract. I could use some guidance from other
more experienced JIT hands as to how to best deal with it in practice.
In the generated function prologue in config/mips/jit3-mips.def,
we have...
=== Begin Source Fragment
define_insn(prologue, prologue_xxC) {
label* l;
Method* meth;
int limit;
int haveint;
int j;
int i;
int fi;
int a;
/* Max_args is the maximum number of arguments this method pushed
* onto the stack (allowing for alignment). We always allow for
* the 4 argument registers.
*/
max_args = NR_ARGUMENTS;
debug_name((prologue:\n));
/* Save and move sp, fp r31 */
insn_RRR(_ADDU, REG_i1, REG_fp, REG_i0);
insn_RRR(_ADDU, REG_fp, REG_sp, REG_i0);
/* Remember where the framesize should go */
l = (label*)const_int(1);
l-type = Lframe|Labsolute|Lgeneral;
l-at = (uintp)CODEPC;
insn_RRC(_ADDIU, REG_sp, REG_sp, 0); /* framesize */
ldst_RRC(_SW, REG_ra, REG_fp, -4); /* save $ra */
ldst_RRC(_SW, REG_i1, REG_fp, -8); /* save old $fp */
ldst_RRC(_SW, REG_gp, REG_fp, -12); /* save $gp */
debug((mov i1,fp\n));
debug((mov fp,sp\n));
debug((addiu sp,sp,-framesize\n));
debug((sw ra,-4(fp)\n));
debug((sw i1,-8(fp)\n));
debug((sw gp,-12(fp)\n));
#if defined(USE_JIT_CONSTANT_POOL)
/* Get pointer to constant pool */
insn_RRR(_ADDU, CONSTPOOL_BASE, REG_i25, REG_i0);
ldst_RRC(_SW, REG_gp, REG_fp, -16);
debug((movegp,i25\n));
debug((sw gp,-16(fp)\n));
#endif
/* Save callee save regs */
for (i = 0; i 8; i++) {
ldst_RRC(_SW, REG_s0+i, REG_fp, -SLOTSIZE*(5+i));
debug((sw
%s,%d(fp)\n,regname(REG_s0+i),-SLOTSIZE*(4+i)));
}
== End Source Fragment ===
Now, as it happens, the offset generated to save register $16, i=0 in the for
loop above, ends up being -16. Which is to say, if USE_JIT_CONSTANT_POOL
is defined (which it is by default), the same storage location in the frame is used
for
both $16 and $25. Unfortunately, if I undefine USE_JIT_CONSTANT_POOL
in jit.h, where it is defined, the resulting JIT doesn't work. In the abstract, it
should
be a simple problem of upping the frame size by 8 bytes (8 not 4, to preserve
alignment),
and using a new offset for $25. However, in the code above, the frame size seems
to be generated automagically to replace a zero constant in the instruction
generation
macro with some method-dependent frame size that I speculate somehow already
allows for some number of saved registers in the frame. Where is this defined?
Are the offsets into the frame for the con
Is the relationship between the saved register context and other values on the
frame fixed, such that I cannot insert a new storage element between them?
I've been trying to code something really sneaky to save/restore the register
behind the back of the rest of the frame management code in a sort of
sub-frame, but the first cut at that doesn't work, and frankly, it's not what
I would consider to be wholesome coding. How can I adjust the total frame
size to add a new element?
Kevin K.
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] JIT3 Questions
ops, sorry about the previous email
I've been looking at the problem with JIT3 on MIPS platforms,
and have come across something distinctly suspicious that I know
how to fix in the abstract. I could use some guidance from other
more experienced JIT hands as to how to best deal with it in practice.
In the generated function prologue in config/mips/jit3-mips.def,
we have...
=== Begin Source Fragment
define_insn(prologue, prologue_xxC) {
label* l;
Method* meth;
int limit;
int haveint;
int j;
int i;
int fi;
int a;
/* Max_args is the maximum number of arguments this method pushed
* onto the stack (allowing for alignment). We always allow for
* the 4 argument registers.
*/
max_args = NR_ARGUMENTS;
debug_name((prologue:\n));
/* Save and move sp, fp r31 */
insn_RRR(_ADDU, REG_i1, REG_fp, REG_i0);
insn_RRR(_ADDU, REG_fp, REG_sp, REG_i0);
/* Remember where the framesize should go */
l = (label*)const_int(1);
l-type = Lframe|Labsolute|Lgeneral;
l-at = (uintp)CODEPC;
insn_RRC(_ADDIU, REG_sp, REG_sp, 0); /* framesize */
ldst_RRC(_SW, REG_ra, REG_fp, -4); /* save $ra */
ldst_RRC(_SW, REG_i1, REG_fp, -8); /* save old $fp */
ldst_RRC(_SW, REG_gp, REG_fp, -12); /* save $gp */
debug((mov i1,fp\n));
debug((mov fp,sp\n));
debug((addiu sp,sp,-framesize\n));
debug((sw ra,-4(fp)\n));
debug((sw i1,-8(fp)\n));
debug((sw gp,-12(fp)\n));
#if defined(USE_JIT_CONSTANT_POOL)
/* Get pointer to constant pool */
insn_RRR(_ADDU, CONSTPOOL_BASE, REG_i25, REG_i0);
ldst_RRC(_SW, REG_gp, REG_fp, -16);
debug((movegp,i25\n));
debug((sw gp,-16(fp)\n));
#endif
/* Save callee save regs */
for (i = 0; i 8; i++) {
ldst_RRC(_SW, REG_s0+i, REG_fp, -SLOTSIZE*(5+i));
debug((sw
%s,%d(fp)\n,regname(REG_s0+i),-SLOTSIZE*(4+i)));
}
== End Source Fragment ===
Now, as it happens, the offset generated to save register $16, i=0 in the for
loop above, ends up being -16. Which is to say, if USE_JIT_CONSTANT_POOL
is defined (which it is by default), the same storage location in the frame is used
for
both $16 and $25. Unfortunately, if I undefine USE_JIT_CONSTANT_POOL
in jit.h, where it is defined, the resulting JIT doesn't work. In the abstract, it
should
be a simple problem of upping the frame size by 8 bytes (8 not 4, to preserve
alignment),
and using a new offset for $25. However, in the code above, the frame size seems
to be generated automagically to replace a zero constant in the instruction
generation
macro with some method-dependent frame size that I speculate somehow already
allows for some number of saved registers in the frame. Where is this defined?
I think the 'label' stuff does what you want. In the mips case the code
that does the replacement is defined in jit.h:
#define LABEL_Lframe(P,V,L) \
{ \
int framesize = FRAMESIZE; \
assert((framesize 0xF000) == 0); \
*(P) = (*(P) 0x) | ((-framesize) 0x); \
}
...
#define EXTRA_LABELS(P,D,L) \
case Lframe:LABEL_Lframe(P,D,L);break; \
...
And the label is setup with this line from the prologue:
/* Remember where the framesize should go */
l = (label*)const_int(1);
l-type = Lframe|Labsolute|Lgeneral;
l-at = (uintp)CODEPC;
Then, when the jitter is doing post processing of the code it will
execute the LABEL_Lframe macro to replace the value at 'l-at'.
Is the relationship between the saved register context and other values on the
frame fixed, such that I cannot insert a new storage element between them?
Not really. You determine the layout of the stack frame so you can do
whatever you want. Its mostly a matter of tweaking the label macros
appropriately.
I've been trying to code something really sneaky to save/restore the register
behind the back of the rest of the frame management code in a sort of
sub-frame, but the first cut at that doesn't work, and frankly, it's not what
I would consider to be wholesome coding.
hmm... Can it not be worked into the existing frame management stuff?
This would benefit other architectures as well.
How can I adjust the total frame size to add a new element?
Just pump the 'framesize' value in the LABEL_Lframe() macro.
Kevin K.
tim
___
kaffe mailing list
[EMAIL PROTECTED]
[kaffe] .properties files with Kaffe
Hello, As I am new with Kaffe, the fhis question may appear to be stupid :) Does anybody knowhow I can use ".properties" files like "javax.comm.properties" with Kaffe ? Thanks by advance. Best regards, Tanguy Monfort.
Re: [kaffe] .properties files with Kaffe
Hi Tanguy, --- Tanguy Monfort [EMAIL PROTECTED] wrote: Does anybody know how I can use .properties files like javax.comm.properties with Kaffe ? I would expect it to work the same like with Sun's impementation: http://javaalmanac.com/egs/java.util/Props.html cheers, dalibor topic __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
