Thanks. The first str seems to be doing that :). One more question, i couldnt quite follow how the below checks if the map check fails, dont receiver_reg and object represent same object? (or is it that they represent same when code is initially generated but receiver reg object can change)
__ ldr(scratch, FieldMemOperand(receiver_reg, HeapObject::kMapOffset)); __ cmp(scratch, Operand(Handle<Map>(object->map()))); Thank You Zaheer 2010/6/11 Søren Gjesse <[email protected]>: > The code generating this code is in stub-cache-arm.cc, > method StubCompiler::GenerateStoreField(). In there there are comments on > what is generated. The map is the hidden class, and you are right a separate > stub is generated for each property/receiver combination. These monomorphic > stubs are shared in the sense that they are stored in a cache where a lookup > is done when a specific one is needed. Also the megamorphic stubs (used in > places where different names/receivers are seen) probes this cache for a > monomorphic stub to call before entering the runtime system. > Regards, > Søren > > On Fri, Jun 11, 2010 at 10:39, zaheer ahmad <[email protected]> wrote: >> >> hi, >> >> Iam looking at the arm assembly for a storeic monomorphic stub. its >> not clear to me which step does direct access to the property and also >> where the hidden class is accessed (i assume the map somehow >> represents the hidden class). could you pls give some pointers. >> >> Also assuming unique stub is generated for each property, much of the >> code seems common checks, isnt it possible to share or am i wrong. >> >> thanks, >> Zaheer >> >> kind = STORE_IC >> ic_state = MONOMORPHIC >> ic_in_loop = 0 >> type = FIELD >> name = c >> Instructions (size = 116) >> 0xf5ac5a00 0 e3110001 tst r1, #1 >> 0xf5ac5a04 4 0a000014 beq +88 -> 92 (0xf5ac5a5c) >> 0xf5ac5a08 8 e5113001 ldr r3, [r1, #-1] >> 0xf5ac5a0c 12 e59fc054 ldr ip, [pc, #+84] ;; >> object: 0xf5b26ae1 <Map> >> 0xf5ac5a10 16 e153000c cmp r3, ip >> 0xf5ac5a14 20 1a000010 bne +72 -> 92 (0xf5ac5a5c) >> 0xf5ac5a18 24 e5810013 str r0, [r1, #+19] >> 0xf5ac5a1c 28 e3100001 tst r0, #1 >> 0xf5ac5a20 32 0a00000c beq +56 -> 88 (0xf5ac5a58) >> 0xf5ac5a24 36 e3a02014 mov r2, #20 >> 0xf5ac5a28 40 e20134ff and r3, r1, #-16777216 >> 0xf5ac5a2c 44 e35304f6 cmp r3, #-167772160 >> 0xf5ac5a30 48 0a000008 beq +40 -> 88 (0xf5ac5a58) >> 0xf5ac5a34 52 e59fc030 ldr ip, [pc, #+48] >> 0xf5ac5a38 56 e0812002 add r2, r1, r2 >> 0xf5ac5a3c 60 e002200c and r2, r2, ip >> 0xf5ac5a40 64 e1a02422 mov r2, r2, lsr #8 >> 0xf5ac5a44 68 e1c1100c bic r1, r1, ip >> 0xf5ac5a48 72 e5913008 ldr r3, [r1, #+8] >> 0xf5ac5a4c 76 e3a0c001 mov ip, #1 >> 0xf5ac5a50 80 e183321c orr r3, r3, ip, lsl r2 >> 0xf5ac5a54 84 e5813008 str r3, [r1, #+8] >> 0xf5ac5a58 88 e12fff1e bx lr >> 0xf5ac5a5c 92 e59fc00c ldr ip, [pc, #+12] ;; code: >> BUILTIN, StoreIC_Miss >> 0xf5ac5a60 96 e12fff1c bx ip >> 0xf5ac5a64 100 03000003 constant pool begin >> 0xf5ac5a68 104 f5b26ae1 constant >> 0xf5ac5a6c 108 00001fff constant >> 0xf5ac5a70 112 f5b45280 constant >> >> >> thanks, >> Zaheer >> >> -- >> v8-users mailing list >> [email protected] >> http://groups.google.com/group/v8-users > > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
