# New Ticket Created by Chip Salzenberg # Please include the string: [perl #39695] # in the subject line of all future correspondence about this issue. # <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39695 >
On Mon, Jul 03, 2006 at 03:39:19PM -0500, Vishal Soni wrote: > On Mon, 2006-07-03 at 13:03 -0700, Chip Salzenberg wrote: > > The use of a fixed constant like MAX_REGISTER doesn't really work; Parrot > > has an unbounded (if not infinite :-)) number of registers [...] > > You'll have to use the INTVAL typedef as the data type to hold register > > numbers. > > The function prototype is > void > Parrot_register_move(Interp *interpreter, int n_regs, > unsigned char *dest_regs, unsigned char *src_regs, > unsigned char temp_reg, > reg_move_func mov, > reg_move_func mov_alt, > void *info); > > src_regs and dest_regs are pointers to unsigned char. Unsinged char > being 1 byte will store 256 distinct values. Hence I declared the > MAX_REGISTER to 256. Well look at that. If I'd looked a bit closer at the diffs I might have noticed that myself. That's definitely an RT-able bug. > Let me know what case do we need to code for unbounded number of registers > or 256 registers for now. The former, please. I'd consider it the beginning of fixing that bug about using 'unsigned char' for registers. > The algorithm will need to move away from using adjacency matrix to > probably a graph-vertex data structure approach as the adjacency matrix > could eat up memory. I don't know if it would help, but Audrey speaks highly of the Judy library: http://judy.sourceforge.net/ which provides sparse dynamic arrays in what is apparently a very efficient way. If Judy would provide the best solution, we could have Parrot use it. -- Chip Salzenberg <[EMAIL PROTECTED]>
