The following patch moves all parsing of opcode_table into a
Parrot::Opcode module. It also removes all parsing of interp_guts.h.
This patch incorporates my earlier patches to prefix all C opcode
functions with "Perl_op_".
As best I can tell, everything works the same with the patch as it
did be
This is a first stab at the configure stuff for Parrot. It works fine,
except that I had to put in a hack in the dependencies for it to generate
ops.h before it was needed, since I couldn't figure out how to get the
automatic dependencies system to do it right. Also, it doesn't check for the
This patch (which is pretty big) does:
* Changes the opcode_table file to provide additional information about
the operands. Case shouldn't be a problem since that data never becomes
a C symbol [this is pretty much as before]
* Padding errors solved: assemble.pl and bytecode.c were padding the
On Mon, 2001-09-10 at 20:52, Dan Sugalski wrote:
> At 07:25 PM 9/10/2001 -0400, Bryan C. Warnock wrote:
> >I think Dan mentioned this, but it looks like the suffixes can be derived
> >from the args being passed in. That would greatly simply the assembler to
> >just the function names: set, eq, a
On Mon, 2001-09-10 at 19:54, Dan Sugalski wrote:
> At 07:45 PM 9/10/2001 -0500, Brian Wheeler wrote:
> >If eq_i_ic is really treated as /eq(_i)+_ic/ then this code still
> >doesn't work:
> >
> >eq_i_ic I1,I2,NEXT,DONE
> >
> >because that'd be like eq_i_i_ic_ic, right?
>
> Right. But don't forget,
At 07:25 PM 9/10/2001 -0400, Bryan C. Warnock wrote:
>I think Dan mentioned this, but it looks like the suffixes can be derived
>from the args being passed in. That would greatly simply the assembler to
>just the function names: set, eq, add, branch.
>
>Were there problems with the scheme, is so
Following patch defers output of opcode until the end of an error-free run.
Also introduces a primitive '-c' option to allow checking of assembly only
(a la Perl).
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
On Monday 10 September 2001 09:30 pm, Dan Sugalski wrote:
> >What happens with:
> >
> >goto FOO; { bar { FOO: foo } blah }
> >
> >Is goto responsible for figuring out it has entered bar's
> >scope and setting the VM state so that the exitscopes are
> >properly balanced?
>
> I'm not sure what w
On Monday 10 September 2001 09:27 pm, Dan Sugalski wrote:
>
> Parse opcode_table. Sync up your source first, there have been some
> changes to the format in the last few hours.
I'll wait on those changes before delving back into the assembler for the
simplified instruction handling.
--
Bryan
At 09:26 PM 9/10/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> >jump FOO
> >
> > doesn't change scope.
> >
> >newscope scope_template_in_fixup_section
> >
> > does. And
> >
> >exitscope
> >
> > leaves one. :)
>
>Ok. That clears it up a little. The current scope is part of
>the VM i
This patch (temporarily) fixes the missing _ic on comparison opcodes.
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.6
diff -u -r1.6 assemble.pl
--- assemble.pl 2001/09/10 21:26:08 1.6
+
At 06:02 PM 9/10/2001 -0700, Damien Neil wrote:
>On Mon, Sep 10, 2001 at 08:56:52PM -0400, Dan Sugalski wrote:
> > >I'm thinking of writing something to generate a Parrot::Opcode.pm
> > >module, so code doesn't need to parse opcode_table and interp_guts.h.
> > >Sound reasonable?
> >
> > Yes, pleas
At 09:01 PM 9/10/2001 -0400, Bryan C. Warnock wrote:
>On Monday 10 September 2001 09:00 pm, Dan Sugalski wrote:
> > >But how does the interpreter know where a lexical scope begins
> > >and ends in the bytecode? For example, a "jump FOO" might change
> > >scopes. How is the scope discovered?
> >
>
At 06:16 PM 9/10/2001 -0700, Brent Dax wrote:
>Dan Sugalski:
>...
># The jump ops will be easy to figure--either they'll take a
># register, a
># constant number, or a label. We don't allow labels that could
># be confused
># with registers. (No I0: anywhere...)
>
>Noo! How will I write reall
Dan Sugalski wrote:
>jump FOO
>
> doesn't change scope.
>
>newscope scope_template_in_fixup_section
>
> does. And
>
>exitscope
>
> leaves one. :)
Ok. That clears it up a little. The current scope is part of
the VM internal state and compilers need to generate state
change instruc
Okay, we'll start small. "length_s_i" is backwards - should be "length_i_s".
Patch fixes code and test.
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.6
diff -u -r1.6 basic_opco
On Mon, Sep 10, 2001 at 08:56:52PM -0400, Dan Sugalski wrote:
> >I'm thinking of writing something to generate a Parrot::Opcode.pm
> >module, so code doesn't need to parse opcode_table and interp_guts.h.
> >Sound reasonable?
>
> Yes, please do. I knew we needed one the second time I needed to par
On Monday 10 September 2001 09:00 pm, Dan Sugalski wrote:
> >But how does the interpreter know where a lexical scope begins
> >and ends in the bytecode? For example, a "jump FOO" might change
> >scopes. How is the scope discovered?
>
>jump FOO
>
> doesn't change scope.
Is that a "doesn't" or
Dan Sugalski:
...
# The jump ops will be easy to figure--either they'll take a
# register, a
# constant number, or a label. We don't allow labels that could
# be confused
# with registers. (No I0: anywhere...)
Noo! How will I write really confusing JAPHs now? :^)
--Brent Dax
[EMAIL PROTECT
On Monday 10 September 2001 08:58 pm, Dan Sugalski wrote:
> >
> >Tayyib.
>
> Is that a good thing or a bad thing? :)
It's an "okay" thing. Literally.
>
> >Handling constants now. Everything else seems to work on the
> >assembler side.
>
> Keen. Constants are odd, since they can happen in a n
At 09:06 PM 9/10/2001 -0400, Ken Fox wrote:
>Jeffrey Coleman Carlyle wrote:
> > Am I missing something (well, clearly I am), but are test.pasm and
> > test2.pasm missing from the CVS repository?
>
>Look in ./t
Right. We moved them around a bit ago. Joys of a new project--everything's
in flux, an
At 09:05 PM 9/10/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > At 05:41 PM 9/10/2001 -0400, Ken Fox wrote:
> > > You're expecting the current lexical scope to be carried implicitly
> > > via the PC?
> >
> > No, it'll be in the interpreter struct.
>
>But how does the interpreter know where a
At 05:49 PM 9/10/2001 -0700, Damien Neil wrote:
>On Mon, Sep 10, 2001 at 08:48:48PM -0400, Dan Sugalski wrote:
> > At 04:56 PM 9/10/2001 -0700, Brent Dax wrote:
> > >This patch seems to work on the FreeBSD box I have access to. Now to
> > >figure out what's causing all those 'use of uninitialized
At 08:44 PM 9/10/2001 -0400, Bryan C. Warnock wrote:
>On Monday 10 September 2001 08:47 pm, Dan Sugalski wrote:
> > Because I think backwards from most people, apparently. :)
> >
> > That and generally speaking if there are three args the second is the same
> > type as the first, while the third i
Jeffrey Coleman Carlyle wrote:
> Am I missing something (well, clearly I am), but are test.pasm and
> test2.pasm missing from the CVS repository?
Look in ./t
- Ken
Dan Sugalski wrote:
> At 05:41 PM 9/10/2001 -0400, Ken Fox wrote:
> > You're expecting the current lexical scope to be carried implicitly
> > via the PC?
>
> No, it'll be in the interpreter struct.
But how does the interpreter know where a lexical scope begins
and ends in the bytecode? For examp
At 07:45 PM 9/10/2001 -0500, Brian Wheeler wrote:
>If eq_i_ic is really treated as /eq(_i)+_ic/ then this code still
>doesn't work:
>
>eq_i_ic I1,I2,NEXT,DONE
>
>because that'd be like eq_i_i_ic_ic, right?
Right. But don't forget, I screwed up the eq op--it ought to have a single
destination. :)
At 07:56 PM 9/10/2001 -0500, Brian Wheeler wrote:
>I've got to know...what's the significance of the magic number? :)
It's the number of arguments. Why it's there, I don't know, since it's
redundant. Seemed like a good idea at the time. We can probably chop it out
without a problem.
On Mon, Sep 10, 2001 at 08:48:48PM -0400, Dan Sugalski wrote:
> At 04:56 PM 9/10/2001 -0700, Brent Dax wrote:
> >This patch seems to work on the FreeBSD box I have access to. Now to
> >figure out what's causing all those 'use of uninitialized value at
> >assembler.pl line 81' messages...
>
> I
# -Original Message-
# From: Jeffrey Coleman Carlyle [mailto:[EMAIL PROTECTED]]
# Sent: Monday, September 10, 2001 5:04 PM
# To: 'Simon Cozens'
# Cc: [EMAIL PROTECTED]
# Subject: RE: Parrot 0.0.1 is released.
#
#
# Am I missing something (well, clearly I am), but are test.pasm and
# test2.
On Monday 10 September 2001 08:47 pm, Dan Sugalski wrote:
> Because I think backwards from most people, apparently. :)
>
> That and generally speaking if there are three args the second is the same
> type as the first, while the third is the variant. Generally.
Tayyib. Handling constants now. E
At 04:56 PM 9/10/2001 -0700, Brent Dax wrote:
>This patch seems to work on the FreeBSD box I have access to. Now to
>figure out what's causing all those 'use of uninitialized value at
>assembler.pl line 81' messages...
It's the blank lines in opcode_table. The assembler (and disassembler) at
At 08:00 PM 9/10/2001 -0400, Bryan C. Warnock wrote:
>On Monday 10 September 2001 06:23 pm, Dan Sugalski wrote:
> > At 05:23 PM 9/10/2001 -0500, Brian Wheeler wrote:
> > >First off, here's an inconsistancy I found: In test.pasm
> > >
> > >REDO: eq_i_ic I2, I4, DONE, NEXT
> > >
> > >appears. Sh
"Bryan C. Warnock" wrote:
> On Monday 10 September 2001 06:23 pm, Dan Sugalski wrote:
> > When we run out, we repeat the innermost type.
>
> Why are you doing right-to-left instead of left-to-right?
Because it would be harder to repeat the innermost type then? ;)
Most binary ops will take identi
another thought...
>
> A thought (though gross): if we restrict mneumonics to not use the underscore,
> then anything after _ can be the op signature.
>
> The opcode_table could use these characters for different data types:
> integer i
> integer constant j
> numeri
>
> At 05:23 PM 9/10/2001 -0500, Brian Wheeler wrote:
> >First off, here's an inconsistancy I found: In test.pasm
> >
> >REDO: eq_i_ic I2, I4, DONE, NEXT
> >
> >appears. Shouldn't this be comparing to a constant, not a register?
>
> Nope, though if I let you in on the actual secret it's help
Simon Cozens wrote:
> =head1 The Parrot String API
Have you guys seen Topaz? One of many things I think Chip
did right was to build strings from a low-level buffer
concept. This moves memory management (and possibly raw-io)
out of the string class and into the buffer class.
The other major sugge
Yes, I'm still interested. Don't know how much I'll have time,
though, (even after 5.8.0, that is). But I guess (together with Andy)
we can at least tell horror stories about all the possible ways of how
*not* to do it to scare all the young whippersnappers :-)
--
$jhi++; # http://www.iki.fi/j
On Monday 10 September 2001 06:23 pm, Dan Sugalski wrote:
> At 05:23 PM 9/10/2001 -0500, Brian Wheeler wrote:
> >First off, here's an inconsistancy I found: In test.pasm
> >
> >REDO: eq_i_ic I2, I4, DONE, NEXT
> >
> >appears. Shouldn't this be comparing to a constant, not a register?
>
> Nope,
Am I missing something (well, clearly I am), but are test.pasm and
test2.pasm missing from the CVS repository?
// Jeffrey Coleman Carlyle: Computer Science Graduate Student at the
// University of Illinois at Urbana-Champaign; Creator of StratoSetup,
// Windows Restart, comp.os.msdos.programme
Simon Cozens wrote:
> FWIW, it's just dawned on me that if we want all of these things to be
> overloadable by PMCs, they need to have vtable entries. The PMC vtable
> is going to be considerably bigger than we anticipated.
Surely you don't expect the PMC vtable to be the only mechanism
for overl
Damien Neil:
# On Mon, Sep 10, 2001 at 04:04:20PM -0700, Damien Neil wrote:
# > The following quick-and-dirty patch appears to work. This prefixes
# > all opcode functions with "Parrot_op_". I'd have made the prefix
# > configurable, but the opcode generation is spread across three
# > different
Damien Neil:
# On Mon, Sep 10, 2001 at 06:58:23PM -0400, Dan Sugalski wrote:
# > At 03:52 PM 9/10/2001 -0700, Damien Neil wrote:
# > >Parrot fails to work in very obscure ways on FreeBSD. After some
# > >poking around, I tracked the problem to the "end" op--this appears
# > >to conflict with some
On Mon, Sep 10, 2001 at 04:04:20PM -0700, Damien Neil wrote:
> The following quick-and-dirty patch appears to work. This prefixes
> all opcode functions with "Parrot_op_". I'd have made the prefix
> configurable, but the opcode generation is spread across three
> different files.
Oops--that bre
I think Dan mentioned this, but it looks like the suffixes can be derived
from the args being passed in. That would greatly simply the assembler to
just the function names: set, eq, add, branch.
Were there problems with the scheme, is someone working on it, or did it
fall through the cracks?
On Mon, Sep 10, 2001 at 06:58:23PM -0400, Dan Sugalski wrote:
> At 03:52 PM 9/10/2001 -0700, Damien Neil wrote:
> >Parrot fails to work in very obscure ways on FreeBSD. After some
> >poking around, I tracked the problem to the "end" op--this appears
> >to conflict with something inside libc. Ren
On Mon, Sep 10, 2001 at 11:13:15PM +0100, Simon Cozens wrote:
> Brian, if you could cvs update (or grab the snapshot from
> http://www.netthink.co.uk/downloads/parrot-0.0.1.tar.gz)
If all goes well,
http://www.netthink.co.uk/downloads/parrot-nightly.tar.gz
will contain nightly CVS snapshot
On Mon, 10 Sep 2001 17:13:44 -0400, Dan Sugalski wrote:
>Who the heck is going to override arctangent? (No, don't tell me, I don't
>want to know)
Perhaps you do. Think BigFloat. Or Complex.
--
Bart.
On Mon, Sep 10, 2001 at 06:23:02PM -0400, Dan Sugalski wrote:
> That should really be eq_i_ic_ic. (Well, actually there should be only one
> label, and we fall through otherwise. It's a bug in implementation and
> assembly, not opcode name... :)
Patches are... :)
> I was using a trailing c to
At 02:12 PM 9/10/2001 -0700, Hong Zhang wrote:
> > Uri Guttman
> > > we are planning automatic over/underflow to bigfloat. so there is no
> > > need for traps. they could be provided at the time of the
> > > conversion to big*.
> >
> > OK. But will Perl support signaling and non-signaling NANs?
>
At 05:23 PM 9/10/2001 -0500, Brian Wheeler wrote:
>First off, here's an inconsistancy I found: In test.pasm
>
>REDO: eq_i_ic I2, I4, DONE, NEXT
>
>appears. Shouldn't this be comparing to a constant, not a register?
Nope, though if I let you in on the actual secret it's help.
That should real
First off, here's an inconsistancy I found: In test.pasm
REDO: eq_i_ic I2, I4, DONE, NEXT
appears. Shouldn't this be comparing to a constant, not a register? It
became a little obvious when I made a few changes to the
assembler/disassembler to give more details about the data (and to allow
At 05:41 PM 9/10/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > =item if tx, X, Y
>
>What's the purpose of providing Y? Does it make anything easier
>allowing Y != 0?
Hmmm. No, it doesn't, it just bloats out the opcode stream by an IV. I'll
fix that.
> > =item jump tx
>
>I expected a "call
On Mon, Sep 10, 2001 at 05:25:46PM -0400, Sam Tregar wrote:
> Ooo, ooo - me first. Since you turned on -Wall in the Makefile I thought
> it would be nice if it compiled without warnings. Below is a patch that
> does that on my system.
Thanks, applied. (Although I consider it a temporary fix, be
On Mon, Sep 10, 2001 at 09:42:38PM +0100, Simon Cozens wrote:
> From CPAN: http://www.cpan.org/authors/id/S/SI/SIMON/parrot-0.0.1.tar.gz
>http://www.cpan.org/src/parrot-0.0.1.tar.gz
>(once the mirrors have updated)
>
> From CVS: See the Parrot CVS home pag
> At 09:15 PM 9/10/2001 +0100, Simon Cozens wrote:
> >FWIW, it's just dawned on me that if we want all of these things to be
> >overloadable by PMCs, they need to have vtable entries. The PMC vtable
> >is going to be considerably bigger than we anticipated.
>
> Who the heck is going to override a
Dan Sugalski wrote:
> =item if tx, X, Y
What's the purpose of providing Y? Does it make anything easier
allowing Y != 0?
> =item jump tx
I expected a "call" op too. Not a named sub call, but just "call
tx" where tx has the same semantics as in "jump".
A "return" op is needed too.
> =item iton
> Patches should be sent to the perl6-internals mailing list, where I'll take a
> look at them and apply them to the CVS tree.
Ooo, ooo - me first. Since you turned on -Wall in the Makefile I thought
it would be nice if it compiled without warnings. Below is a patch that
does that on my system
On Mon, 10 Sep 2001, Simon Cozens wrote:
> On Sat, Sep 08, 2001 at 12:00:24PM -0400, Dan Sugalski wrote:
> > Okay, I'm whipping together the "fancy math" section of the interpreter
> > assembly language. I've got:
> >
> > sin, cos, tan : Plain ones
> > asin, acos, atan: arc-what
> Uri Guttman
> > we are planning automatic over/underflow to bigfloat. so there is no
> > need for traps. they could be provided at the time of the
> > conversion to big*.
>
> OK. But will Perl support signaling and non-signaling NANs?
I don't think we should go for automatic overflow/underf
At 09:15 PM 9/10/2001 +0100, Simon Cozens wrote:
>FWIW, it's just dawned on me that if we want all of these things to be
>overloadable by PMCs, they need to have vtable entries. The PMC vtable
>is going to be considerably bigger than we anticipated.
Who the heck is going to override arctangent? (
On Sat, Sep 08, 2001 at 12:00:24PM -0400, Dan Sugalski wrote:
> Okay, I'm whipping together the "fancy math" section of the interpreter
> assembly language. I've got:
>
> sin, cos, tan : Plain ones
> asin, acos, atan : arc-whatevers
> shinh, cosh, tanh : Hyperbolic whatevers
> l
Because the game of hide-and-seek was still going on, it took Edmund
and Lucy some time to find the others. But when at last they were all
together (which happened in the long room, where the suit of armour
was) Lucy burst out:
"Peter! Susan! It's all true. Edmund has seen it
Uri Guttman
> we are planning automatic over/underflow to bigfloat. so there is no
> need for traps. they could be provided at the time of the
> conversion to big*.
OK. But will Perl support signaling and non-signaling NANs?
Dan Sugalski wrote:
>Okay, I'm whipping together the "fancy math" section of the interpreter
>assembly language. I've got:
[...]
>
>Can anyone think of things I've forgotten? It's been a while since I've
>done numeric work.
I'm not a math weenie, but I would thing gamma(x) would be of use.
Also
--- "Bryan C. Warnock" <[EMAIL PROTECTED]> wisely wrote:
> On Monday 10 September 2001 01:08 pm, Simon Cozens wrote:
> > And in addition - why are we worrying about namespace
> collision RIGHT NOW?
> > Sure, when Parrot can be embedded, then we should
> ensure that our names
> > aren't going to cl
At 10:58 AM 9/10/2001 -0700, David Whipp wrote:
>Dan Sugalski wrote:
> > Okay, I'm whipping together the "fancy math" section of the
> > interpreter assembly language. I've got:
>[...]
> > Can anyone think of things I've forgotten? It's been a while
> > since I've done numeric work.
>
>I'm not sur
At 10:55 AM 9/10/2001 -0700, Hong Zhang wrote:
> > At 06:26 PM 9/9/2001 -0700, Wizard wrote:
> > >into something using a processor op equivalent to the 8051C
> > >testbit( byte_variable, bit_offset).
> >
> > This is pretty much
> >
> >testbit I0, 6
> >
> > to test whether bit 6 is set i I0
> "DW" == David Whipp <[EMAIL PROTECTED]> writes:
DW> Dan Sugalski wrote:
>> Okay, I'm whipping together the "fancy math" section of the
>> interpreter assembly language. I've got:
DW> [...]
>> Can anyone think of things I've forgotten? It's been a while
>> since I've done numer
Dan Sugalski wrote:
> Okay, I'm whipping together the "fancy math" section of the
> interpreter assembly language. I've got:
[...]
> Can anyone think of things I've forgotten? It's been a while
> since I've done numeric work.
I'm not sure where this belongs, but I'd really like to have
a usage
> At 06:26 PM 9/9/2001 -0700, Wizard wrote:
> >into something using a processor op equivalent to the 8051C
> >testbit( byte_variable, bit_offset).
>
> This is pretty much
>
>testbit I0, 6
>
> to test whether bit 6 is set i I0, right?
What is the difference from
and I0, I0, (1 << 6)
Bryan C. Warnock writes:
> It's not a prioirty, but it's so much easier to walk the correct path from
> the start. Since it's all Parrot, it's even easier.
I agree. How about this: when the code is available (i.e., this
afternoon), why don't you sit down with whoever else feels
passionately ab
At 06:26 PM 9/9/2001 -0700, Wizard wrote:
>into something using a processor op equivalent to the 8051C
>testbit( byte_variable, bit_offset).
This is pretty much
testbit I0, 6
to test whether bit 6 is set i I0, right?
Dan
-
At 01:20 PM 9/10/2001 -0400, Bryan C. Warnock wrote:
>On Monday 10 September 2001 01:08 pm, Simon Cozens wrote:
> > And in addition - why are we worrying about namespace collision RIGHT NOW?
> > Sure, when Parrot can be embedded, then we should ensure that our names
> > aren't going to clash. But
I'm having trouble with my hosting company (wehost.net is poop!). That last
email was a reply that I sent last night at 6pm. Please ignore it :-P
Grant M.
At 12:46 PM 9/10/2001 -0400, Jason Gloudon wrote:
>Will the buffers associated with a string be managed by Parrot's memory
>management, and be visible to the garbage collector ? Or will these buffers be
>allocated from their own pool of memory not subject to garbage collection.
They'll be GC'd.
On Monday 10 September 2001 01:08 pm, Simon Cozens wrote:
> And in addition - why are we worrying about namespace collision RIGHT NOW?
> Sure, when Parrot can be embedded, then we should ensure that our names
> aren't going to clash. But who in their right minds is going to embed
> Parrot in anyth
On Mon, Sep 10, 2001 at 10:58:33AM -0600, Nathan Torkington wrote:
> let's assume that Parrot will only officially be part of the Perl project,
> and focus on writing more Parrot code instead of arguing about
> namespaces.
What He Said.
And in addition - why are we worrying about namespace colli
Will the buffers associated with a string be managed by Parrot's memory
management, and be visible to the garbage collector ? Or will these buffers be
allocated from their own pool of memory not subject to garbage collection.
--
Jason
[EMAIL PROTECTED] (Simon Cozens) writes:
> =head2 C
>
> This field is, as its name suggests, unused; however, it can be used to
> hold a pointer to the correct vtable for foreign strings.
Wouldn't it be better to put a vtable * directly inside struct
parrot_string instead of the 'encoding' enum
Well, I used to do some embedded systems programming using C, and many of
the compilers would make attempts to optimize logical ops like
if( byte_variable & 0xF7 ){...
into something using a processor op equivalent to the 8051C
testbit( byte_variable, bit_offset).
The 8051 processor has sever
I'm happy to say that, in preparation for the release of the first
piece of Parrot code, Simon Cozens has stepped forward to hold the
source pumpkin.
Simon's responsible for the contents of the internal and external
source distribution. He'll update the CVS repository with patches
submitted by t
> "W" == Wizard <[EMAIL PROTECTED]> writes:
W> Uri Guttman wrote:
>> but having parrot op codes map to special instructions
>> makes sense only if we are doing some form of machine instruction
>> generation as with JIT or TIL.
W> Actually, I wasn't necessarily asking for any speci
On Monday 10 September 2001 12:58 pm, Nathan Torkington wrote:
> Here's my Official Word. Right now it's too early to know whether
> building perl6's runtime to also support other languages will impact
> perl6's speed or size. We also have faced skepticism about the whole
> effort from other lan
Bryan C. Warnock writes:
> Like I said, just things to keep in mind. There's a slight difference
> between designing and coding Parrot as an interpreter backend, and coding it
> as a backend to Perl that other languages can use. (I'm in favor of the
> latter, though public opinion seems to fa
On Monday 10 September 2001 11:16 am, Dan Sugalski wrote:
> No. We don't need perl to test the interpreter. Parser and compiler, yes,
> interpreter no.
The code that we are writing in assembler is Parrot opcode that we would
expect a Perl parser and compiler to spit out. (That's all I'm saying.
I'm happy to say that, in preparation for the release of the first
piece of Parrot code, Simon Cozens has stepped forward to hold the
source pumpkin.
Simon's responsible for the contents of the internal and external
source distribution. He'll update the CVS repository with patches
submitted by t
Dan Sugalski:
# At 10:08 AM 9/10/2001 -0700, Wizard wrote:
# >Uri Guttman wrote:
...
# Okay, I see what you're aiming at. I don't think we will,
# mainly because
# it's not going to do us a whole lot of good. Parrot's got
# more registers
# than any system on the planet that I know of, so the bit
On Mon, Sep 10, 2001 at 10:29:13AM -0400, Bryan C. Warnock wrote:
> Parrot is striving to be a common backend for multiple scripting languages,
> of which one is Perl 6, no? And, of course, to adequately test Parrot, you
> need to concurrently develop Perl 6, yes? And that is what is currently
At 10:29 AM 9/10/2001 -0400, Bryan C. Warnock wrote:
>Erk, we seem to be muddling around in that great grey area between what is
>Parrot and what is Perl.
>
>Parrot is striving to be a common backend for multiple scripting languages,
>of which one is Perl 6, no? And, of course, to adequately test
At 03:55 PM 9/10/2001 +0100, Dave Mitchell wrote:
>Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> > Erk, we seem to be muddling around in that great grey area between what is
> > Parrot and what is Perl.
>
>Yes, which leads me on to think...
>
>(With my "maintainer of the Coding PDD" hat on)
>
>Pr
At 10:08 AM 9/10/2001 -0700, Wizard wrote:
>Uri Guttman wrote:
> > but having parrot op codes map to special instructions
> > makes sense only if we are doing some form of machine instruction
> > generation as with JIT or TIL.
>
>Actually, I wasn't necessarily asking for any special ops (I'm not a
At 10:07 AM 9/10/2001 -0500, Brian Wheeler wrote:
>Honestly, I don't care either way, since add i0,i0,0 is the same
>(basically) as a nop, but takes a little more cpu. One could always
>#define nop add i0,i0,0
>:)
Ah, almost, except that add i0,i0,0 is a four-word instruction, and you
might be
Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> Erk, we seem to be muddling around in that great grey area between what is
> Parrot and what is Perl.
Yes, which leads me on to think...
(With my "maintainer of the Coding PDD" hat on)
Presumably we have to decide what bits of code have a Parrot_
On Mon, 2001-09-10 at 09:16, Bryan C. Warnock wrote:
> On Monday 10 September 2001 10:28 am, Brian Wheeler wrote:
> >
> > I was thinking about NOP this morning, and I realized that it might very
> > well be necessary. If someone was writing a "simple" assembler for
> > parrot, it might be useful
Erk, we seem to be muddling around in that great grey area between what is
Parrot and what is Perl.
Parrot is striving to be a common backend for multiple scripting languages,
of which one is Perl 6, no? And, of course, to adequately test Parrot, you
need to concurrently develop Perl 6, yes?
On Monday 10 September 2001 10:28 am, Brian Wheeler wrote:
>
> I was thinking about NOP this morning, and I realized that it might very
> well be necessary. If someone was writing a "simple" assembler for
> parrot, it might be useful for padding.
Pad what?
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Mon, 2001-09-10 at 08:47, Dan Sugalski wrote:
> At 08:07 PM 9/9/2001 -0400, Uri Guttman wrote:
> > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> >
> > DS> Yeah, I can't think of a good reason for a noop. We might have one
> > DS> anyway, though, just in case one comes along anywa
Uri Guttman wrote:
> but having parrot op codes map to special instructions
> makes sense only if we are doing some form of machine instruction
> generation as with JIT or TIL.
Actually, I wasn't necessarily asking for any special ops (I'm not actually
asking for anything, it's just a suggestion)
At 12:53 PM 9/10/2001 +0100, Nicholas Clark wrote:
>On Sun, Sep 09, 2001 at 10:16:27PM +0100, Simon Cozens wrote:
> > =head1 Elements of the C structure
> >
> > Those implementing the C API will obviously need to know about
> > how the C structure works. You can find the definition of this
> > str
1 - 100 of 109 matches
Mail list logo
