Message-Id: <200508160224.j7G2OlmV019735@delorie.com> Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Gary R. Van Sickle" To: Subject: RE: Cygwin.dll crash, alloca and custom stack Date: Mon, 15 Aug 2005 21:24:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <602EF4562299D711978800065BEECE9A0D2D30D3@cbrml50.ag.gov.au> X-IsSubscribed: yes > From: "Gary R. Van Sickle wrote: > >In the post you're replying to, I listed the legitimate reasons for > >wanting to do it. Here they are again: > > > >- If you're writing a task switcher. > > And what's the difference between a task switcher and > switching between co-routines? You seem to already have all the answers you ostensibly came here to seek, so I expect you'll be answering that question for me. > Basically nothing at all My expectation has been fulfilled. > except that a task gets switched whenever the OS wants to, > whereas a co-routine gets switched under program control. Really? So these "coroutines" are totally under the Scheme programmer's control, the OS has nothing to do with them, but if I, say, spawn a thread, it's off to never-never land and I have no control over it? > So > why must they be implemented differently? I guess they musn't. As you've already figured out, you should use the platform's existing task switching facilities to implement these coroutines, and drop this silly notion of manhandling esp. > It's nothing new to > be writing user space task switchers that switch stacks, When was the last time you did it on either Windows or Linux with gcc? > I > see no reason why a user space co-routine switcher should not > do the same. > That's because you're looking the other way. > >Do you actually realize that there are far better ways to implement > >stacks for interpreters than dinking with esp? > > I realise there are a dozen ways to suck eggs. I thought your goal was to write a Scheme interpreter with as little pain as possible. > But do YOU > realise If I do, I don't care. I'm not the one who came here for help and then became belligerent when it was offered. > that there > > are two ways to implement a language with co-routines, > whether it be interpreted or compiled, and that is to either > have a vm with a fake stack, or to use the machine's real > stack. Or to spawn the coroutine as a thread (or fiber) as Chris Faylor pointed out, and let the OS and CRT operate as they were designed to operate. > And if you use the machine's real stack you MUST > "dink" with esp. You MUST. Then you'd better not use the machine's real stack. > I don't happen to be writing a VM > based interpreter with a fake stack. > Chris, you're so wildly out in left field on this no-brainer issue that there's no way you'll be writing any sort of interpreter. > >I suggest you investigate those alternatives instead of trying to do > >something that cannot work, and then getting all pissy when > people try > to > >dissuade you from wasting your time. > > That's strange. Now that I know that on Windows it likes to > use its own stack for system calls, its working fine by just > restoring the system stack temporarily. I can switch stacks > and co-routines with no problems at all. So much for your > bogus "cannot work". I guess you don't know everything after > all huh? I guess it is in fact you who knows all. I stand humbled, and hope that your esp-mangling-via-gcc-asm()-statements Scheme interpreter works as well tomorrow as it did today. > I do remain curious why Windows actually cares > whereas Linux acts sensibly and doesn't carebut it matters > little for my purposes. > ...until something goes wrong, which it will, and you can't figure out why. But I guess you can be assured that it has nothing whatsoever to do with manhandling esp, so you have that going for you, which is nice. > >No, but there is a law that you have to learn to walk before > you can run. > >You are trying to sprint a marathon before you're even able > to stand erect. > > > Meaningless ad-hominem. You refuse to acknowledge that C has a runtime. There was nothing meaningless about that ad-hominem, Mr. Sees-An-Insult-Under-Every-Metaphor. > I guess now that I've got it working, > if I can't stand erect, you must not even be crawling. > "SNAP!", as the kids say these days. > >Christopher Faylor dot com> wrote: > >What you are trying to do is a bad idea. > > Bad huh? I'm fuzzy on the whole good/bad thing. Care to elaborate? > Dinking with esp via asm() statements: bad. Combining replies to two different posts into one: bad. Learning how to write code that at least has a fighting chance of not being a disaster: good. > >Btw, have you thought about how to handle stack overflow? > What happens > >when the program pushes its way to the top of your malloced region? > > Each Scheme function call has its own environment that is > chained to previous environments. Each environment has its > own stack. The C code that executes a scheme function uses a > small and well-defined amount of stack. > Restoring the system stack for external library calls is > going to be a good idea anyway, because they can use > arbitrary amounts of stack. Wow. Yeah, well, I guess that is technically on the list of reasons not to be screwing around with your stack pointer in C code, somewhere down around #431. > But for the interpreter itself > the exact amount of stack required for one lambda can be > calculated by trial and error. The other way to implement it > is to copy the entire stack when switching co-routines, but > I'm trying to avoid that. Hear me now and believe me later: this project is way beyond your abilities and experience, and your "Only help me if you're going to tell me I'm doing things the right way" attitude puts the final nail in this project's coffin. If you wish to succeed in writing a C program, don't even think about "asm()" for several more years. And don't worry: there's plenty of problems to be had without having to invoke "asm()". -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/