http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #94 from Walter Bright <bugzi...@digitalmars.com> 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: -------

Reply via email to