Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.lang.forth Subject: Re: setjmp/longjmp vs. CATCH/THROW Message-ID: Date: 7 Jul 90 00:16:50 GMT References: <9007062100.AA05671@ucbvax.Berkeley.EDU> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 39 In article <9007062100.AA05671@ucbvax.Berkeley.EDU> wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV writes: > > You can push the jmp_buf on the return stack. > You can do so if you happen to know how many return stack cells are > necessary to hold the information in jmp_buf. True. You also need to know this to allocate a jmp_buf, so it's reasonable to assume you know it or can find out: HERE allocate jmp_buf HERE SWAP - CONSTANT JMP_BUF_SIZE > Which brings up the > other obvious problem with using the return stack in this fashion; it > "partitions" the return stack in the middle of a definition, Since you're doing it to implement catch/throw you can assume that this is a reasonable assumption. > CATCH/THROW avoids this partitioning effect by making the return stack > effects occur at a procedure boundary, where the return stack details > are already hidden from a standard program. But you can't use CATCH and THROW to (for example) implement coroutines. This does require knowing what's inside a JMP_BUF, I admit, but that's probably manageable: addr JMP_BUF !STACK_BASE addr JMP_BUF !RSTACK_BASE int JMP_BUF !STACK_SIZE int JMP_BUF !RSTACK_SIZE addr JMP_BUF !IP JMP_BUF longjmp This is forth. If you want a language like lisp with no interesting bits, I'd say go with lisp. For forth you should choose the mechanism with the greatest amount of flexibility. Ten years ago I did this both ways, and jmp_buf was the clear winner. -- Peter da Silva. `-_-' +1 713 274 5180.