[M3devel] function pointers and comparison to nil? mis-typed function pointers?
Jay
jayk123 at hotmail.com
Sun May 25 02:16:01 CEST 2008
I'm being lazy...
Tony can you explain this stuff?
Comparison of function pointers..What are the various representations and rules?
What does it mean to compare nested functions?
What does it mean to compare a function to NIL?
I'll poke around more.
What I am seeing is that comparison of function pointers to NIL is surprisinglyexpensive, and probably somewhat buggy. Or at least some of the runtimegenerated "metadata-ish" stuff is produced or typed incorrectly.
In particular, RTLinker.m3:
PROCEDURE AddUnit (b: RT0.Binder) = VAR m: RT0.ModulePtr; BEGIN IF (b = NIL) THEN RETURN END; line 119 m := b(0); line 120 IF (m = NIL) THEN RETURN END; line 121 AddUnitI(m); line 122 END AddUnit;
generates a lot of code, just for the first line:
(556) set_source_line source line 119 (557) load m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb (558) load_nil (559) if_eq (560) load m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb (561) load_indirect load address offset 0x0 src_t 0x5 dst_t 0x5 (562) load_integer integer n_bytes 0x0 hi 0x0 low 0x1 sign -1 (563) if_eq (564) set_label (565) load_nil (566) load m3cg_load (M3_DjPxE5_b): offset 0x0, convert 0xb -> 0xb (567) if_ne (568) set_label (569) exit_proc (570) set_label (571) set_source_line source line 120
The details on the load_integer trace might not be completely correct. I will test a fix shortly.Esp. that n_bytes gets decremented to zero before the trace.
Ok, I see now why some of the bloat -- because the "then return end" is on the same line.If it were written as: if (b = NIL THEN return end
It probably wouldn't look so bad. That took me a while to realize.
The following is generated for SPARC64_OPENBSD:
line 119
.stabn 68,0,119,.LLM61-.LLFBB4 .LLM61: ldx [%fp+2175], %g1 brz %g1, .LL26 nop ldx [%fp+2175], %g1 ldx [%g1], %g1 bus error here? yes, probably this one cmp %g1, -1 be %xcc, .LL27 nop.LL26: ldx [%fp+2175], %g1 brz %g1, .LL33 nop.LL27:
line 120
.stabn 68,0,120,.LLM62-.LLFBB4.LLM62:
ldx [%fp+2175], %g1 stx %g1, [%fp+2007] ldx [%fp+2007], %g1 brz %g1, .LL30 nop ldx [%fp+2007], %g1 ldx [%g1], %g1 or here ? cmp %g1, -1 bne %xcc, .LL30 nop ldx [%fp+2007], %g1 add %g1, 16, %g1 ldx [%g1], %g1 or here? stx %g1, [%fp+2015] ldx [%fp+2007], %g1 add %g1, 8, %g1 ldx [%g1], %g1 stx %g1, [%fp+2007].LL30: ldx [%fp+2007], %g1 ldx [%fp+2015], %g5 mov 0, %o0 call %g1, 0 nop mov %o0, %g1 stx %g1, [%fp+2023] ldx [%fp+2023], %g1 stx %g1, [%fp+1999] line 121
.stabn 68,0,121,.LLM63-.LLFBB4.LLM63: ldx [%fp+1999], %g1 brz %g1, .LL33 nop.LL32: .stabn 68,0,122,.LLM64-.LLFBB4.LLM64:
g1 points to RTSignal_I3
(gdb) x/i $pc0x3ff0a8 <RTLinker__AddUnit+28>: ldx [ %g1 ], %g1
(gdb) x/i $g10x4021f4 <RTParams_I3>: save %sp, -208, %sp
I am willing to accept that a "function pointer" is a pair of pointers, or even three pointers.A pointer to code, a pointer to globals for position independent code, a frame pointer to locals.That equality comparison of function pointers requires comparing two (or three) pointers.
(Though the global pointer shouldn't need comparing.)At least for nested functions. Less so for non-nested. ?Much less for comparison to NIL. ?
And either way, this code is reading bogus data.There isn't a pointer at the function address, there is code.
Something doesn't add up.
I'm going to try setting "aligned procedures" but that's quite bogus I think.
EqualExpr.m3 says
Note: procedures pointers are always aligned!
but maybe not?
Yeah yeah I'm being lazy. I'll read more code..
I also wonder if a "function pointer" can be optimized for the case of not being to a nested function.It looks like calling a function pointer is very inefficient.It looks like..am I reading that correctly?.. that if the pointer points to -1, then it is nested anda pair of pointers, and not otherwise. That -1 is treated specially as the first bytes of a function?
Is that a Modula-3-ism or a SPARC-ism?It looks like a Modula-3-ism. And it seems dubious.But I'll have to read more..
NT386GNU does the same sort of wrong looking thing:
LFBB4: pushl %ebp movl %esp, %ebp subl $24, %espLBB5: .stabn 68,0,117,LM60-LFBB4LM60: movl $0, -16(%ebp) .stabn 68,0,119,LM61-LFBB4LM61: movl 8(%ebp), %eax testl %eax, %eax je L26 movl 8(%ebp), %eax movl (%eax), %eax BAD cmpl $-1, %eax BAD je L27L26: movl 8(%ebp), %eax testl %eax, %eax je L33L27: .stabn 68,0,120,LM62-LFBB4LM62:
and NT386:
0:000> ucm3!RTLinker__AddUnit:00607864 55 push ebp00607865 8bec mov ebp,esp00607867 81ec0c000000 sub esp,0Ch0060786d 53 push ebx0060786e 56 push esi0060786f 57 push edi00607870 c745fc00000000 mov dword ptr [ebp-4],000607877 837d0800 cmp dword ptr [ebp+8],00:000> ucm3!RTLinker__AddUnit+0x17:0060787b 0f840f000000 je cm3!RTLinker__AddUnit+0x2c (00607890)00607881 8b7508 mov esi,dword ptr [ebp+8]00607884 8b5e00 mov ebx,dword ptr [esi] BAD 00607887 83fbff cmp ebx,0FFFFFFFFh BAD 0060788a 0f840f000000 je cm3!RTLinker__AddUnit+0x3b (0060789f)00607890 837d0800 cmp dword ptr [ebp+8],000607894 0f8505000000 jne cm3!RTLinker__AddUnit+0x3b (0060789f)0060789a e969000000 jmp cm3!RTLinker__AddUnit+0xa4 (00607908)
cm3!RTLinker__AddUnit+0x20:00607884 8b5e00 mov ebx,dword ptr [esi] ds:002b:0062c950=81ec8b550:000> u @esicm3!RTLinker_I3:0062c950 55 push ebp0062c951 8bec mov ebp,esp0062c953 81ec00000000 sub esp,00062c959 53 push ebx0062c95a 56 push esi0062c95b 57 push edi0062c95c 837d0800 cmp dword ptr [ebp+8],00062c960 0f8400000000 je cm3!RTLinker_I3+0x16 (0062c966)
This is just wrong.
Comparing bytes of code to -1.
I think the likely fix is for the "I3" code to be laid out as a "constant function pointer", a pointer to a pair of pointers where one points to the code and one is to -1. Something like that. That can't be quite correct given that the existing data is callable.
- Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080525/03271120/attachment-0002.html>
More information about the M3devel
mailing list