On Thu, 2005-06-30 at 19:36 +0200, Leopold Toetsch wrote:
> Brian Wheeler wrote:
> > Its been a while since I tinkered with parrot so I thought I'd start
> > playing again...but I've hit a segfault.
>
> Should of course not happen... But it seems that the codegen i
I noticed a hole in the io.ops where the PIO stuff wasn't covered. This
patch creates an eof opcode which checks for end of file.
Brian Wheeler
[EMAIL PROTECTED]
cvs diff: Diffing .
cvs diff: Diffing ops
Index: ops/io.ops
==
Sigh. I'll get this right sometime!
Brian
Index: config/auto/jit.pl
===
RCS file: /cvs/public/parrot/config/auto/jit.pl,v
retrieving revision 1.33
diff -u -r1.33 jit.pl
--- config/auto/jit.pl 8 Mar 2004 08:49:05 - 1.33
++
;t mess with the
default class that needs the split for the return & exception.
Brian Wheeler
[EMAIL PROTECTED]
Index: config/auto/jit.pl
===
RCS file: /cvs/public/parrot/config/auto/jit.pl,v
retrieving revision 1.33
diff -u -r1.3
d not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [runtime/parrot/dynext/libnci.so] Error 1
No idea how to fix this one...adding --ccflags=-fPIC doesn't help the
compile.
Below is a patch which fixes the first 3.
Brian Wheeler
[EMAIL PROTECTED]
diff -ur ../parrot-0.1.1/classe
On Mon, 2004-07-05 at 19:27, Dan Sugalski wrote:
UNARY_NEGATIVE: restore $Px; new $Py, Undef; $Py = $Px * -1; save $Py |
$Px = -1 * $Px
Wouldn't something this do what is desired? I'm just guessing, though.
Brian
Yep, that did it! Thanks!
Brian
On Mon, 2003-06-09 at 23:11, Paul Fisher wrote:
> Brian Wheeler <[EMAIL PROTECTED]> writes:
>
> > Any thoughts?
>
> Are you running RHL 9? If so, unset LANG and try rebuilding.
>
> Default RHL 9 w/ LANG="en_US.UTF-8"
On Mon, 2003-06-09 at 15:23, Leopold Toetsch wrote:
> Brian Wheeler <[EMAIL PROTECTED]> wrote:
> > Its been a while since I've looked at parrot, so I did a "cvs update
> > -d", "perl Configure.pl", "make clean", "make" and build
_jit_info_t *,
struct Parrot_Interp * );
jit/i386/jit_emit.h:Parrot_end_jit(jit_info, interpreter);
Did I miss something obvious?
Brian Wheeler
[EMAIL PROTECTED]
On Thu, 2002-10-31 at 12:15, Larry Wall wrote:
> On 31 Oct 2002, brian wheeler wrote:
> : I agree considering, this isn't APL and the problems people have had
> : mailing examples (let alone creating them!).
>
> Nevertheless, it has already been decreed that Perl 6 progr
and write my own code in non-Latin-1 environments.
I agree considering, this isn't APL and the problems people have had
mailing examples (let alone creating them!).
I've got to admit all of these operators are scaring me. Seems alot
like Brooks' second-system effect.
Brian Wheeler
[EMAIL PROTECTED]
On Tue, 2002-10-29 at 11:48, Brent Dax wrote:
> [EMAIL PROTECTED]:
> # > Well, on thinking a bit about this, there's no reason that
> # we have to
> # > worry--it's perfectly OK for us to declare, unconditionally, that
> # > segment 0 is always bytecode, 1 line number info, and so on, with
> #
On Mon, 2002-10-28 at 16:44, Mark J. Reed wrote:
> On 2002-10-28 at 16:39:10, brian wheeler wrote:
> > [The below is actually from Larry, not Michael]
> > > explicit radix specifications for integers:
> > > 0123- decimal
> > >2:0110
:123?]
>256:192.168.1.0 - base 256
>(...etc...)
>
I've got to admit that I've not paid alot of attention to this
thread...but does that mean 0x1234 and 01234 (octal) go away or is this
an omission?
Brian Wheeler
[EMAIL PROTECTED]
>
> other uncategorized:
&g
On Sat, 2002-07-13 at 12:32, Tom Hughes wrote:
> In message <20020703012231$[EMAIL PROTECTED]>
> Simon Glover (via RT) <[EMAIL PROTECTED]> wrote:
>
> > This code:
> >
> > A:# prints "a"
> > print "a"
> > end
> >
> > doesn't assemble; the assembler dies wit
I saw this was a TODO item in core.ops.
Brian
--- core.ops1 Jul 2002 17:18:04 - 1.176
+++ core.ops2 Jul 2002 19:41:44 -
@@ -2074,9 +2074,9 @@
=item B(inout STR, in INT)
-Remove $2 characters from the end of the string in $1.
+=item B(out STR, in STR, in INT)
-TODO:
This patch implements a typeof op which returns the integer type or
string type of a PMC.
The test I used is:
new P0,.PerlInt
typeof S0,P0
eq S0,"PerlInt",OK_1
print "not "
OK_1:
print "ok 1\\n"
typeof I0,P0
eq I0,.PerlInt,OK_2
print "not "
OK_2:
pr
On Sat, 2002-06-22 at 20:12, Jeff wrote:
> brian wheeler wrote:
> >
> > Its not backwards, it does the right thing.
>
> Okay, I believe you now :) I was thinking that the insert was done at
> the beginning of the -file-, not the insertion point of the file. If you
> h
On Sat, 2002-06-22 at 13:06, Jeff wrote:
> Clinton A Pierce wrote:
> >
> > At 09:37 PM 6/21/2002 -0500, brian wheeler wrote:
> > >I've implemented a .include directive for the new assembler. It
> > >basically changes the preprocessor to shift through the so
I've implemented a .include directive for the new assembler. It
basically changes the preprocessor to shift through the source file, and
when an include is found, the included file is unshifted to the
beginning.
Should I commit it?
Brian
--- assemble.pl 17 Jun 2002 03:18:17 - 1.74
++
Crud, I forgot to attach the quicksort in the last one...
Brian
On Sat, 2002-05-25 at 21:17, brian wheeler wrote:
> On Fri, 2002-05-24 at 15:10, Sean O'Rourke wrote:
> > > I was starting with a very simple test to decide how to determine where the
> > > memo
On Fri, 2002-05-24 at 15:10, Sean O'Rourke wrote:
> > I was starting with a very simple test to decide how to determine where the
> > memory overuse was coming from,
>
> I'm actually looking at this now as well, though with zip2.pasm instead of
> quicksort. What I've found is that because zip co
0.0 0.35 0.001 0.00 0.00 string_init [128]
I don't see anything that really stands out (unlike earlier builds where
string_make was taking the most time)
Any thoughts?
Brian
#
# quicksort.pasm
#
# Author: Brian Wheeler ([EMAIL PROTECTED])
#
# Usage:
#./par
I've been trying to catch up with parrot again (darn it, babies take
more time than I thought :) and I've come up with a question... how do
you do "other" things to PMCs that aren't normal ops? In particular, I
was wondering about shift/unshift, push/pop on the PerlArray PMC. Am I
missing somethi
On Wed, 2002-02-27 at 14:07, Simon Cozens wrote:
> I know some people have been talking about rewriting the assembler; I've
> had some more thoughts on this over the past couple of days.
>
> First, I think that our assembler is going to be a reference implementation
> for those producing bytecod
On Sat, 2002-02-23 at 13:12, Dan Sugalski wrote:
> At 12:22 PM -0500 2/23/02, Melvin Smith wrote:
> >At 11:53 AM 2/23/2002 +, Simon Cozens wrote:
> >>I was very lucky recently to attend a talk by Ganesh Sittampalam
> >>introducing Microsoft .NET and the Common Language Runtime. A lot of
> >>wh
On Fri, 2001-11-23 at 13:41, Simon Cozens wrote:
> On Fri, Nov 23, 2001 at 06:04:29PM +, Simon Cozens wrote:
> > * Rewrite mops.pasm to use integer PMCs, and compare the speeds.
>
> I couldn't wait. :)
>
> % ../../test_prog mops.pbc
> Iterations:1
> Estimated ops: 2
On Tue, 2001-11-20 at 12:19, Ken Fox wrote:
> James Mastros wrote:
> > In byteswapping the bytecode ...
> >
> > I propose that we make INTVAL and opcode_t the same size, and gaurrenteed
> > to be able to hold a void*.
>
> It sounds like you want portable byte code. Is that a goal? It seems like
On Mon, 2001-11-19 at 19:59, James Mastros wrote:
> Hey all.
> In parellel to splitting out features (yeah, I like that better then
> "platforms" too) (which is going well this time, I think (I'm being a lot
> better about checking against clean checkouts, but having problems
> thinking of a goo
On Mon, 2001-11-19 at 12:43, Hong Zhang wrote:
> > Are there any cases where a void * cannot be placed into an integer
> > register? It seems like it shouldn't happen, especially since jump and
> > jsr are supposed to take an integer register and they point to a
> > host-machine-address...
>
> W
Are there any cases where a void * cannot be placed into an integer
register? It seems like it shouldn't happen, especially since jump and
jsr are supposed to take an integer register and they point to a
host-machine-address...
Brian
On Sat, 2001-11-03 at 22:11, Gregor N. Purdy wrote:
> Brian --
>
> > > None of these are issues with the approach I've been working on /
> > > advocating. I'm hoping we can avoid these altogether.
> > >
> >
> > I think this is a cool concept, but it seems like a lot of overhead with
> > the str
On Sat, 2001-11-03 at 21:40, Gregor N. Purdy wrote:
> James --
>
> > We're going to have to think about assigning static opcode numbers,
> > instead of the current order-defined. For one thing, we're looking at
> > perpetual bytecode compatablity (no?). This isn't really a Big Deal, but we
>
On Fri, 2001-10-26 at 09:57, Sam Tregar wrote:
> On Fri, 26 Oct 2001, Brent Dax wrote:
>
> > What if I want my compiler to be lazy? Do you have the right to punish
> > me for my laziness by making me add constant folding to my optimizer (or
> > perhaps making me *write* an optimizer just to do c
On Fri, 2001-10-26 at 01:32, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Brian Wheeler <[EMAIL PROTECTED]> wrote:
>
> > Darn it, I fat fingered the log message.
> >
> > This is a fix which changes the way op variants are handled. The o
Darn it, I fat fingered the log message.
This is a fix which changes the way op variants are handled. The old
method "forgot" the last variant, so thing(i,i|ic,i|ic) would
generate:
thing(i,i,i)
thing(i,i,ic)
thing(i,ic,i)
but not
thing(i,ic,ic)
The new one does.
Brian
On Mon, 2001-09-17 at 11:20, Gregor N. Purdy wrote:
>
> I agree that jsr/ret are what I really want, but I'm dying to play
> with baby subroutines in jako, and I think I could play enough games
> with a properly understood jump_i and some assembler magic to make
> them work. I now have jump.pasm
On Sun, 2001-09-16 at 14:26, Gregor N. Purdy wrote:
> Brian --
>
> > Its not going to work, if I understand it correctly. I tried doing it
> > (even set up the symbol '*' to mean the current PC) and do it, but it
> > seems the ops take a relative offset. Take jump_i, for example:
>
> Taking th
I've commited a change which allows local labels to be used in parrot.
The labels are local relative to the last non-local label defined (i.e.
local labels are forgotten when a non-local is defined).
Here's my test program:
main: print "test 1\n"
branch $ok
$ng:p
On Fri, 2001-09-14 at 15:42, Dan Sugalski wrote:
> At 03:10 PM 9/14/2001 -0500, Brian Wheeler wrote:
> >I've been thinking alot about the bytecode file format lately. Its
> >going to get really gross really fast when we start adding other
> >(optional) sections to the
On Fri, 2001-09-14 at 15:44, Buddha Buck wrote:
> At 03:10 PM 09-14-2001 -0500, Brian Wheeler wrote:
> >I've been thinking alot about the bytecode file format lately. Its
> >going to get really gross really fast when we start adding other
> >(optional) sections to the
On Fri, 2001-09-14 at 10:20, Dan Sugalski wrote:
> Okay, we've had a number of people in favor of a good macro assembler for
> Parrot. Given that, do we have anyone who'll volunteer to define, maintain,
> and extend the thing? (Presuming we jump off of the current assembler,
> which seems reaso
This patch does a couple of things:
* uses Getopt::Long for options. -c is now --checksyntax. I wasn't
sure how to keep compatible (patches welcome!)
* options include:
--help
--version
--verbose
--output=file
This patch allows you to do thingies like:
and I1,I2,0x
'and', 'or', and 'xor' have been adapted to use this.
Also, shl and shr can take an integer register as the amount to shift.
Brian
? pasm.pl
? patch
? test2.pbc
? test3.pbc
? euclid0.pbc
? euclid1.pbc
? euclid.pbc
?
This patch gives the assembler support of '\a','\n','\r','\t', and '\\'
in string constants.
In addition, it changes (for all registers) "I reg %li is ..." to just
the value of the register. Printing constants is also supported, but
alas, you have to specify the type (print_sc, print_ic, print_n
I caught it trying to use inc_i_ic instead of inc_i in a test program I
was running. this patch fixes it.
Brian
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.12
diff -r1.12 assemble.pl
1
On Thu, 2001-09-13 at 02:23, Simon Cozens wrote:
> On Wed, Sep 12, 2001 at 11:23:27PM -0500, Brian Wheeler wrote:
> > I've been having tons of problems with labels in the current
> > assembler...so I wrote my own. It should provide all of the features
> > that the cur
This diff adds jsr_ic and ret to the interpreter. I don't know if my
way of returning is legal, and I know there's probably issues with 64
bit machines, but it works...and that's the important part :)
Right now it only has a depth of 32 and no bounds checking, but its
enough to get started.
Br
I i
+xor_i 3 I I I
# bitops.pasm : test bitops.
# and, not, or, shl, shr, xor
# Brian Wheeler ([EMAIL PROTECTED])
MAIN: set_i_icI1,0b
set_i_icI2,0b
set_i_icI3,0b10101010
set_i_icI4,0b01010101
set_i_icI5,0
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
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?
>
> No
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 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
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
On Sat, 2001-09-08 at 22:24, Uri Guttman wrote:
> >>>>> "BW" == Brian Wheeler <[EMAIL PROTECTED]> writes:
>
>
> BW> =item and tx, ty, tz *
>
> BW> Bitwise And all bits in y with z and store the result in register x.
> BW&g
On Sat, 2001-09-08 at 21:43, Wizard wrote:
> Questions regarding Bitwise operators:
>
> > =item rol tx, ty, tz *
> ...
> > =item ror tx, ty, tz *
>
> Are these with or without carry?
> If not, is there a need for a RCL/RCR (with carry...and carry where)?
>
I'd think without, since I've not see
On Sat, 2001-09-08 at 15:28, Dan Sugalski wrote:
> At 03:14 PM 9/8/2001 -0500, Brian Wheeler wrote:
> >On Sat, 2001-09-08 at 11:00, Dan Sugalski wrote:
> > > Okay, I'm whipping together the "fancy math" section of the interpreter
> > > assembly lan
On Sat, 2001-09-08 at 11:00, 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, log10, l
While waiting for Parrot (dammit, I took the wrong week off), I've been
scanning the various documents and samples which have been floating
around on the list. Is there a document describing Parrot syntax yet?
Or is that a "will be released on monday" thing as well?
Brian
'perl' or 'perl5'
then it should assume perl 5 code unless there's something that triggers it to
assume otherwise (I.e. the module keyword)
Brian Wheeler
[EMAIL PROTECTED]
print "$person{first_name} is $person{age}\n";
> print "$person{first_name}'s numerical grade is
> $person{num_grade}\n";
> $person{num_grade} = 0 unless $person{never_missed_class};
> if ( $person{num_grade} > 60 ) { print "$person{name}
> passed!\n"; }
> @temp = ($person{name}, $person{age});
>
>
> Dave
>
What if the hash keys we want to use are not valid scalar names? For example,
I've had keys like "total - female" as keys, but using the ^ syntax
would fail on this...
Brian Wheeler
[EMAIL PROTECTED]
64 matches
Mail list logo
