Re: [PATCH] Bytecode bounds checking and TRACE_OPS

2001-09-17 Thread Gregor N. Purdy
Dan -- > While I'm not fond of segfaults myself, the place to check isn't in the > interpreter loop. It's not unwarranted in assuming that it's told to go OK > places. If we want to check the better place is inside the jump ops. I'm in agreement, although we still need to watch out for falling

Re: [PATCH] Bytecode bounds checking and TRACE_OPS

2001-09-17 Thread Dan Sugalski
At 03:53 PM 9/17/2001 +0100, Simon Cozens wrote: >On Mon, Sep 17, 2001 at 11:01:32AM -0400, Dan Sugalski wrote: > > While I'm not fond of segfaults myself, the place to check isn't in the > > interpreter loop. > >My view is that if you screw up writing assembly code, you should be >thankful that y

Re: [PATCH] Bytecode bounds checking and TRACE_OPS

2001-09-17 Thread Dan Sugalski
At 11:02 AM 9/17/2001 -0400, Gregor N. Purdy wrote: >Dan -- > > Also, we're trying to keep the stuff in the loop to a minimum, so for this > > I'd rather have a separate runops function, as well as having the actual > > funky stuff in the body separated out. (I'd really like it abstracted out > >

Re: [PATCH] Bytecode bounds checking and TRACE_OPS

2001-09-17 Thread Simon Cozens
On Mon, Sep 17, 2001 at 11:01:32AM -0400, Dan Sugalski wrote: > While I'm not fond of segfaults myself, the place to check isn't in the > interpreter loop. My view is that if you screw up writing assembly code, you should be thankful that you get the protection of a segfault. Same happens if y

Re: [PATCH] Bytecode bounds checking and TRACE_OPS

2001-09-17 Thread Gregor N. Purdy
Dan -- > The big one is you shouldn't assume that we are only going to have a single > chunk of bytecode--we may well have several loaded from disk, and more > created on the fly by eval/do/dynamic recompilation. Yeah. It seems we should have a parrot_bytecode structure that keeps the pointer

Re: [PATCH] Bytecode bounds checking and TRACE_OPS

2001-09-17 Thread Dan Sugalski
At 10:58 AM 9/17/2001 -0400, Gregor N. Purdy wrote: >Nor do I. Note that the checks themselves are about as cheap as they >*can* be, though. And I think that not checking is dangerous. I *did* >get some segfaults when I was working on the jump_i example. Just try >running blamo.pasm (attached) on

Re: [PATCH] Bytecode bounds checking and TRACE_OPS

2001-09-17 Thread Gregor N. Purdy
Simon -- > On Mon, Sep 17, 2001 at 10:33:35AM -0400, Gregor N. Purdy wrote: > > as *word* counts not *byte* counts -- D'Oh!) > > Isn't assembly programming fun? :) Woo-hoo! > > */ > > > > static int > > -check_magic(void** program_code) { > > +check_magic(void** program_code, long* program

Re: [PATCH] Bytecode bounds checking and TRACE_OPS

2001-09-17 Thread Simon Cozens
On Mon, Sep 17, 2001 at 10:33:35AM -0400, Gregor N. Purdy wrote: > as *word* counts not *byte* counts -- D'Oh!) Isn't assembly programming fun? :) > */ > > static int > -check_magic(void** program_code) { > +check_magic(void** program_code, long* program_size) { > +program_size -= sizeof

Re: [PATCH] Bytecode bounds checking and TRACE_OPS

2001-09-17 Thread Dan Sugalski
At 10:33 AM 9/17/2001 -0400, Gregor N. Purdy wrote: >Any thoughts? The big one is you shouldn't assume that we are only going to have a single chunk of bytecode--we may well have several loaded from disk, and more created on the fly by eval/do/dynamic recompilation. Also, we're trying to keep

[PATCH] Bytecode bounds checking and TRACE_OPS

2001-09-17 Thread Gregor N. Purdy
All -- While I was working on understanding jump_i, I was wishing I could see a trace of where the PC was going and what it was executing. (BTW, the jump.pasm test works now that I hard-coded the offsets as *word* counts not *byte* counts -- D'Oh!) I was also concerned that even though I was pro