beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: https://libera.irclog.whitequark.org/picolisp | Check www.picolisp.com for more information
ygrek has quit [Remote host closed the connection]
ygrek has joined #picolisp
fbytez has quit [Quit: byte byte]
fbytez has joined #picolisp
corecheckno has quit [Remote host closed the connection]
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
ygrek has quit [Remote host closed the connection]
ygrek has joined #picolisp
ygrek has quit [Remote host closed the connection]
corecheckno has joined #picolisp
<tankf33der> good day
<tankf33der> abu[7]: installed s390x machine again in qemu.
<abu[7]> Hi tankf33der!
<tankf33der> and besides everything else tried pil21 stack issue again
<abu[7]> You have a new idea?
<tankf33der> i have found a smaller example of fail
<tankf33der> (co 'a (* 3 4)) -> trivial code works.
<abu[7]> Coroutines make assumptions about the stack
<abu[7]> Perhaps the direction?
<abu[7]> Pil assumes it grows downwards
<tankf33der> good it is not a bug.
<abu[7]> I don't know
<tankf33der> ok
<abu[7]> Who uses s390x typically?
<tankf33der> customers from ibm
<abu[7]> ok
<tankf33der> idea. i will compile x64 version with strong strack protection and will try run chacha20 code on it
<abu[7]> It is not a matter of protection I think, but something in the s390x architecture breaking Pil assumptions
<abu[7]> see @doc/structures at the end of the file
<tankf33der> it is to find out via c code, right ?
<tankf33der> i run just trivial linux on s390x
<abu[7]> Not sure ...
<tankf33der> pil21 under stack protection works. all passed.
<tankf33der> good sign.
<abu[7]> Very good
<abu[7]> So it is *only* the coroutine?
<tankf33der> In general yes.
<tankf33der> ffi and coroutines - main porting issues like it should be
<abu[7]> Do you know if the stack really grows downwards as expected by Pil?
<tankf33der> I will try to google
<abu[7]> Or do a test in C
<abu[7]> char b[1] ... printf("%p\n", b) in
<abu[7]> different functions
<abu[7]> eg. in main() and a subfunction
<abu[7]> %p in the subfunction must be lower
<tankf33der> doing
<tankf33der> found this code in google
<tankf33der> and x64 and s390x returns: Stack grows downward
<abu[7]> Good news then!
<abu[7]> So it may be a minor issue
<tankf33der> smaller code
<tankf33der> (T . 0) is wrongly zero after yield in co
<abu[7]> Right
<abu[7]> Used all stack
<abu[7]> I try to find a possible reason a little later, now at an event
<tankf33der> sure. no hurry.
<tankf33der> afk.
ygrek has joined #picolisp
Iacob has quit [Quit: IRCNow and Forever!]
Iacob has joined #picolisp
<abu[7]> Hmm, hard to say. Seems indeed that the main stack segment T was overwritten.
<abu[7]> Cause (stack) says (T . 0)
<tankf33der> Eee
<abu[7]> Question is how this happens
bjorkintosh has quit [Ping timeout: 260 seconds]
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp