develooper Front page | perl.perl6.internals | Postings from October 2001

Re: Fetching the PC?

Thread Previous | Thread Next
From:
Dan Sugalski
Date:
October 11, 2001 19:23
Subject:
Re: Fetching the PC?
Message ID:
5.1.0.14.2.20011011221853.023bace0@pop.sidhe.org
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
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About