http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #94 from Walter Bright <[email protected]> 2011-04-14 11:54:00 PDT --- (In reply to comment #92) > This is roughly what I did in my initial patches. The comments at the top of > the file describe it in more detail. See > http://d.puremagic.com/issues/attachment.cgi?id=488&action=edit I think that covers things, except for handling ambiguous pointers. But I think it still consumes a lot of static storage. I suggest a state machine, which will consume roughly 1 byte per pointer in the type. The state machine is a list of instructions, one byte each: 00 end of state machine 01 pointer at this offset, advance offset by size_t 02 advance offset by size_t, pointer here, advance by size_t 03 advance offset by 2*size_t, pointer here, advance by size_t .. 0F advance offset by 0F*size_t, pointer here, advance by size_t 10 advance offset by the following two bytes 11 ambiguous pointer at this offset, advance offset by size_t 12 execute loop nn times, where nn is the next byte. loop starts after nn 13 same as 12, but nn is the value in the next 2 bytes 14 end of loop (loops can nest) 15 the following size_t bytes are a pointer to another state machine to call like a function Or something like that. I think the state machine would be very compact, and would be fast to execute. A function can be added to TypeInfo to return the state machine for that type. The compiler would generate the data for the state machine. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
