On Mon, 2001-09-17 at 11:20, Gregor N. Purdy wrote:
>
> I agree that jsr/ret are what I really want, but I'm dying to play
> with baby subroutines in jako, and I think I could play enough games
> with a properly understood jump_i and some assembler magic to make
> them work. I now have jump.pasm working right (the key was to think
> in terms of word offsets, not byte offsets).
:) I think I read somewhere that impatience was a good thing...
>
> > > 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.
>
> My mental model for this thing is "Parrot is a CPU architecture" and
> a lot of what I'm trying to make it do is behave as much as possible
> in that way. So, if we are talking about a CPU architecture (ISA),
> lacking the full complement of relative and absolute jumps, register
> and constant comparisons, etc. is a bummer.
I think we're ok on relative ops, but you're right, we're short of
absolute.
>
> Mucking with things like memory addresses of host machines, etc. is
> important, but only at the interpreter level, not at the ISA design
> level (IMHO).
>
> I don't see a relocation issue anyway, since the way I look at the
> interpreter code is:
>
> PC === (code - start_code)
>
> So if an instruction says "absjump 43", then I know that I need
> to do:
>
> code = (start_code + 43)
>
> and if an instruction says "(rel)jump 43" then I know that I need
> to do:
>
> code += 43
>
> neither of these is a problem in my eyes.
>
Ok, they're not really problems, per se, but the way the interpreter is
constructed, the ops *always* return the offset to the next PC.
> > 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:
>
> Not quite. First, recall jump.pasm (attached). It does work now that
> I've got the offsets correct. Now, there is nothing to stop us from
> moving the setting of I2 to earlier (jump2.pasm, attached). With
> appropriate labels and address arithmetic (jump3.pasm, attached) it
> is even almost readable.
>
> Now, if we also have good macros and '* == PC' and calculated labels,
> we can have some real fun (jump4.pasm, attached).
>
Ok, fair enough. I've implemented '*' as the PC in the assembler. I've
not done macros yet, but I remember seeing a patch somewhere.
> Of course, this doesn't allow us to do recursion, wastes registers,
> etc. But, it would allow me to play with the syntax of the language
> with a simple implementation until cooler ops are available.
>
:) there are real architectures that couldn't (easily, if at all) do
recursion. I think the PDP-8 was one of them.
> > 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)
>
> Probably it would be best to wait. But my Impatience is showing...
>
Like I said...I think I've heard its a good thing :)
Brian
