At 12:20 PM 9/17/2001 -0400, Gregor N. Purdy wrote:
>Brian --
> > > 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.
This isn't actually a problem, as there are times we will want to return
absolute addresses. Granted they'll be fetched from some place and not
generated at compile time, but useful nonetheless. (For things like sub
entry points and such, where we're potentially jumping into other code regions)
>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.
Give me a bit. I'm ignoring e-mail (mostly) and getting a bunch of work
done. I'm getting the generic stack and jsr/ret stuff done in the
interstices between work. :)
> > Overall, I think you're barking up the wrong tree. jsr/ret are for
> > subroutines.
I should point out that these are assembly level subroutines, not Perl
level subroutines. There'll be a separate HLL sub call op/return pair.
>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.
You can recurse if you clone the register file at 'subroutine' entry.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
