Hey all.
I know it's a little (OK, a lot) early for this, but has anybody
considered writing support for parrot bytecode and the parrot object
format into GNU binutils?
If you don't use some features of the VM (specificly, PMC and String
registers, destroying push), it isn't that different f
On Friday 12 October 2001 05:35 pm, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > I see we don't have push-with-copy ops for the various register files. I
> > think I'll go fix that.
>
> Bryan Warnock posted a patch to add those on Mon
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I see we don't have push-with-copy ops for the various register files. I
> think I'll go fix that.
Bryan Warnock posted a patch to add those on Monday but it doesn't
seem to have been committed...
The message is
At 04:20 PM 10/12/2001 -0500, Brian Wheeler wrote:
>On Fri, 2001-10-12 at 16:04, Dan Sugalski wrote:
> > At 04:00 PM 10/12/2001 -0500, Brian Wheeler wrote:
> > >On Fri, 2001-10-12 at 15:45, Dan Sugalski wrote:
> > > > At 03:50 PM 10/12/2001 -0500, Brian Wheeler wrote:
> > > > >Neat-o, but I do hav
On Fri, 2001-10-12 at 16:04, Dan Sugalski wrote:
> At 04:00 PM 10/12/2001 -0500, Brian Wheeler wrote:
> >On Fri, 2001-10-12 at 15:45, Dan Sugalski wrote:
> > > At 03:50 PM 10/12/2001 -0500, Brian Wheeler wrote:
> > > >Neat-o, but I do have a question... how do I pass parameters to
> > > >recursive
At 04:00 PM 10/12/2001 -0500, Brian Wheeler wrote:
>On Fri, 2001-10-12 at 15:45, Dan Sugalski wrote:
> > At 03:50 PM 10/12/2001 -0500, Brian Wheeler wrote:
> > >Neat-o, but I do have a question... how do I pass parameters to
> > >recursive subroutines, and/or save registers and not clobber the
> >
At 03:50 PM 10/12/2001 -0500, Brian Wheeler wrote:
>Neat-o, but I do have a question... how do I pass parameters to
>recursive subroutines, and/or save registers and not clobber the
>caller's?
Ah, this doesn't get into that. I'm still not sure what the calling
conventions will be.
I see we don'
At 04:28 PM 10/12/2001 -0400, Gregor N. Purdy wrote:
>Michael --
>
> > I'm of the opinion that you shouldn't just be able to jump into
> > another code-segment.
>
>I agree.
That's fine. I don't. :)
>Since in the future, different chunks of code could be
>compiled with different oplibs, the opfun
Neat-o, but I do have a question... how do I pass parameters to
recursive subroutines, and/or save registers and not clobber the
caller's?
Here's a factorial program I wrote:
### Compute the factorial recursively
### based on the scheme classic:
### (define fact (lambda(n) (if (= 1 n) 1 (
Michael --
> I'm of the opinion that you shouldn't just be able to jump into
> another code-segment.
I agree. Since in the future, different chunks of code could be
compiled with different oplibs, the opfunc and opinfo lookups
will have to move to be close to the bytecode stream, not part
of the
Okay, I finished the support for the generic stack. We can now:
*) save and restore registers (using the save and restore opcodes)
*) return from subs using the address on the top of the stack (using
the ret opcode)
*) Branch to a label using the bsr opcode, and remember where we
Just a quick reminder:
Everything that gets checked into the perl 6 repository *must* have its
ownership either explicitly transferred to YAS (and covered under the
license and suchlike things mentioned in the README file) or explicitly
state that it is covered by the current license *and* exp
On Fri, 12 Oct 2001, Dan Sugalski wrote:
> At 01:30 PM 10/12/2001 -0400, Michael Maraist wrote:
> >I'm of the opinion that you shouldn't just be able to jump into
> >another code-segment.
>
> [Snip]
>
> >And thus be prevented from changing context; That would be relegated
> >to a subroutine invoc
At 01:30 PM 10/12/2001 -0400, Michael Maraist wrote:
>I'm of the opinion that you shouldn't just be able to jump into
>another code-segment.
[Snip]
>And thus be prevented from changing context; That would be relegated
>to a subroutine invocation (especially since such subroutines can be
>dynamic
On Fri, 12 Oct 2001, Ritz Daniel wrote:
> > >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.
> >
> > It can't mean that. This:
> >
> >set I0, 0
> >jump
On Fri, 12 Oct 2001 18:18:27 +0200, Ritz Daniel wrote:
>within the vm address 0 should be address 0 of the bytecode, not the
>real cpu. but it would be nice to have a null pointerso what about the first
>instruction in bytecode is at vm address 1?
All you have to do is reserve the location
> That, unfortunately, is rather excessively restrictive. (Or we would have
> to take over the MMU hardware when we were running. I think I'd like to not
> do that...)
>
> >within the vm address 0 should be address 0 of the bytecode, not the
> >real cpu.
>
> Which bytecode segment, then? And h
At 06:18 PM 10/12/2001 +0200, Ritz Daniel wrote:
> > >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.
> >
> > It can't mean that. This:
> >
> >set I0, 0
> >
At 12:03 PM 10/12/2001 -0400, Gregor N. Purdy wrote:
>Dan --
>
> > It's also possible the 0.0/3.0 division's getting things messed up
> > depending on what flags are set during the compile. It ought to be 0, but
> > there might be some NaNs sneaking in or something.
>
>Another interesting angle. I
> >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.
>
> It can't mean that. This:
>
>set I0, 0
>jump I0
>
> should coredump.
>
i think parrot is a virtual c
Dan --
> It's also possible the 0.0/3.0 division's getting things messed up
> depending on what flags are set during the compile. It ought to be 0, but
> there might be some NaNs sneaking in or something.
Another interesting angle. I hard-coded it to floor(0.0) and still get
the weird result.
At 11:54 AM 10/12/2001 -0400, Gregor N. Purdy wrote:
>Dan --
>
> > >There has got to be something stupid I've done in these big changes,
> > >but I can't think of a failure mode that would screw up floor().
> >
> > My bet, if I had to bet, is that it's not floor that's messed up. You
> might
> >
Dan --
> >There has got to be something stupid I've done in these big changes,
> >but I can't think of a failure mode that would screw up floor().
>
> My bet, if I had to bet, is that it's not floor that's messed up. You might
> want to build parrot with debugging and step through and see if ma
> At 08:48 PM 10/11/2001 -0400, Ryan O'Neil wrote:
> >I was playing with Parrot and wanted a basic random numbers
> >implementation. Just in case anyone else wants it too, here are the
> >appropriate diffs and test file. It seemed logical for rand to return a
> >real number between 0 and 1 ins
Right now we're doing some evil things with bitmasks on pointers to find
the base address of the register chunk structure given a pointer to any
place in the structure. I'm about to do this for stack chunks as well.
Unfortunately, what we're doing now (with a hard-coded constant in
config_h.in
At 08:48 PM 10/11/2001 -0400, Ryan O'Neil wrote:
>I was playing with Parrot and wanted a basic random numbers
>implementation. Just in case anyone else wants it too, here are the
>appropriate diffs and test file. It seemed logical for rand to return a
>real number between 0 and 1 instead of h
At 11:44 PM 10/11/2001 -0400, Gregor N. Purdy wrote:
>The moby patch does lots of things (apply it in a fresh sandbox!),
>and has this same stupid op (and some mod_n debug printfs to boot)
>But, when I run test_prog floortest.pbc, I get:
>
> a = 0.00; b = 3.00; c = 0.00; d = 13452219
At 04:56 AM 10/12/2001 -0400, Bryan C. Warnock wrote:
>It's still early yet, and we have a workable model for our immediate needs.
>But this was weighing on my mind, so I thought I'd get some feelers out
>there while I had pondered this. I'll file any notes away for later.
Cool, thanks. This loo
At 01:33 AM 10/12/2001 -0400, Bryan C. Warnock wrote:
>If floats are so non-portable, why do we have a constant table section for
>them?
Because I was thinking we could reasonably easily fix up IEEE floats into
native format on systems that didn't do IEEE natively. I think that was a
bad idea n
At 03:04 PM 10/12/2001 +0200, Ritz Daniel wrote:
> > 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
Daniel --
> 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
>
>
> 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
On Fri, 12 Oct 2001, Bart Lateur wrote:
> On Thu, 11 Oct 2001 22:23:06 -0400, Dan Sugalski wrote:
>
> >>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.
> >Br
It's still early yet, and we have a workable model for our immediate needs.
But this was weighing on my mind, so I thought I'd get some feelers out
there while I had pondered this. I'll file any notes away for later.
Goal #1: Native efficiency for native platform. As long as the file stays
On Thu, 11 Oct 2001 22:23:06 -0400, Dan Sugalski wrote:
>>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
35 matches
Mail list logo
