Edi Weitz <[EMAIL PROTECTED]> writes:

> Is this a specific CMUCL/PCL issue? Is there a way to work around this
> without going back to my non-CLOS version?

I'm afraid I can't help here, but it doesn't look like a specific PCL
issue to me.

Why I'm following up is that I noticed something strange in CVS CMUCL
that I wanted to add below.

> PS: Here's an excerpt from by actual code.
> 
>     1. The original closure created by a function:
> 
>   4804EC8A:       ADD   [EAX], AL
>        C8C:       ADD   [EAX], AL
>        C8E:       ADD   [EAX], AL
>        C90:       .ENTRY "DEFUN CREATE-STRING-MATCHER"() ; FUNCTION
>                   ;;; common part starts here
> 
>     2. The 'same' closure created by a CLOS method:
>   
>   4802E829:       ADD   [EAX], AL
>         2B:       ADD   [EAX], AL
>         2D:       ADD   [EAX], AL
>         2F:       ADD   [ESI+44], BH
>         32:       ADD   [EAX], EAX
>         34:       DEC   EAX
>         35:       CALL  #x30F4303C
>         3A:       ADD   CL, [EAX-25]
>         3D:       RET
>         3E:       ADD   ECX, [EAX+11]
>         41:       ADD   [EAX], AL
>         43:       SUB   [EDI-49], BH
>         46:       ADD   [EAX], CH
>                   ;;; common part starts here
>   

And in CMUCL from CVS:

USER ==> (disassemble (baz (make-instance 'bar :a 1)))
480F2610:       .entry "defmethod baz (bar)"() ; function
      28:       pop   dword ptr [ebp-8]
      2B:       lea   esp, [ebp-32]
      2E:       mov   edx, esi
      30:       mov   ebx, esp               ; No-arg-parsing entry point
      32:       sub   esp, 12
      35:       mov   eax, [#x480F2608]      ; #<FDEFINITION object for a>
      3B:       mov   ecx, 4
      40:       mov   [ebx-4], ebp
      43:       mov   ebp, ebx
      45:       call  dword ptr [eax+5]
      48:       mov   esp, ebx
      4A:       mov   ebx, [#x480F260C]      ; #<Function "defmethod baz (bar)"
                                                 {480F26B9}>
      50:       mov   byte ptr [#x28F001D4], 0 ; 
common-lisp::*pseudo-atomic-interrupted*
      57:       mov   byte ptr [#x28F001BC], 4 ; common-lisp::*pseudo-atomic-atomic*
      5E:       mov   ecx, 16
      63:       add   ecx, [#x28F00504]      ; x86::*current-region-free-pointer*
      69:       cmp   ecx, [#x28F0051C]      ; x86::*current-region-end-addr*
      6F:       jbe   L0
      71:       call  #xB0000038             ; alloc_overflow_ecx
      76: L0:   xchg  ecx, [#x28F00504]      ; x86::*current-region-free-pointer*
      7C:       lea   ecx, [ecx+1]
      7F:       mov   dword ptr [ecx-1], 642
      86:       mov   eax, [ebx+3]
      89:       mov   [ecx+3], eax
      8C:       mov   byte ptr [#x28F001BC], 0 ; common-lisp::*pseudo-atomic-atomic*
      93:       cmp   byte ptr [#x28F001D4], 0 ; 
common-lisp::*pseudo-atomic-interrupted*
      9A:       jeq   L1
      9C:       break 9                      ; Pending interrupt trap
      9E: L1:   mov   [ecx+7], edx
      A1:       mov   edx, ecx
      A3:       mov   ecx, [ebp-8]
      A6:       mov   eax, [ebp-4]
      A9:       add   ecx, 2
      AC:       mov   esp, ebp
      AE:       mov   ebp, eax
      B0:       jmp   ecx

which is similar to what one gets from using a DEFUN like this

(defun foo-test (y)
  (let ((x (foo y)))
    (lambda () x)))

Is the closure entry point somewhere in the middle of that?






Reply via email to