> I think the confusion's because the jump opcode's broken. When you say > > jump 12 > > It should jump to absolute address 12, not 12 bytes/words/opcodes from the > current position.
i fixed that. but ther's only a jump_i, no jump_ic...
"jump Ix" now jumps to the absolute address held in a register Ix. Absolute means
start of the bytecode + Ix. the following code will result in a simple program
restart,
no core dump:
set I1, 0
jump I1
the fixed jump breaks the tests: basic5, call.pasm, jump.pasm
but i wonder why nobody realized that jump's broken, the doc says it jumps _to_
the address, not forward or backward........
-daniel
----- Original Message -----
From: "Dan Sugalski" <[EMAIL PROTECTED]>
Sent: Friday, October 12, 2001 4:23 AM
Subject: Re: Fetching the PC?
> At 09:12 PM 10/11/2001 -0500, Brian Wheeler wrote:
> >On Thu, 2001-10-11 at 20:49, Dan Sugalski wrote:
> > > At 08:25 PM 10/11/2001 -0500, Brian Wheeler wrote:
> > > >Since we're passing guilt around, there's an equate of '*' which is the
> > > >current PC...and I didn't document it. You can do
> > > > set I1,*
> > > >and it will set I1 to the current PC. It doesn't allow any math,
> > > >though. I thought about hooking up eval to various brackets but I never
> > > >got the time before my job got busy...
> > >
> > > Absolute or relative PC?
> >
> >Well, its relative to the start of the bytecode...which I suppose would
> >be absolute...unless multiple bytecode chunks are placed in the same
> >memory block, in which case it'd be relative. Now I'm confused. :)
>
> Absolute addresses are, well, absolute addresses. Relative addresses are
> offsets from the current location.
>
> I think the confusion's because the jump opcode's broken. When you say
>
> jump 12
>
> It should jump to absolute address 12, not 12 bytes/words/opcodes from the
> current position.
>
> > > >Though I like Gregor's way of doing it: we know the addresses (more or
> > > >less) at compile time, so we might as well not waste ops doing
> > > >arithmetic that we know in advance...
> > >
> > > Fair enough, though we don't really know the absolute PC at assembly time,
> > > as we're all position independent. Thinking further, having the getpc
> > > opcode take an offset would let us do something like:
> > >
> > > getpc I0, FOO
> > >
> > > to put the absolute address of FOO into I0, suitable for jumps and jsrs.
> > >
> >
> >This just comes out as a specialized add, right? In fact, isn't it
> >this:
> > set I0,*
> > inc I0,FOO <-- assuming the assembler knew that this is an address
>
> Yup. Only set doesn't take * as a parameter--it can't, because there's no
> way to know at assembly time what the real PC will be.
>
> >How are multiple bytecode chunks (i.e. libraries) going to be handled?
>
> They're just going to get mmapped in wherever the system puts 'em.
>
> >Are they going to be contiguous?
>
> Nope.
>
> >Are they going to be segmented somehow
> >so there's a "far jump" which takes us out of the current block?
>
> Nope. Jumps and jsrs take absolute addresses, so they can go anywhere.
> Branches are relative so fixing them up to bounce between segments would be
> tough, but we're not going to do that. :)
>
>
> Dan
>
> --------------------------------------"it's like this"-------------------
> Dan Sugalski even samurai
> [EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
>
jumpabs.patch
Description: Binary data
