Re: Transferring control between code segments, eval, and suchlike things

2003-01-24 Thread Nicholas Clark
On Thu, Jan 23, 2003 at 12:11:20AM -0500, Dan Sugalski wrote: > Every sub doesn't have to fit in a single segment, though. There may > well be a half-zillion subs in any one segment. (Though one segment > per sub does give us some interesting possibilities for GCing unused > code) For an inter

Re: Transferring control between code segments, eval, and suchlike things

2003-01-23 Thread Juergen Boemmels
Dan Sugalski <[EMAIL PROTECTED]> writes: > Okay, since this has all come up, here's the scoop from a design perspective. > > First, the branch opcodes (branch, bsr, and the conditionals) are all > meant for movement within a segment of bytecode. They are *not* > supposed to leave a segment. To do

Re: Transferring control between code segments, eval, and suchlike things

2003-01-23 Thread Jason Gloudon
On Wed, Jan 22, 2003 at 03:00:37PM -0500, Dan Sugalski wrote: > Destinations. These are a pain, since if we can go anywhere then the > JIT has to do all sorts of nasty and unpleasant things to compensate, > and to make every op a valid destination. Yuck. Arbitrary jumps are not that difficult t

Re: Transferring control between code segments, eval, and suchlike things

2003-01-23 Thread Leopold Toetsch
Benjamin Stuhl wrote: At 03:00 PM 1/22/2003 -0500, you wrote: ... Although, all this would seem to suggest that we'd need/want a special-purpose allocator for bytecode segments, since every sub has to fit within precisely one segment (and I know _I'd_ like to keep bytecode segments on their

Re: Transferring control between code segments, eval, and suchlike things

2003-01-23 Thread Leopold Toetsch
Dan Sugalski wrote: Okay, since this has all come up, here's the scoop from a design perspective. Hard stuff did meet my printer at midnight, reading it onscreen twice didn't help ;-) First: Definition #0: A bytecode segment is a sequence of code, which is loaded into memory with no execut

Re: Transferring control between code segments, eval, and suchlike things

2003-01-22 Thread Dan Sugalski
At 6:24 PM -0500 1/22/03, Benjamin Stuhl wrote: At 03:00 PM 1/22/2003 -0500, you wrote: Okay, since this has all come up, here's the scoop from a design perspective. First, the branch opcodes (branch, bsr, and the conditionals) are all meant for movement within a segment of bytecode. They are *

Re: Transferring control between code segments, eval, and suchlike things

2003-01-22 Thread Benjamin Stuhl
At 03:00 PM 1/22/2003 -0500, you wrote: Okay, since this has all come up, here's the scoop from a design perspective. First, the branch opcodes (branch, bsr, and the conditionals) are all meant for movement within a segment of bytecode. They are *not* supposed to leave a segment. To do so was a

Transferring control between code segments, eval, and suchlike things

2003-01-22 Thread Dan Sugalski
Okay, since this has all come up, here's the scoop from a design perspective. First, the branch opcodes (branch, bsr, and the conditionals) are all meant for movement within a segment of bytecode. They are *not* supposed to leave a segment. To do so was arguably a bad idea, now it's officially