--- Comment #4 from Michael Rynn <y0uf00...@gmail.com> 2009-12-16 19:10:53 PST
Sorry to split into 3 bits. When I press tab the focus goes to the submit
I stepped thru the x86 code generated in the debugger using Visual Studio
2008 after conversion with cv2pdb -- great tool.
In the noblit case :-
The code calls __aaGet
the arguments are the key, typeinfo...@__init, and address of the
An address? is returned in EAX, which is checked for null,
The value of nval is directly blitted to the returned address.
__aaGet does the checking if the key points to existing value,
and allocates memory for new value as required.
In the postblit case the generated code seems to miss the point entirely.
The code initially makes a temporary copy of val. and calls the postblit
constructor, which calls this(this). --> @postblit__cpctor -->
Why is a prior temporary copy required, when one hopes that its the map
that is going to provide the final destination?
>From the temporary copy, it then pushes the bits value of the temporary
(not the address!),
then the key, then typeinfo...@__init, and address of map.
The code then calls __aaGetRvalue ( not __aaGet )
__aaGetRvalue gives up very quickly, failing its first check.
It pushes registers, and then checks the address in [esp+18h].
This being null, it pop-exits with null as the result in eax.
Obviously __aaGetRvalue is expecting something else to be setup.
Presumably if __aaGetRvalue actually worked, it would just reblit
the value in the temporary to the memory it allocated or found, without
calling postblit again.
I would like to see ideally.
No temporary copy made initially.
The map lookup able to allocate or find memory for the key.
The address returned.
The copy made and then post-blit called.
Failing that , please fix up __aaGetRvalue so it does the right thing.
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------