Simon Cozens:
# Simon Glover:
# > call.pasm: it has problems with things like [D - @ - 3]
# in the macros
#
# No macros any more. See the assembler PDD.
#
# > fact.pasm, local_label.pasm: it doesn't handle local
# labels like $ok
#
# No local labels either.
#
# > mops_p.pasm, pmcmops.pasm:
Simon Glover:
> call.pasm: it has problems with things like [D - @ - 3] in the macros
No macros any more. See the assembler PDD.
> fact.pasm, local_label.pasm: it doesn't handle local labels like $ok
No local labels either.
> mops_p.pasm, pmcmops.pasm: it doesn't understand PerlInt (or
On Fri, 15 Mar 2002, Dan Sugalski wrote:
> At 12:42 PM +0200 3/15/02, Shlomi Fish wrote:
> >Does this correspond with the general Parrot philosophy? Any
> >other objections?
>
> Did you look at PDD 6? Most of this is already spec'd out.
>
You mean "PDD 6: Parrot Assembly Language"? Do you imply
After installing Text::Balanced on my trusty 561
[msmith@linux parrot]$ time perl newasm examples/assembly/mops.pasm > mops.pbc
Using /home/msmith/parrot/blib
real0m0.564s
user0m0.520s
sys 0m0.050s
[msmith@linux parrot]$ time perl assemble.pl examples/assembly/mops.pasm >
mops.p
On Fri, 15 Mar 2002, Simon Glover wrote:
>
> stack.pasm: it can't handle the expanded opcode names like set_i_ic
>
This actually seems to be quite easy to fix - we just return early from
expand_op is the opcode is already in expanded form. Patch again newasm
attached.
Simon
--- newasm.o
OK, I've finished trying it out on all of the files in examples/assembly.
Most of them assemble and run fine. The ones that don't are:
call.pasm: it has problems with things like [D - @ - 3] in the macros
fact.pasm, local_label.pasm: it doesn't handle local labels like $ok
stack.pasm
At 4:52 PM -0500 3/15/02, Clinton A. Pierce wrote:
>At 04:28 PM 3/15/2002 -0500, Dan Sugalski wrote:
>>At 4:01 PM -0500 3/15/02, Clinton A. Pierce wrote:
>>>I'm in the midst of writing some routines to debug pasm code, and
>>>one of the things I dearly want is a "stack dump" routine. I can
>>>*
Simon Glover:
> With a proper fresh checkout, everything builds OK here, but I've run
> into another problem: Parrot::Assembler:Utils uses Text::Balanced, but
> that's not a core module in 5.6.x and earlier. Weren't we trying to
> stay compatible with Perl's back to 5.5.3 ?
Yep. This wasn't
On Fri, 15 Mar 2002, Simon Cozens wrote:
> You didn't resync. I just updated packout.c to take this function out.
> There's a reason step 1 included CVS updating. :)
Yep, just figured that out for myself - I rsync'd, rather than doing a
cvs checkout, and not realizing it doesn't do quite the
Simon Glover:
> This step spews a load of warnings of the form:
Did you resync? I swear I updated packfile.h to put these back in.
> ... and here make just dies with the message:
You didn't resync. I just updated packout.c to take this function out.
There's a reason step 1 included CVS updati
On Fri, 15 Mar 2002, Simon Cozens wrote:
> Here's how to play with it:
>
> 1) CVS update and build Parrot
> 2) "make packout.o"
This step spews a load of warnings of the form:
packout.c:22: warning: no previous prototype for `PackFile_pack_size'
packout.c: In function `PackFile_pack
This is very rough, since we haven't worked out a great way to
integrate XS and Parrot. But you can try it. It's nice and small:
% wc -l newasm Packfile.xs Packfile.pm Makefile.PL lib/Parrot/Assembler/Utils.pm
188 newasm
94 Packfile.xs
108 Packfile.pm
12 Makefile.PL
46 li
At 04:28 PM 3/15/2002 -0500, Dan Sugalski wrote:
>At 4:01 PM -0500 3/15/02, Clinton A. Pierce wrote:
>>I'm in the midst of writing some routines to debug pasm code, and one of
>>the things I dearly want is a "stack dump" routine. I can *almost* code
>>this in pasm, except I'm missing one last c
At 4:01 PM -0500 3/15/02, Clinton A. Pierce wrote:
>I'm in the midst of writing some routines to debug pasm code, and
>one of the things I dearly want is a "stack dump" routine. I can
>*almost* code this in pasm, except I'm missing one last component: a
>way to tell the depth of the stack with
At 2:59 PM -0600 3/15/02, David M. Lloyd wrote:
>On Fri, 15 Mar 2002, Nicholas Clark wrote:
>
>> On Fri, Mar 15, 2002 at 03:42:50PM -0500, Dan Sugalski wrote:
>>
>> > >> On Fri, 15 Mar 2002, Tim Bunce wrote:
>> > >> > Might be good to also provide "higher level" controls that just
>> > >> >
I'm in the midst of writing some routines to debug pasm code, and one of
the things I dearly want is a "stack dump" routine. I can *almost* code
this in pasm, except I'm missing one last component: a way to tell the
depth of the stack without causing the runtime to bail.
Any of the following
On Fri, Mar 15, 2002 at 08:50:47PM +, Nicholas Clark wrote:
> On Fri, Mar 15, 2002 at 03:42:50PM -0500, Dan Sugalski wrote:
>
> > >> On Fri, 15 Mar 2002, Tim Bunce wrote:
> > >> > Might be good to also provide "higher level" controls that just
> > >> > provide hints to the GC. Somewhat lik
On Fri, 15 Mar 2002, Nicholas Clark wrote:
> On Fri, Mar 15, 2002 at 03:42:50PM -0500, Dan Sugalski wrote:
>
> > >> On Fri, 15 Mar 2002, Tim Bunce wrote:
> > >> > Might be good to also provide "higher level" controls that just
> > >> > provide hints to the GC. Somewhat like the "use less qw(me
At 7:42 PM + 3/15/02, Nicholas Clark wrote:
>On Fri, Mar 15, 2002 at 12:58:19AM +, Alex Gough wrote:
>> On Fri, 15 Mar 2002, Tim Bunce wrote:
>> > Might be good to also provide "higher level" controls that just
>> > provide hints to the GC. Somewhat like the "use less qw(memory);"
>> >
On Fri, Mar 15, 2002 at 12:58:19AM +, Alex Gough wrote:
> On Fri, 15 Mar 2002, Tim Bunce wrote:
> > Might be good to also provide "higher level" controls that just
> > provide hints to the GC. Somewhat like the "use less qw(memory);"
> > pragma that never quite happened for perl5, but with mor
Okay, here's the scoop. All the GC related vtable stuff? Tossed. We
now have exactly two entries.
mark: Called if the PMC has the PMC_custom_mark_FLAG set. Assumed to
mark all the buffers and PMCs this PMC contains
collect: Called if the PMC has the PMC_private_GC_FLAG set. Any
memory allocat
At 12:42 PM +0200 3/15/02, Shlomi Fish wrote:
>Does this correspond with the general Parrot philosophy? Any
>other objections?
Did you look at PDD 6? Most of this is already spec'd out.
--
Dan
--"it's like this"---
Many of the languages (if not most) that are planned to be implemented
above Parrot are lexically-scoped. The methodology to implement such
behaviour on top of an otherwise non-LS VM was described by Abelson and
Sussman in the book "Structure and Interpretation of Computer Programs":
http://mitp
Melvin Smith:
> Anyone planning on hacking up a string replace op anytime soon
> for assigning into a string?
Ideally, substr S1, S2, I1, I2, S3
> Or is the plan to do this with keyed access?
I hadn't thought of using keys on strings; probably not a great idea.
--
Heh, heh, heh, heh... the NO
24 matches
Mail list logo
