'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]
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
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
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 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
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
>
> 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
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
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 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
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
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
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
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
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
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
++
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
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
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
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:
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
: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 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
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
> #
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 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
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
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"
_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 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
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
==
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
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
;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
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
++
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 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 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
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
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
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 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 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 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
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
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
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 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 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 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
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
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 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
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 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 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 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
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
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
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
