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 is mixing
old and new calling
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
===
RCS
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
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.33 jit.pl
--- config/auto/jit.pl 8 Mar
/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/classes/default.pmc ./classes/default.pmc
--- ../parrot-0.1.1/classes/default.pmc 2004
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
: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 failed:
$ make realclean
should help. We don't have all dependencies
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 programs are
written in Unicode
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
#
- 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:
my our - [declar]
mapgrep
sqrt
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- binary [also b:0110?]
8:123
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 with the error message:
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 Bchopn(inout STR, in INT)
-Remove $2 characters from the end of the string in $1.
+=item Bchopn(out STR, in STR, in INT)
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:
print ok
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 source file, and
when an include is found
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
haven't committed, feel free to do 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
memory overuse was coming from,
I'm
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:
#./parrot quicksort.pbc /file
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
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
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
what CLR is
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
Elapsed
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
we can
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...
What
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 good
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 string lookups.
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
need
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 constant
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 old
method forgot the last variant, so thing(i,i|ic
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 this into
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:
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 code.
So, with that in mind
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
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,
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 current assembler has. I'ved tested
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
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
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.
: 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
set_s_scS1,OK
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
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
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
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
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,
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 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 language. I've got:
sin, cos, tan : Plain ones
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, log
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 (x = y z)
just a minor thought on parrot assembler argument order. dan seems
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 seen any
that triggers it to
assume otherwise (I.e. the module keyword)
Brian Wheeler
[EMAIL PROTECTED]
58 matches
Mail list logo
