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
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
--- 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 the anon
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 when
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.
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 instruction slot
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 CSTRING structure
Those implementing the CSTRING API will obviously need to know about
how the CSTRING structure works. You can find the definition of
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++; #
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 numeric work.
DW I'm
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 sure where this
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
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?
I don't think
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 model
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
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 special ops (I'm not
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
[EMAIL PROTECTED] (Simon Cozens) writes:
=head2 Cunused
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'
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
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 really
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 anything
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 who in
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
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)
Unless if
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, right?
What is
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 for
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
log2,
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-whatevers
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, 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 page at
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 breaks
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 something
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
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,
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, though if I
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
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
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
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 actually
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
numeric
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 identical
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.
# -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
#
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...
It's the
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.
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 example, a
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
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
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, and the
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,
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
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 parse
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
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 instructions if
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 really
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?
jump FOO
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, please do. I knew
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 op too.
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 internal state and
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 C.
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 we'll do in that
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 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 anyway.
in a hardware
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, add,
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
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
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
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 favor
81 matches
Mail list logo
