Argh, my mailer crashed as I sent this, so I don't know if it went out.
On Thu, 2001-10-11 at 21:23, Dan Sugalski wrote:
> 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.
>
Ok, fair enough...but should it be jumping to:
(char *)byte_code+12
or
(char *)12
If its the former, it seems there will be some problems jumping to other
bytecode blocks, and if its the latter, at the very least someone can do
a "jump 0" and coredump the process.
I could be missing stuff, because I've not had a chance to review the
changes over the last few weeks....
> > > >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.
>
Yeah, I thought about that afterwards (the condition where real PC is
actually a memory address)
> >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. :)
>
>
Fair enough :)
Brian
> Dan
>
> --------------------------------------"it's like
this"-------------------
> Dan Sugalski even samurai
> [EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
