Thus wrote the illustrious Simon Cozens:
[severely trimmed]
> STRING* string_make(void *buffer, IV buflen, IV
> encoding, IV flags, IV type)
> STRING* string_copy(STRING* s)
> void string_destroy(STRING *s)
*cough* Namespace pollution *cough*
These should proably all be prefixed...
On Mon, Sep 10, 2001 at 04:48:35AM -0700, Benjamin Stuhl wrote:
> *cough* Namespace pollution *cough*
> These should proably all be prefixed...
You're going to have a canary when you see the rest of the code... :)
Seriously, I see the string subsystem as being self-sufficient; it can be
detached
You'll be glad to hear that the interpreter now supports strings.
Here's a document about how that happens and what STRING* means and
its API. As before, I'd like
i) people to come up with more fundamental operations on strings
ii) someone to take over this document and patch it up based o
On Mon, Sep 10, 2001 at 12:53:51PM +0100, Nicholas Clark wrote:
> > void *bufstart;
>
> A split buffer would allow an offset at the front, by effectively treating
> the STRING as '' . 'Pathologically Eclectic Rubbish Lister'
Who says we don't support split buffers? void* bufstart can be an
--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 10, 2001 at 04:48:35AM -0700, Benjamin Stuhl
> wrote:
> > *cough* Namespace pollution *cough*
> > These should proably all be prefixed...
>
> You're going to have a canary when you see the rest of
> the code... :)
I know. I've looked at t
On 09/07/01 Dan Sugalski wrote:
> >The only optimizations that interpreter had, were computed goto and
> >allocating the eval stack with alloca() instead of malloc().
>
> Doesn't this really get in the way of threading? You'll chew up great gobs
> of system stack, and that's a scarce resource wh
At 10:09 PM 9/9/2001 +0100, Simon Cozens wrote:
>On Fri, Sep 07, 2001 at 04:30:56PM -0400, Dan Sugalski wrote:
> > =item find_method Px, Py, tz
>
>Using what kind of dispatch mechanism? Or is that what the t is for?
That bit needs to change because of some of the stuff I've been digging
into. Ba
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 anyway.
>
>in a hardware cpu they were commonly used to fill an
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
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)
On Fri, Sep 07, 2001 at 04:30:56PM -0400, Dan Sugalski wrote:
> =item find_method Px, Py, tz
Using what kind of dispatch mechanism? Or is that what the t is for?
Simon
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
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
> "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
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
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?
> 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
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
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?
>
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
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
> "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
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
[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
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
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, 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
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
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
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.
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 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
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
-
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?
What is the difference from
and I0, I0, (1 << 6)
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?
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
--- "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
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
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
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
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 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
> 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
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
> 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
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
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
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.
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
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
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
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?
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
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
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
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
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
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
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,
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
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
>
> 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
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
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
"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
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
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
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
# -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 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
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_
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.
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. :)
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 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
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
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
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
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 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 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
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
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
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 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
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
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
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
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
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
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: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
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 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
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
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
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
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
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
1 - 100 of 109 matches
Mail list logo
