On Sun, 2001-09-16 at 14:26, Gregor N. Purdy wrote:
> Brian --
>
> > Its not going to work, if I understand it correctly. I tried doing it
> > (even set up the symbol '*' to mean the current PC) and do it, but it
> > seems the ops take a relative offset. Take jump_i, for example:
>
> Taking this into account, I modivied jump.pasm and fixed the offsets.
> I tested it this way...
>
> $ assemble.pl --output t/jump.pbc --listing t/jump.list t/jump.pasm
> $ test_prog t/jump.pbc
> Jump test.
> Jumping to subroutine...
> $ perl disassemble.pl t/jump.pbc
> ....
>
> I also did 'vi t/jump.list'. With these hard-coded relative offsets, I
> think the program should be producing the desired output, but it
> doesn't. If it did, I could do some tricks in jakoc and/or assemble.pl
> to create a pseudo-op for jumping to any label, and another for
> setting up the return-offset based on the end-label of the destination
> block and the label we want it to return to. It sure would be nice,
> though, to have a real 'absjump_i' opcode (really start-of-bytecode-
> relative rather than current-program-counter relative).
>
This won't be needed once jsr/ret become available. ret is (really) the
absjump_i you're looking for since its only purpose is to return to a
previous place. Everything else can be setup as relative to the PC.
> It would also be helpful to have jump_ic and absjump_ic, rather than
> having to load these things into registers.
You can use branch_ic for this. absjump is probably a bad idea since it
appears the return value of the opcode function is really a memory
address of the host machine. If an absolute value (relative to the
beginning of the opcode stream) was used, then it would have to be
relocated at load-time and wouldn't be able to remain read-only.
>
> Anyway, I'm attaching the revised jump.pasm example. Maybe I still
> don't have the offsets calculated right, but I stared at jump.list
> and the disassembly listing for a while and I *think* they are
> right.
>
> I wish I had a tracing mode where I could watch exactly where it
> was jumping to and what ops it was executing. I still wonder if
> somehow its jumping out of the bytecode and landing on an op zero
> (end). Jumping out of the bytecode *should* raise an error, though,
> no?
>
> If I'm not using this right, I sure would like to see an example of
> the correct use of jump_i...
I've not figured out what jump_i is for :) I suspect its for calculated
jumps (i.e. the switch statement) rather than for subroutines.
Overall, I think you're barking up the wrong tree. jsr/ret are for
subroutines. Your subroutine isn't going to work for more than one
caller, since the return offset is hardcoded, you might as well write
jump.pasm as:
MAIN: print "Jump test.\n"
print "Jumping to subroutine...\n"
branch SUB
RET: print "Returned from subroutine!\n"
end
SUB: print "Entered subroutine...\n"
branch RET
because the bytecodes dumped out are virtually identical.
We're going to have to wait for Dan (or, you could manually apply the
patch I posted earlier which adds a simple jsr/ret implementation)
Brian
