[Sbcl-devel] [patch] Thiemo's vector patch for hppa

[Larry Valkama]

Attached is the hppa version of Thiemo's stack-vector patch.
Hppa seem to be happy without register restriction (:offset) on variable
temp and offset in the vops. Guess it is an remnant in mips.

commit at will :)

[Larry Valkama]

dont commit :( the patch is bad.

Following would solve it but I dont know what form to throw at sbcl to
test those vops.

diff -Ndrup b/src/compiler/hppa/alloc.lisp c/src/compiler/hppa/alloc.lisp
--- b/src/compiler/hppa/alloc.lisp 2008-12-16 18:34:14.000000000 +0100
+++ c/src/compiler/hppa/alloc.lisp 2008-12-16 19:08:57.000000000 +0100
@@ -109,7 +109,7 @@
;; FIXME: It would be good to check for stack overflow here.
(pseudo-atomic ()
(align-csp temp)
- (set-lowtag other-pointer-lowtag alloc-tn result)
+ (set-lowtag other-pointer-lowtag csp-tn result)
(inst addi (* vector-data-offset n-word-bytes) csp-tn temp)
(inst add bytes csp-tn csp-tn)
(storew type result 0 other-pointer-lowtag)

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

[Nikodemus Siivola]

On Tue, Dec 16, 2008 at 8:14 PM, Larry Valkama
<rem...@users.sourceforge.net> wrote:

> Following would solve it but I dont know what form to throw at sbcl to
> test those vops.

dynamic-extent.impure.lisp should do it, unless the relevant tests
have been disabled. The following works as well. TIME should report 0
bytes consed if the stack-allocation works.

(defun foo-vec ()
(let ((vec (make-array 12 :element-type 'fixnum)))
(declare (dynamic-extent vec))
(foo vec)
nil))

(defun foo (x) (assert (typep x '(simple-array fixnum (12)))))

(time (loop repeat 100000 do (foo-vec)))

Cheers,

-- Nikodemus

[Larry Valkama]

> On Tue, Dec 16, 2008 at 8:14 PM, Larry Valkama
> <rem...@users.sourceforge.net> wrote:
>
>> Following would solve it but I dont know what form to throw at sbcl to
>> test those vops.
>
> dynamic-extent.impure.lisp should do it, unless the relevant tests
> have been disabled. The following works as well. TIME should report 0
> bytes consed if the stack-allocation works.
>
> (defun foo-vec ()
> (let ((vec (make-array 12 :element-type 'fixnum)))
> (declare (dynamic-extent vec))
> (foo vec)
> nil))
>
> (defun foo (x) (assert (typep x '(simple-array fixnum (12)))))
>
> (time (loop repeat 100000 do (foo-vec)))
>
> Cheers,
>
> -- Nikodemus
>

Thanks,

Must the following form return #(0 0) on the toplevel ? What should it
return ? Is it legal ?

(defun a ()
(let ((v (make-array 2 :element-type 'fixnum)))
(declare (dynamic-extent v))
v))

What I'm seeing is that we unwind stack/frame pointers and return an
not allocated pointer.

(defun a ()
(let ((v (make-array 2 :element-type 'fixnum)))
(declare (dynamic-extent v))
v))

compiles to:

VOP XEP-ALLOCATE-FRAME {#<SB-ASSEM:LABEL 1> NIL}
VOP NOTE-ENVIRONMENT-START {#<SB-ASSEM:LABEL 2>}
VOP NOTE-ENVIRONMENT-START {#<SB-ASSEM:LABEL 3>}
VOP CURRENT-STACK-POINTER => t10[NL2]
VOP ALLOCATE-VECTOR-ON-STACK '202!11>t12[NL3] '2!13>t14[NL4]
'2!13>t15[NL5] => t16[A0]
VOP RESET-STACK-POINTER t10[NL2]
VOP RETURN-SINGLE t7[OCFP] t9[LRA] t17[A0]

regards,
/larry

[Nikodemus Siivola]

On Thu, Dec 18, 2008 at 8:33 PM, Larry Valkama
<rem...@users.sourceforge.net> wrote:

> Must the following form return #(0 0) on the toplevel ? What should it
> return ? Is it legal ?
>
> (defun a ()
> (let ((v (make-array 2 :element-type 'fixnum)))
> (declare (dynamic-extent v))
> v))

The form itself is bogus, and can return just about anything, and can
legally induce nasal demons. The dynamic-extent declaration is a
promise that V is going to be dead when the LET has finished, so it
can be stack allocated.

This is analogous to the following C function:

int*
my_a (void)
{
int a[2];
return (int*) a;
}

> What I'm seeing is that we unwind stack/frame pointers and return

> not allocated pointer.

> VOP XEP-ALLOCATE-FRAME {#<SB-ASSEM:LABEL 1> NIL}
> VOP NOTE-ENVIRONMENT-START {#<SB-ASSEM:LABEL 2>}
> VOP NOTE-ENVIRONMENT-START {#<SB-ASSEM:LABEL 3>}
> VOP CURRENT-STACK-POINTER => t10[NL2]
> VOP ALLOCATE-VECTOR-ON-STACK '202!11>t12[NL3] '2!13>t14[NL4]
> '2!13>t15[NL5] => t16[A0]
> VOP RESET-STACK-POINTER t10[NL2]
> VOP RETURN-SINGLE t7[OCFP] t9[LRA] t17[A0]

That looks about right.

Cheers,

-- Nikodemus

[Larry Valkama]

Thanks for the quick answer. Great stuff, I thought it was provoking a
bug, but not. It was ok on x86, but there we use allocate-on-heap instead.

Here was the output for that form on hppa:

$ ./src/runtime/sbcl --core output/sbcl.core
This is SBCL 1.0.23.38, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (defun a ()

(let ((v (make-array 2 :element-type 'fixnum)))
(declare (dynamic-extent v))
v))

A
* (a)

debugger invoked on a TYPE-ERROR:
The value #<invalid object #x7ABEA4EF> is not of type SEQUENCE.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.

(LENGTH #<invalid object #x7ABEA4EF>)[:EXTERNAL]
0] *

[Nikodemus Siivola]

On Thu, Dec 18, 2008 at 10:01 PM, Larry Valkama
<rem...@users.sourceforge.net> wrote:

> Thanks for the quick answer. Great stuff, I thought it was provoking a
> bug, but not. It was ok on x86, but there we use allocate-on-heap instead.

That's funky. For me it stack allocated happily on x86 as well (and of
course lands in the debugger with a bogus object when trying to print
the return value.)

I'm guessing you either have an older SBCL on x86 (where stack
allocation doesn't happen in default compilation policy), stack
allocation explicitly turned off, or possibly the full evaluator
turned off so the function was never compiled.

Cheers,

-- Nikodemus

[Larry Valkama]

Nikodemus Siivola skrev:

> On Thu, Dec 18, 2008 at 10:01 PM, Larry Valkama
> <rem...@users.sourceforge.net> wrote:
>
>> Thanks for the quick answer. Great stuff, I thought it was provoking a
>> bug, but not. It was ok on x86, but there we use allocate-on-heap instead.
>
> That's funky. For me it stack allocated happily on x86 as well (and of
> course lands in the debugger with a bogus object when trying to print
> the return value.)
>
> I'm guessing you either have an older SBCL on x86 (where stack
> allocation doesn't happen in default compilation policy), stack
> allocation explicitly turned off, or possibly the full evaluator
> turned off so the function was never compiled.
>
> Cheers,
>
> -- Nikodemus
>

Oh, it was a while since I compiled on x86, its 1.0.18:

shrek@gudrun:~$ sbcl
This is SBCL 1.0.18, an implementation of ANSI Common Lisp.

More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (defun a ()

(let ((v (make-array '(42) :element-type 'single-float)))
(declare (dynamic-extent v))
v))

A
* (a)

#(0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
0.0 0.0
0.0 0.0 0.0 0.0)
*