develooper Front page | perl.perl5.porters | Postings from October 2013

[perl #120314] t/re/fold_grind.t spews tons of "Attempt to free temp prematurely" warnings on DEBUGGING but ultimately passes

Thread Previous | Thread Next
From:
bulk88 via RT
Date:
October 26, 2013 16:52
Subject:
[perl #120314] t/re/fold_grind.t spews tons of "Attempt to free temp prematurely" warnings on DEBUGGING but ultimately passes
Message ID:
rt-4.0.18-14234-1382806338-1707.120314-15-0@perl.org
On Sat Oct 26 03:17:47 2013, pcm wrote:
> On Sat, Oct 26, 2013 at 5:27 AM, Father Chrysostomos via RT
> <perlbug-followup@perl.org> wrote:
...........
> >>
> >> On another note, can anyone provide context as to why our final
> >> fallback to 'define bool char', except for VMS?  Couldn't we just
> >> change *that* to be int everywhere, unless otherwise defined?
> >
> > That would increase memory usage on C89 compilers.
> 
> bulk88: could you change the define for bool from char to int in your
> setup?  If it's as simple as that, could you tell us what kind of
> effect it has on the size?  I can't think of a better person for that
> kind of comparison.
> 

TLDR: need a couple days to compile a new perl and will give stats and a perlbench run at that time, also some compilers could theoretically stuff multiple bools/chars into 1 int, but VC 2003 doesn't

All opinion is from VC 2003. Also doing this somewhat from memory since my favorite asm book isn't next to me ATM. I've never seen Visual C 2003 put 2 bools/chars into a 4 byte C stack slot or 2 chars into a register although it is possible with registers EA*-ED* using AH/AL, etc. If a bool isn't stored across a function call, it will often be optimized to a EFLAGS check and a conditional jump and machine instructions will be reordered to not overwrite EFLAGS, therefore a bool across function calls is what I will discuss. The problem is, only one of the 4 registers that are byte addressable are non-volatile, EBX. The 2 main non-vol registers on x86, ESI and EDI, are NOT splitable. EBP (stack frame or GP depending on compiler design), also isn't splitable. Not splitable means it can only be manipulated as one 32 bit value and the lower 16 bit value (upper bit manipulation requires |= and <<).

On x64 ALL registers can be addresses as lowest byte. Even RSI/RDI. But there is no new AH/BH/CH/DH style operands in x64. AH/BH/CH/DH still exist on x64. So it is technically possible to put 2 chars into a int. Making the "bool" be an "int" would likely prevent that optimization if it would happen. The other side of the story is, it is possible VC's devels decided bitfields and *H registers and splitting of registers is a very bad idea due to data dependencies in the CPU, so it won't paralelize during execution. *H registers could also be much slower if they are software emulated by the CPU. I once did tried to do a &= on 16 bit SP instead of copying ESP to EAX, then a &= on 8 bit AL in hand written asm, then copying EAX to ESP. The function was 2 instructions shorter but doubled in execution time. 16 bit SP is obviously software emulated on an Intel Core 2 the same way all of real mode (16 bit machine code) is microcode emulated by the CPU.

So the question is, will the CPU split bitfields or AH/AL into separate phantom registers and performance improves (2 bools became 1 machine code register, other random int is 2nd machine code register, the whole thing becomes 3 internal registers and executes simultaneously) over using 3 ints (2 bools become 2 machine code registers, 3rd int is other random int and goes on C stack, executes as 2 internal registers and a L1 fetch simultanously, other random int executed in next cycle after L1), or are AH and AL implemented in 2 to 3 32 bit operations in software and they are slower than 2 full size E*X regs?

The interp struct will probably skyrocket in size by making bool into an int since there are sequences of 4 and 8 bools in a row in the struct.

-- 
bulk88 ~ bulk88 at hotmail.com

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=120314

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About