New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
exchange value of $a,$b without $temporary variable #5788
Comments
From nospam-abuse@ilyaz.org[A complimentary Cc of this posting was sent to
IIRC, this construction (well, a similar one) has subtle problems with perl5.6.0 -wle 'BEGIN{ *a=\$a::a; *b = \$b::b } \ I think this may be considered as a bug, the parser has enough info to Hope this helps, |
From @rgarciaIlya Zakharevich (via RT) wrote:
The bug is that the 2nd op aassign is not flagged as OPpASSIGN_COMMON I've a patch for this, but it works only in the case where In other words : (this patch for illustrative purposes only) Inline Patch--- op.c.orig Wed Jul 10 01:36:04 2002
+++ op.c Thu Aug 1 16:20:45 2002
@@ -3659,7 +3659,7 @@
for (curop = LINKLIST(o); curop != o; curop = LINKLIST(curop)) {
if (PL_opargs[curop->op_type] & OA_DANGEROUS) {
if (curop->op_type == OP_GV) {
- GV *gv = cGVOPx_gv(curop);
+ GV *gv = GvEGV(cGVOPx_gv(curop));
if (gv == PL_defgv || (int)SvCUR(gv) == PL_generation)
break;
SvCUR(gv) = PL_generation;
I don't know how to solve this in the general case, as I have |
From @gbarrOn Thu, Aug 01, 2002 at 04:39:22PM +0200, Rafael Garcia-Suarez wrote:
Right.
And only if that glob assignment is actually performed before the This is difficult to solve in the general case. It would need runtime Graham.
|
From @rgarciaGraham Barr wrote:
Indeed. Ilya pointed this out in the original c.l.p.misc discussion.
|
From @ysthOn Thu, 01 Aug 2002 17:59:24 +0200, raphel.garcia-suarez@hexaflux.com wrote:
ref to glob assignment is handled just after the 2nd GV_UNIQUE_CHECK |
@chorny - Status changed from 'open' to 'stalled' |
From ambrus@math.bme.huCreated by ambrus@math.bme.huAfter the statements '*x=*y; @x=8; @y=@x;', the array @x should still $ perl5.12.2 -we '*x=*y; @x=8; @y=@x; warn @x;' Perl 5.14.0RC1 still behaves the same as 5.13.11: $x[0] becomes undefined, Thanks, Ambrus Perl Info
|
From @cpansproutOn Sun May 01 14:05:56 2011, b_jonas wrote:
This is the no-common-vars optimisation (aka the absence of the In ($a,$b) = ($b,$a) assignments, perl has to copy the RHS into That can be *really* slow. So perl avoids doing it if the variables But one can easily fool perl with glob assignments. (If we add support If the stack were refcounted, fixing this would be easy (just check the |
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Sat Jul 27 05:06:39 2002, nospam-abuse@ilyaz.org wrote:
Twelve years after the report, this is finally fixed, in commit ff2a62e. -- Father Chrysostomos |
The RT System itself - Status changed from 'stalled' to 'open' |
@cpansprout - Status changed from 'open' to 'resolved' |
From @bulk88On Thu Sep 18 20:07:16 2014, sprout wrote:
I think this is a bad implementation. Instead of adding another 4 bytes to every GV, why not turn gp_line into a bitfield (C bitfield or bitwise op synthesized), top bit is the GPf_ALIASED_SV flag. Do we need to support over 2 billion lines of perl source code in 1 file? -- |
From @cpansproutOn Thu Sep 18 22:06:40 2014, bulk88 wrote:
On 64-bit systems, it fills in an alignment hole (assuming line_t is 32 bits). On 32-bit systems, the size goes from 44 to 48 bytes. On Windows memory is allocated in 8-byte chunks;¹ on 32-bit darwin in 16-byte chunks. Are there any systems that mallocate 4-byte chunks any more? If not, then this makes no difference. Even so, it was partly to offset any possible increase in memory usage from this bug’s fix that I stopped many CVs from having to have GVs to live in. ¹ This is based on a message that you posted when we were discussing COW techniques.
I’m not necessarily opposed, though I’m not sure I feel comfortable changing the way we use line_t, either. If you can prove me wrong about malloc sizes, I’ll probably go ahead and follow your suggestion. -- Father Chrysostomos |
From @bulk88On Thu Sep 18 22:26:26 2014, sprout wrote:
If in the future, GPs are allocated as arenas, 4 bytes on 32 bit OSes would definitely matter.
Here is the table of request alloc size, vs total size (including header+unused but reserved anyway spare bytes at end) https://rt-archive.perl.org/perl5/Ticket/Display.html?id=114820#txn-1159502 If Perl DIDNT add any extra headers on Win32, you would be correct that 44 (0x2C) and 48 (0x30) make no difference. ptr=3324C8 i=2C _msize=2C RevEngd req sz=2C Actual=38 ptr=3324C8 i=30 _msize=30 RevEngd req sz=30 Actual=38 at malloc(0x31/49), it goes into another bucket with more slack space. But Perl on Win32 adds a header to each allocation. Tracing/stepping the old GP code, Initial req in newGP, 0x2c enters OS's native allocator HeapAlloc (which is aliased to RtlAllocateHeap) as request size 0x38 Dump of C stack args on entry to RtlAllocateHeap 0x0012FAF8 77c2c3c9 00360000 00000000 00000038 00365f38 ÉÃÂw..6.....8...8_6. (Return Address) (HANDLE hHeap) (DWORD dwFlags) (SIZE_T dwBytes) (not an arg, unknown C auto) ntdll.dll!_RtlAllocateHeap@12() A req of 0x38 takes a 0x40 slot. ptr=332500 i=38 _msize=38 RevEngd req sz=38 Actual=40 But a req of 0x3c, it takes a 0x48 slot, a memory increase of 8 bytes. ptr=332540 i=3C _msize=3C RevEngd req sz=3C Actual=48 If Win32 Perl's malloc code is rewritten (I might do it one day), then there wont be a perl added header, but its not on my immediate todo list. In any case, unlike other interpreted programing language engines, Perl never steals always 0 bits from pointers or other fields, the webbrowser you are reading this with, does steal bits from pointers. -- |
From perl5-porters@perl.orgDaniel Dragan wrote:
I stand corrected.
Is there any way to grep for that in the lynx source? |
From @cpansproutOn Thu Sep 18 22:06:40 2014, bulk88 wrote:
Can I assume that line_t is 32 bits everywhere? Or should I use U32 for the bitfield? -- Father Chrysostomos |
From @bulk88On Fri Sep 19 22:21:27 2014, sprout wrote:
What is wrong with using a http://www.tutorialspoint.com/cprogramming/c_bit_fields.htm ? -- |
From @rurbanOn Fri, Sep 19, 2014 at 12:06 AM, bulk88 via RT And do we really have to endure such enormous binary ABI changes directly into Please revert and move to a branch |
From @cpansproutOn Sat Sep 20 07:10:21 2014, bulk88 wrote:
Let me rephrase the question: If line_t is some size other than 32 bits on an exotic compiler or platform, then is it safe to do this? line_t:31 gp_line; -- Father Chrysostomos |
From @bulk88On Fri Sep 19 16:09:19 2014, perl5-porters@perl.org wrote:
I downloaded some source and searched it, Lynxs, no After I wrote the below, I found someone already wrote this up in http://wingolog.org/archives/2011/05/18/value-representation-in-javascript-implementations Mozilla Spidermonkey (I've written C code for it before), yes Spidermonkey's JSValue is passed by copy, as a 4 byte int. The 4 byte data unit contain primative ints or primative bools that are not GCed, or a GCed pointer to something. I am using Spidermonkey 1.8 from March 2009. After Spidermonkey ~1.8/Firefox 3.*, when Mozilla went into rapid release cycle, Mozilla made a decision to drop support Mozilla embedder/API stability, and Spidermonkeys devs decided to rewrite the engine in C++ to be able to hang out with the cool kids on the school yard, so I have no idea and dont care what the lastest Spidermonkey is doing since I can't use it for my internal use. /* /* Type tag bitfield length and derived macros. */ /* Predicates for type testing. */ /* Objects, strings, and doubles are GC'ed. */ I am not familiar with Google V8, but there are some examples of tagged pointers and it seems to be the same concept as in Spidermonkey except with a large scoop of OOP obfuscation. The core unit is 4 bytes, and is a primitive int or a GCed/heap *. Smi* Smi::FromIntptr(intptr_t value) { #define HAS_SMI_TAG(value) \ bool Object::IsSmi() const { bool Object::IsHeapObject() const { V8_INLINE static bool HasHeapObjectTag(const internal::Object* value) { // Tag information for HeapObject. class Smi: public Object { // Convert a value to a Smi object. int Smi::value() const { class Internals { V8_INLINE static int SmiValue(const internal::Object* value) { // Smi constants for 32-bit systems. // // Formats of Object*: // Smi represents integer Numbers that can be stored in 31 bits. Now for Webkit/Safari, and answer is yes on tagged pointers. Webkit steals HIGH bits on 64 bit OSes, not low 2 or 3 bits of the pointer like Spidermonkey and V8. All Webkit boxed pointers are always double NAN. !!isnan(*(double*)webkit_boxed_val_that_is_a_boxed_ptr) == 1 Webkit uses a 8 byte long union, which I think is pass by copied, and the union seems to be limiting memory space to 2/4GB even on 64 bit OSes. The high 4 bytes are info on how to interpret the union. Low 4 bytes are the pointer if the boxed data unit is a pointer. A SO post conflicts with the code below which is from WebKit @ r173798, and the SO post says that JSC uses 52 bit pointers on 64 bit OSes http://stackoverflow.com/questions/17698605/how-to-overcome-javascripts-56-bit-limitation . While I see support for Int52 format for JSC JSValue *s, I dont see it being used to store JSObject *s. So Webkit/Safari is not 64 bit clean at all (is that a feature or a limitation? ;-) ). ALWAYS_INLINE int32_t JSValue::toInt32(ExecState* exec) const inline bool JSValue::isInt32() const inline int32_t JSValue::asInt32() const class JSValue { union EncodedValueDescriptor { inline JSObject* JSValue::getObject() const ALWAYS_INLINE JSCell* JSValue::asCell() const inline bool JSValue::isCell() const inline uint32_t JSValue::tag() const inline JSValue::JSValue(const JSCell* ptr) #if USE(JSVALUE32_64) inline bool isInt52(double number) inline int64_t tryConvertToInt52(double number) Internet Explorer 6, no tagged pointers. Pointer can be all 2^32 or 2^64 permutations. Circa 2001 or 2008 design depending on how you count it. Maybe its even a Win16 design :D IE is obviously closed source, so these comes from REing. JScript.dll version 5.7 from 2008 shows primatives/boxeds being 16 bytes units that are passed by copy. First/low 4 bytes in asm (2 bytes on paper) are the tag/type code. The primative double lives in the upper 8 bytes of the union. This identical to MS OLE/VB/COM VARIANTs which are http://msdn.microsoft.com/en-us/library/windows/desktop/ms221627%28v=vs.85%29.aspx or see http://en.wikipedia.org/wiki/Variant_type . This makes IE6 JS's basic type being the largest of all 4 browsers with JS compared in this post, at 16 bytes on a 32 bit machine. This is identical to Perl's SV and 2 or 4 byte flag determining type. So why are we coding as if its the days of Disco? and why is P5's design looks like bell bottoms? Partial answers: I know P1 is from 1987, P5 broke API compatibility with P4 in 1993, but SV API is a lil better than P4's 24 byte STR struct, it isn't the 8 or 4 bytes of every competitor except MS. I dont see any reason why a 4 or 8 byte primative/boxed type couldn't have been used from 1993 onwards with P5. -- |
From @cpansproutOn Sat Sep 20 09:34:43 2014, sprout wrote:
Oops, the :n is in the wrong spot. I decided to go with U32, which I did in 39ff6c3. -- Father Chrysostomos |
From @janduboisOn Mon, Sep 22, 2014 at 9:57 PM, Father Chrysostomos via RT
For consistency this should probably be PERL_BITFIELD32 instead of Cheers, |
From @cpansproutOn Tue Sep 23 09:38:32 2014, jdb wrote:
Thank you. That was the answer I was looking for. I have changed it in commit e12ab2f. -- Father Chrysostomos |
From @khwilliamsonOn 09/20/2014 08:10 AM, bulk88 via RT wrote:
So why doesn't Perl use C language bit fields in general? It's easier I just presumed that bit fields were from C99 and that's why we didn't |
From ambrus@math.bme.huOn 9/24/14, Karl Williamson <public@khwilliamson.com> wrote:
As far as I can see, bit fields are not generally worth to use in any Ambrus |
From @jhiOn Wednesday-201409-24, 1:46, Zsbán Ambrus wrote:
I have not much experience on actually trying to use bit fields, but After a google-aided refresher: extremely unportable in that the |
From @doughera88On Tue, Sep 23, 2014 at 10:45:31PM -0600, Karl Williamson wrote:
I don't recall any specific discussion of that issue, but I do recall None of that really matters much today, however, except for a -- |
Migrated from rt.perl.org#15667 (status was 'resolved')
Searchable as RT15667$
The text was updated successfully, but these errors were encountered: