Melvin Smith <[EMAIL PROTECTED]> wrote: > At 11:34 PM 11/22/2003 +0100, Leopold Toetsch wrote:
>>The concept of having INTVAL constants inside the opcodes is >>wrong from a general POV. Please have a look at e.g jit/arm/ what >>immediate constants are requiring as work arounds. > I'm not aware of those problems concerning immediate integers. > Could you describe the issue? I really don't go into the JIT much. The arm architecture can only load 12-bit immediate constants directly. Its a size limit as we have one, when going with 32-bit ops and 64-bit INTVALs. This means, that integer constants bigger then a certain size should better be in the constant table. That's of course suboptimal too, as we would need a lot of ops duplication to handle both integer const formats. > I can't agree that immediate operands are ever "generally wrong" as > there are immediate instructions on most hardware and those > instructions are efficient, since the instruction and operand > are both in the pipeline. > Maybe they don't fit into our JIT design? They don't fit for all architectures and all sizes. JIT design is fine but has to cope with hardware limitations. > Ix regs are for: > 1) Fast integer stuff > 2) Iteration (increment variables) > 3) Conditional checks > 4) Branching and holding addresses > 5) Indexing arrays and strings While the operands clearly are of wordsize (opcode_t) I doubt that it makes sense to say, that arrays or strings can hold max-INTVAL items. > 6) Holding small constant values and flags > All of this works out fine if we use the native size, and none of this > should be penalized (for example if we decided to use "default" 64-bit > INTVAL registers > on a 32-bit CPU, this is penalization -- which I am NOT proposing). The question is: Do we want to support a configuration with 32-bit opcode_t and 64-bit INTVALs? Perl5 has 64-bit IV support, but it doesn't has native data types. Perl6 may have both. The languages, we are running will define, if we need such a configuration. >>How do you communicate the long-long-long intval constants to the PMC? > You can't do that now anyway, but the two options I see are: > (1) use a string or (2) use a multiple register op > or..... (3) Fix Parrot not to assume any integer constant must fit into an > Ix register or single opcode! :) or (4) assign_l Px, Lc # assign long long constant from const_table to PMC. > So, on to a solution: I think, we should first have a decision to above question - the snipped proposal is fine. > -Melvin leo
