Re: question about branching/returning
The internal do-op-loop runs until it sees a return value of zero from any op-codes. The RETURN statement within basic_opcodes.ops is really a keyword which gets parsed into an offset of the current PC counter based on the internally calculated size of the instruction (known at Configure time from opcode_table). Of course, this is based off my reverse engineering of existing code. I'm sure any of this is subject to change. As a note, another poster said that end is never executed which isn't currently true. -Michael Dave Storrs wrote: Ok, that was pretty much what I thought. But then what is the 'end' opcode for? It does a 'RETURN 0', which would increment the PC by 0 opcodes...which either counts as an infinite loop or a no-op, and we've already got a no-op op.
Re: question about branching/returning
On Wed, Sep 19, 2001 at 10:32:18PM -0700, Dave Storrs wrote: Ok, that was pretty much what I thought. But then what is the 'end' opcode for? It does a 'RETURN 0', which would increment the PC by 0 opcodes...which either counts as an infinite loop or a no-op, and we've already got a no-op op. RETURN(0) is special-cased by process_opcodes(); it returns a literal 0, not a relative address. As other people have noted, this is irrelevent, as end is never called. - Damien
Re: question about branching/returning
Simon --
But this still sucks:
while (code = code_start code (code_start + code_size) code-i) {
DO_OP(code, temp, func, interpreter);
}
Three tests and an addition each op. At the *very least*, we should store
code_end = code_start + code_size. And at best...
This:
while (code = code_start code (code_start+code_size) *code)
{ DO_OP(code, interpreter); }
should be the same as this:
IV code_end = code_start + code_size;
while (code = code_start code code_end *code)
{ DO_OP(code, interpreter); }
once the optimizer is through (disclaimer: IANAO).
DS The default dispatch loop shouldn't check. The Safe dispatch loop (note the
DS caps there... :) should check.
If we add:
#define PARROT_SAFE_FLAG 0x04 /* Watch bytecode block bounds */
to include/parrot/interpreter.h, then we could change the core runops
loop to look like this:
if (interpreter-flags PARROT_SAFE_FLAG) {
IV code_end = code_start + code_size; /* Nice and explicit */
while (code = code_start code code_end *code)
{ DO_OP(code, interpreter); }
}
else {
while (*code) { DO_OP(code, interpreter); }
}
But I don't know if that is on track with where folks want to head of
safe operation, or if this is a good way but should be called
something other than safe...
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc.http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_/
Re: question about branching/returning
At 10:22 PM 9/19/2001 -0700, Dave Storrs wrote: I'm working on documenting the opcodes, and I want to make sure that I understand the 'RETURN' code properly. I've poked around a little bit to see if I coudl figure it out, but I don't want to divert too much. Would someone please explain to me what each of the following does? RETURN 4 RETURN 0 RETURN -2 # Is this even legal? You've been filled in pretty well (yeah, the docs suck. Sorry... :) on what those should do. Please note that the jump opcode is currently broken. It returns an offset, when it should return an absolute address. (I'm trying to remember if I intended all the RETURNs to return absolute addresses or not) We need a separate RETURN_ABS or something to not do the offset, FWIW. Oh, and end is always op 0, and the oploop checks that, as you've seen. It has a function body anyway, just to be really sure. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: question about branching/returning
On Thu, 20 Sep 2001, Brent Dax wrote: Damien Neil: # RETURN(0); (written exactly like that, no variation permitted) # is a special case, and terminates the runops loop. The only op # which uses this is end, and it doesn't actually ever execute. # Personally, I feel that this special case should be removed. We should probably just check if the thing returned 0 and exit runops if that's the case. This will also protect us against utter stupidity like: FOO:jump FOO which wouldn't be a bad thing to protect against. To my understanding jump FOO would physically map to the c-code return code + code[1], which means the number zero is not returned, even thoughthe offset of FOO is zero bytes. (I'm away from the source code so I can't verify this, but it's what I remember) -Michael
RE: question about branching/returning
RETURN causes the program counter to be incremented by that many opcodes. So RETURN 4 would move forward 4 opcodes and RETURN -2 would move backward 2 opcodes. Basically, it returns a relative offset from the current position. -Original Message- From: Dave Storrs To: The Perl 6 Internals list Sent: 9/20/2001 12:22 AM Subject: question about branching/returning I'm working on documenting the opcodes, and I want to make sure that I understand the 'RETURN' code properly. I've poked around a little bit to see if I coudl figure it out, but I don't want to divert too much. Would someone please explain to me what each of the following does? RETURN 4 RETURN 0 RETURN -2 # Is this even legal? Thanks in advance, Dave
RE: question about branching/returning
Ok, that was pretty much what I thought. But then what is the 'end' opcode for? It does a 'RETURN 0', which would increment the PC by 0 opcodes...which either counts as an infinite loop or a no-op, and we've already got a no-op op. Dave On Thu, 20 Sep 2001, Gibbs Tanton - tgibbs wrote: RETURN causes the program counter to be incremented by that many opcodes. So RETURN 4 would move forward 4 opcodes and RETURN -2 would move backward 2 opcodes. Basically, it returns a relative offset from the current position.
Re: question about branching/returning
On Wed, Sep 19, 2001 at 10:32:18PM -0700, Dave Storrs wrote: Ok, that was pretty much what I thought. But then what is the 'end' opcode for? It does a 'RETURN 0', which would increment the PC by 0 opcodes...which either counts as an infinite loop or a no-op, and we've already got a no-op op. end *ought* to break the loop. Whoever rewrote the op loop to keep going until the end of the bytecode stream didn't think of that. :) -- Um. There is no David conspiracy. Definitely not. No Kate conspiracy either. No. No, there is definitely not any sort of David conspiracy, and we are definitely *not* in league with the Kate conspiracy. Who doesn't exist. And nor does the David conspiracy. No. No conspiracies here. - Thorfinn, ASR
Re: question about branching/returning
Well, I'm in the process of fiddling with this stuff anyway...what do you want me to make it do? Dave On Thu, 20 Sep 2001, Simon Cozens wrote: On Wed, Sep 19, 2001 at 10:32:18PM -0700, Dave Storrs wrote: Ok, that was pretty much what I thought. But then what is the 'end' opcode for? It does a 'RETURN 0', which would increment the PC by 0 opcodes...which either counts as an infinite loop or a no-op, and we've already got a no-op op. end *ought* to break the loop. Whoever rewrote the op loop to keep going until the end of the bytecode stream didn't think of that. :) -- Um. There is no David conspiracy. Definitely not. No Kate conspiracy either. No. No, there is definitely not any sort of David conspiracy, and we are definitely *not* in league with the Kate conspiracy. Who doesn't exist. And nor does the David conspiracy. No. No conspiracies here. - Thorfinn, ASR
Re: question about branching/returning
On Wed, Sep 19, 2001 at 10:47:44PM -0700, Dave Storrs wrote:
Well, I'm in the process of fiddling with this stuff anyway...what do you
want me to make it do?
Oh, sorry, I see what happens. The last test (code-i) is what I would think
of as *code: it tests whether we're sitting on an end op, zero. The end
function itself is probably never called.
But this still sucks:
while (code = code_start code (code_start + code_size) code-i) {
DO_OP(code, temp, func, interpreter);
}
Three tests and an addition each op. At the *very least*, we should store
code_end = code_start + code_size. And at best...
DS The default dispatch loop shouldn't check. The Safe dispatch loop (note the
DS caps there... :) should check.
--
User: In 1793 the french king was executed.
MegaHAL: HA HA HA! CORRECT. ALTHOUGH, EXECUTED HAS MULTIPLE MEANINGS.
RE: question about branching/returning
First, code-i doesn't exist anymore...it is back to being *code (much more
readable that way :)
Second, we are going to remove those safety checks on that version of runops
if I'm not mistaken, I just don't think anyone's gotten around to it yet.
-Original Message-
From: Simon Cozens
To: Dave Storrs
Cc: 'The Perl 6 Internals list '
Sent: 9/20/2001 12:53 AM
Subject: Re: question about branching/returning
On Wed, Sep 19, 2001 at 10:47:44PM -0700, Dave Storrs wrote:
Well, I'm in the process of fiddling with this stuff anyway...what do
you
want me to make it do?
Oh, sorry, I see what happens. The last test (code-i) is what I would
think
of as *code: it tests whether we're sitting on an end op, zero. The
end
function itself is probably never called.
But this still sucks:
while (code = code_start code (code_start + code_size)
code-i) {
DO_OP(code, temp, func, interpreter);
}
Three tests and an addition each op. At the *very least*, we should
store
code_end = code_start + code_size. And at best...
DS The default dispatch loop shouldn't check. The Safe dispatch loop
(note the
DS caps there... :) should check.
--
User: In 1793 the french king was executed.
MegaHAL: HA HA HA! CORRECT. ALTHOUGH, EXECUTED HAS MULTIPLE MEANINGS.
