Front page | perl.perl5.porters |
Postings from March 2013
On Wed Mar 27 18:00:17 2013, bulk88 wrote: > > Summary, on Win32, new way (8 bytes) is slightly worse than before (5 or > 7 bytes), but still better than the original situation (19 bytes). Its ok. > > On Win32 (not discussing any other OS), Perl_croak_memory_wrap is still > a savings. On VC 2003 32 bit , it will now probably (I didn't compile > f8fd8bfff8eb57156a0ab858d4c185701258b0e3) be > ____________________________________________ > jmp_conditional didnt_wrap (2 bytes) > call *(image_import_table_Perl_croak_memory_wrap) (6 bytes) > didn't_wrap: > ____________________________________________ > which is still shorter than > ________________________________________________ > jmp_conditional didnt_wrap (2 bytes) > push *(image_import_table_PL_memory_wrap) (6 bytes) > push in_image_%s_fmt_string (5 bytes) > call *(image_import_table_Perl_croak_nocontext) (6 bytes) > didn't_wrap: > ________________________________________________ > > As a static non-inline previously, *ideally* (C compiler dependent) it > would have been > ________________________________________________ > jmp_conditional relative_to_croak_memory_wrap (5 bytes) > ________________________________________________ > > Visual C 2003 in 32 bit mode I remember did > ________________________________________________ > jmp_conditional didnt_wrap (2 bytes) > jmp_unconditional in_image_S_croak_memory_wrap (5 bytes) > didn't_wrap: > ________________________________________________ > which is strange and unideal, (I will guess, in the internal design of > VC, it probably has to do with the 1st jump being a flow control > bytecode op, and the 2nd jump being the func call bytecode op). > > In theory, a C compiler could do (VC will do this in debug mode to > enable > http://msdn.microsoft.com/en-us/library/bcew296c%28v=vs.80%29.aspx ), > looking at my 5.12 Strawberry (GCC -O2), it does NOT do this) > > ________________________________________________ > jmp_conditional relative_to_Perl_croak_memory_wrap_stub (5 bytes) > didn't_wrap: > ________________________________________________ > somewhere else in the image, once per image, there is the following function > ________________________________________________ > jmp_unconditional *(image_import_table_Perl_croak_memory_wrap) (6 bytes) > ________________________________________________ > > But I guess there is a performance problem with doing that so it just > isn't done by any Windows C compiler in an optimized build. Forgot to mention, the above numbers assume croak_memory_wrap() is a XS library, not the interp (perl517.dll). They also assume the compiler wasn't set to "aggressive inline" mode and inlined all the S_croak_memory_wrap calls, which could happen. Inside the interp, a jmp_conditional relative_32_bits_to_current_instruction_register can still be done, since it is within the same image. -- bulk88 ~ bulk88 at hotmail.com --- via perlbug: queue: perl5 status: open https://rt.perl.org:443/rt3/Ticket/Display.html?id=116989Thread Previous | Thread Next