digitalmars.D.learn - enum array is not compile time generated?
- tsukikage <tsukikage dmail.com> Mar 19 2011
- tsukikage <tsukikage dmail.com> Mar 19 2011
- bearophile <bearophileHUGS lycos.com> Mar 19 2011
- tsukikage <tsukikage dmail.com> Mar 19 2011
- Jonathan M Davis <jmdavisProg gmx.com> Mar 19 2011
Hi,
I previous expected that the enum A inside foo, or enum B at module
level used by baz are immutable compile time generated static array, but
by looking at the disassembled source, I found A is constructed every
time entering the function in run time. Instaed, static A inside bar is
construct at compile time (found at section CRT$XIA), seems to be
mutable at run time.
Would please someone explain why enum A etc. is constructed at run time?
thank you!
--------------
import std.stdio ;
enum B = [0x1234,0x2222,0x3333,0x4444] ;
enum D = [0x9999,0x8888,0x7777,0x6666] ;
int foo(int i) {
enum A = [0x1111,0x2222,0x3333,0x4444] ;
return A[i] ;
}
int bar(int i) {
static A = [0x4444,0x3333,0x2222,0x1111] ;
return A[i] ;
}
int baz(int i) {
return B[i] ;
}
void main() {
auto c = baz(2) ;
auto b = bar(2) ;
auto a = foo(2) ;
auto d = D[2] ;
writefln("Hey here! %d %d %D", a, b, c, d) ;
}
--------------
compile with only -release, dmd windows.
disassembled:
00402010: enter 00004,000 // baz - module enum
00402014: mov [ebp][-04],eax
00402017: push 000004444
0040201C: push 000003333
00402021: push 000002222
00402026: push 000001111
0040202B: push 004
0040202D: mov ecx,000466080
00402032: push ecx
00402033: call 000408158
00402038: mov edx,[ebp][-04]
0040203B: mov eax,[eax][edx]*4
0040203E: add esp,018
00402041: leave
00402042: retn
00402043:
00402044: enter 00004,000 // bar - static
00402048: push ebx
00402049: mov ecx,fs:[0000002C]
00402050: mov edx,[ecx]
00402052: mov ebx,[edx][00000004]
00402058: mov edx,[edx][00000008]
0040205E: mov eax,[edx][eax]*4 // found THE STATIC ARRAY
00402061: pop ebx // at section CRT$XIA
00402062: leave
00402063: retn
00402064: enter 00004,000 // baz - module enum
00402068: mov [ebp][-04],eax
0040206B: push 000004444
00402070: push 000003333
00402075: push 000002222
0040207A: push 000001234
0040207F: push 004
00402081: mov ecx,000466080
00402086: push ecx
00402087: call 000408158
0040208C: mov edx,[ebp][-04]
0040208F: mov eax,[eax][edx]*4
00402092: add esp,018
00402095: leave
00402096: retn
00402097:
00402098: enter 00008,000
0040209C: mov eax,000000002
004020A1: call 000402064 // baz - moudle enum
004020A6: mov [ebp][-08],eax
004020A9: mov eax,000000002
004020AE: call 000402044 // bar - static
004020B3: mov [ebp][-04],eax
004020B6: mov eax,000000002
004020BB: call 000402010 // foo - function enum
004020C0: mov ecx,000007777 // D[2] hardcoded
004020C5: push d,[004650AC] // other elements of D, eg 0x9999
004020CB: push d,[004650A8] // not found at exe
004020D1: push eax
004020D2: push d,[ebp][-04]
004020D5: push d,[ebp][-08]
004020D8: mov eax,ecx
004020DA: call 0004020E4
004020DF: xor eax,eax
004020E1: leave
004020E2: retn
Mar 19 2011
correction: 00402010: enter 00004,000 // foo - function enum 00402014: mov [ebp][-04],eax
Mar 19 2011
tsukikage:Would please someone explain why enum A etc. is constructed at run time?
enum is currently very broken. The same happens with associative arrays, etc. Bye, bearophile
Mar 19 2011
Oh, I see. Thanks. bearophile wrote:tsukikage:Would please someone explain why enum A etc. is constructed at run time?
enum is currently very broken. The same happens with associative arrays, etc. Bye, bearophile
Mar 19 2011
On Saturday 19 March 2011 06:02:49 bearophile wrote:tsukikage:Would please someone explain why enum A etc. is constructed at run time?
enum is currently very broken. The same happens with associative arrays, etc.
Well, enum works perfectly in that its value doesn't change. It's always the same value. The problem is that the way that it's currently implemented is highly inefficient - though the fact that it recreates the value every time would make it so that is failed where you'd expect it to succeed - though arguably that's also an implementation detail. Regardless, enum works fine in the general case, but it's current implementation is inefficient. I expect that it will be fixed at some point, but as with many things, who knows where it is on the TODO list. There's always something more important/critical that needs to be done. - Jonathan M Davis
Mar 19 2011









tsukikage <tsukikage dmail.com> 