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
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
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
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 to
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 so
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
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
