On Tue, Sep 30, 2014 at 03:34:00PM -0700, bulk88 wrote: > # New Ticket Created by bulk88 > # Please include the string: [perl #122872] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=122872 > > > > This is a bug report for perl from bulk88@hotmail.com, > generated with the help of perlbug 1.40 running under perl 5.21.4. > >From 7e4334762f61048c329fe2d50bf0c62d85648e8e Mon Sep 17 00:00:00 2001 > From: Daniel Dragan <bulk88@hotmail.com> > Date: Tue, 30 Sep 2014 18:30:26 -0400 > Subject: [PATCH] fix SV body docs in sv.c & PURIFY, cleanup body API, add > U32PBYTE macros > > Change setting of SV's new type in sv_flags directly using 1 byte > assignment to avoid a data dependency on a load, atleast on software level. > Instead of load, AND, OR, store machine code ops. Just do store. All x86 > and ARM CPUs, and other Perl CPUs have 1 byte memory reads/writes execept > early Alphas CPUs. Let the compiler and CPU designers figure out how to > read/write 1 byte in a 32/64/128 bit cpu. Make an assert that catches > breakage from sv_flags changes, and bizzare platforms. I understand the idea, and I agree with the general idea of being explicit in intent and relying on the compiler to translate it to hardware instructions. However, this patch includes the following tweak to sv.c: - SvFLAGS(sv) &= ~SVTYPEMASK; - SvFLAGS(sv) |= new_type; + *U32PBYTE0(&SvFLAGS(sv)) = new_type; I have to admit that I actually find the old way easier to read. Further, both on gcc-4.7.2 on Linux/amd64, and Solaris CC on SPARC, the old way actually gave a slightly smaller object file. I would not be at all surprised if the reverse were true on other systems. I did not test speed at all. -- Andy Dougherty doughera@lafayette.eduThread Previous | Thread Next