Re: Are PicoLisp's coroutine stacks legal?
Hi, I can only say that under AmigaOS it would certainly be a no-no: http://wiki.amigaos.net/index.php/Exec_Tasks#Task_Exceptions When an exception occurs, Exec stops executing the tasks normal code and jumps immediately into the exception routine, no matter what the task was doing. The exception routine operates in the same context the task's normal code; it operates in the CPU's user mode and uses the task's stack. http://wiki.amigaos.net/index.php/Exec_Tasks#Task_Stack Task stacks are normally used to store local variables, subroutine return addresses, and saved register values. Additionally, when a task loses the processor, all of its current registers are preserved on this stack (with the exception of the stack pointer itself, which must be saved in the task structure). On May 20, 2013, at 6:43 PM, Alexander Burger a...@software-lab.de wrote: Hi all, since nearly three years PicoLisp supports coroutines (64-bit version). Now suddenly it occurred to me that the way I implemented them might be illegal. The problem is how individual stacks for the coroutines are allocated. I do this by reserving space on the stack (by decrementing the stack pointer) upon starting a new coroutine. Execution of that coroutine may be suspended (with 'yield', so that execution continues in the main program or some other coroutine), to be resumed later. Switching between individual (co)routines is done by moving the stack pointer up and down between the corresponding stack frames. Everything seems to work fine - though I haven't used coroutines in serious projects yet. Now I remember to have read that (in POSIX?) no valid data should be stored *below* the current position of the stack pointer. Is that really the case? I can't find any conclusive information about that. This switching between stack frames, as described above, of course leaves temporarily suspended stack frames *below* the stack pointer, while it points into a higher frame. Does this mean that the operating system might dispose or overwrite them? For example, when paging is required? Interrupts are probably not a problem, as they push their contexts on the system stack. Some sources say that even GCC stores (small amounts of) data below the stack pointer, while others (possibly some ABIs from Intel) say this is an absolute no-no. Can anybody point to a definite answer? ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Are PicoLisp's coroutine stacks legal?
Hi, On May 21, 2013, at 6:56 AM, Alexander Burger a...@software-lab.de wrote: They talk about task stacks and preserved on this stack. I assume that these stacks all reside on the single hardware stack, right? So there is a stack *frame* for each task, and this frame might also be used to save exception context. That's all right. Each task has a different stack using a single user-mode stack pointer. In Amiga there is no memory protection, a context switch just involves saving the registers in the stack, saving the stack pointer itself in the stack structure, restoring the stack pointer of the next task and returning to it in a way that restores the registers. It seems not forbidden, however, to allocate several frames below each other, where the active stack pointer points into some upper frame, right? That's the problem I'm talking about. I thought you were talking about micro stacks. If your stacks are 1 Mb I guess there won't be any problem. If at some point you face problems on a system that happens to unmap stack pages (I doubt it), you can probably workaround it by marking the stack pages with mlock() or similar. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Are PicoLisp's coroutine stacks legal?
Hi, On May 21, 2013, at 7:46 AM, Alexander Burger a...@software-lab.de wrote: The big question is: Will the system (which system?) do that? If so, how do other languages implement green threads, coroutines or continuations? Some OSs do provide the required functionality (e.g, the fibers API on Windows). On POSIX, it's usually a matter of using some dirty hack (setjmp()/longjmp() being the most portable, swapcontext() is also quite popular). When working in embedded/mobile I have seen a couple of platforms with broken setjmp()/longjmp() implementations, so that can also be troublesome. The problem is so complex that perhaps your approach is the simplest. Just take a look at how nasty the thing can get: http://code.google.com/p/libaw/source/browse/coroutine/source/Coro.c Regards, Jorge-- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Quick try at building 64-bit on OSX 10.8.3
I tried to build the emu version on OSX and it failed. Here is the culprit line: emu.patch Description: Binary data Regards, Jorge On May 22, 2013, at 5:24 PM, Alexander Burger a...@software-lab.de wrote: Hi Jon, to see if something magical have happened that would make it possible for me to build 64-bit PicoLisp, so I did the (cd src64; ... runtime. As I'm not very convinced that such a Java SE 6 runtime would give me the 64-bit PicoLisp, I have not accepted that offer yet. Am I wrong? ;-) If you install Java, you can cross-assemble PicoLisp via ErsatzLisp. This is usually not necessary, because you might as well download the pre-assembled '*.s'-files. BUT: In case of the Mac, both approaches won't work, as the Mac's a.out-format is still not supported (you know .. ye old problems). So better don't install Java ;-) ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Quick try at building 64-bit on OSX 10.8.3
On May 22, 2013, at 8:19 PM, Alexander Burger a...@software-lab.de wrote: Hi Jorge, I tried to build the emu version on OSX and it failed. Here is the culprit line: Thanks! Unfortunately, it is not so easy, because then you get a warning on 32-bit systems: cast from pointer to integer of different size [-Wpointer-to-int-cast] So for 32-bits, we must still first cast to an uint32_t. I'd say we change it to: ... (p (if *Bits64 (_genCC A.n = (uint64_t)(uint8_t*)@1(@2);@3) (_genCC A.n = (uint64_t)(uint32_t)(uint8_t*)@1(@2);@3) ) ) ... Does this work for you? If so, I'll put it into the release. Ok, if that's the problem this is nicer… Does it compile without warnings on your 32-bit system? emu2.patch Description: Binary data
Re: Quick try at building 64-bit on OSX 10.8.3
Hi, A quick question, what's the status of the *FPic variant on Linux? Is it working? If it works properly, I guess I could get it running on OSX as well when I find some spare time...-- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Quick try at building 64-bit on OSX 10.8.3
Hi Alex, On May 24, 2013, at 10:49 AM, Alexander Burger a...@software-lab.de wrote: If it works properly, I guess I could get it running on OSX as well when I find some spare time...-- That would be great! I must say that I gave up on that, see e.g. http://www.mail-archive.com/picolisp@software-lab.de/msg03816.html Well, x64 sucks, no surprise here, but not as much as x86. Perhaps a good strategy here would be to use one of the C calling registers (%r9 for instance) as a preloaded NIL. Restoring that value after calling C shouldn't be much of a problem and would probably make code cleaner and faster. I've done some preliminary experiments with that and it looks promising. What do you think of such approach? -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Missing o in -lcrypt in scr/Makefile
On May 24, 2013, at 4:11 PM, Alexander Burger a...@software-lab.de wrote: Hi Jon, I believe there is a missing o at the end of line 104 in the current scr/Makefile. Adding the o to make it -lcrypto helped me build 32-bit PicoLisp, v. 3.1.2.9 C (on Mac OS X 10.8.3). Under Linux it is -lcrypt (according to the man page of crypt(3)). Seems we must make src/Makefile aware of the OS-depenencies again :( There's another option, embedding a libcrypt in picolisp sources. Dealing with changes upstream is always a pain, but OpenBSD's could be a good option. According to the CVS logs it seems quite stable. Didn't try to build it though. http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/ -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Quick try at building 64-bit on OSX 10.8.3
On May 25, 2013, at 9:22 AM, Alexander Burger a...@software-lab.de wrote: HI Jorge, Well, x64 sucks, no surprise here, but not as much as x86. Perhaps a good strategy here would be to use one of the C calling registers (%r9 for instance) as a preloaded NIL. Restoring that value after calling C Surely %r9 could be freed for general purposes. I don't remember if that would solve any problem. Why do you think of NIL especially? You're right, upon deeper inspection it seems it doesn't solve any problem, it just postpones it. -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: REPL and OpenGL
A couple of options: - Use coroutines and yield control to the main thread in the glutIdleFunc. - Use a library that doesn't take control of the main loop. I can think of mine ( http://code.google.com/p/libaw/ ) and GLFW ( http://www.glfw.org ). On May 28, 2013, at 10:57 AM, Oskar Wieland oskar.wiel...@gmx.de wrote: Hi, I'm trying to create an OpenGL window without loosing control to the glutMainLoop. Thus I added the following definition from glut to OpenGL: : (de glutMainLoopEvent () (native `*GlutLib glutMainLoopEvent) ) I set up some kind of main loop: : (mouseFunc '((Btn State X Y) (setq _run NIL))) # Exit upon mouse click : (de go () (setq _run T)(while _run (glutMainLoopEvent))) Is there a function to keep the REPL in the console alive, like (de go () (setq _run T)(while _run (glutMainLoopEvent DO_THE_REPL))) or is there another (better) way to create a OpenGL window without loosing control to glutMainLoop? Oskar -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Problems with 'call'
On May 29, 2013, at 7:05 PM, Thorsten Jolitz tjol...@gmail.com wrote: - the variable is set and known to BASH, but somehow PicoLisp does not know about it: Did you export it? (export FOO=x instead of just FOO=x) -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Regarding the implementations of PicoLisp
On 13 May 2014, at 07:06, Alexander Burger a...@software-lab.de wrote:
Basically you are implementing you own malloc(), which is still far away
from a single-instruction push, pop or stack arithmetic.
Am I missing something? alloca() just adds an offset to the stack pointer:
#include stdlib.h
extern void foo(void *);
void test() {
foo(alloca(100));
}
bash-3.2$ cc -fomit-frame-pointer -fno-stack-protector -c -O3 test.c
bash-3.2$ otool -tV test.o
test.o:
(__TEXT,__text) section
_test:
subq$0x68, %rsp
0004leaq0x4(%rsp), %rdi
0009callq _foo
000eaddq$0x68, %rsp
0012ret
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Solved: Tell mechanism issue (perhaps OT)
I’m getting pids well above 64k on my laptop (OS X). On 06 Aug 2014, at 22:33, Alexander Burger a...@software-lab.de wrote: Hi Randall, I believe that modern Linux and FreeBSD implementations use 32 bit ints for the pid_t. Right. There will never be that many processes on a 32 bit OS, but since they just go forward until they wrap, getting a pid bigger than 16 bits is probably even to be expected. However, they don't plainly wrap. There is a system limit in the kernel, controlled via /proc/sys/kernel/pid_max. Even on 64-bit machines (where pid_t is also an 'int', i.e. a 64-bit number), PIDs don't get up to such huge numbers. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Solved: Tell mechanism issue (perhaps OT)
It’s a 64bit 8 GB machine. BSDs work differently: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/basics-processeshtml Maximum seems to be 9, at least on FreeBSD. On 06 Aug 2014, at 23:09, Henrik Sarvell hsarv...@gmail.com wrote: Hi Jorge, how much RAM does it have, is it a 64bit machine? I have checked the number Alex mentioned on some of our servers, all running Ubuntu 12.04, servers below 64GB RAM have that number set to 32768 per default, machines with 128GB got 98304. On Thu, Aug 7, 2014 at 12:49 PM, Jorge Acereda Maciá jacer...@gmail.com wrote: I’m getting pids well above 64k on my laptop (OS X). On 06 Aug 2014, at 22:33, Alexander Burger a...@software-lab.de wrote: Hi Randall, I believe that modern Linux and FreeBSD implementations use 32 bit ints for the pid_t. Right. There will never be that many processes on a 32 bit OS, but since they just go forward until they wrap, getting a pid bigger than 16 bits is probably even to be expected. However, they don't plainly wrap. There is a system limit in the kernel, controlled via /proc/sys/kernel/pid_max. Even on 64-bit machines (where pid_t is also an 'int', i.e. a 64-bit number), PIDs don't get up to such huge numbers. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Solved: Tell mechanism issue (perhaps OT)
Oh, you mean the 32 bit version of pico lisp? Thats right… On 06 Aug 2014, at 23:23, Jorge Acereda Maciá jacer...@gmail.com wrote: It’s a 64bit 8 GB machine. BSDs work differently: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/basics-processeshtml Maximum seems to be 9, at least on FreeBSD. On 06 Aug 2014, at 23:09, Henrik Sarvell hsarv...@gmail.com wrote: Hi Jorge, how much RAM does it have, is it a 64bit machine? I have checked the number Alex mentioned on some of our servers, all running Ubuntu 12.04, servers below 64GB RAM have that number set to 32768 per default, machines with 128GB got 98304. On Thu, Aug 7, 2014 at 12:49 PM, Jorge Acereda Maciá jacer...@gmail.com wrote: I’m getting pids well above 64k on my laptop (OS X). On 06 Aug 2014, at 22:33, Alexander Burger a...@software-lab.de wrote: Hi Randall, I believe that modern Linux and FreeBSD implementations use 32 bit ints for the pid_t. Right. There will never be that many processes on a 32 bit OS, but since they just go forward until they wrap, getting a pid bigger than 16 bits is probably even to be expected. However, they don't plainly wrap. There is a system limit in the kernel, controlled via /proc/sys/kernel/pid_max. Even on 64-bit machines (where pid_t is also an 'int', i.e. a 64-bit number), PIDs don't get up to such huge numbers. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
