On 2 Nov 2002, Juergen Boemmels wrote:
> Ok, I tested the patch (I tried to use this scratchpads for the scheme
> compiler)
> One thing I missed (or at least didn't find): How can I generate a new
> scope? new_pad generates a new one one the pad stack with a size which
> is actually smaller than
At 9:41 AM +0100 10/30/02, Leopold Toetsch wrote:
Jason Gloudon wrote:
... By default both compilers align stack variables at their natural
alignment, so PMC pointers would normally fall on 4 byte boundaries.
However, it is also possible that someone might save a PMC pointer to an
unaligned add
At 12:41 PM +0100 10/30/02, Leopold Toetsch wrote:
Nicholas Clark wrote:
Also, no-one commented on my suggestion a long time back to remove
-fno-strict-aliasing from gcc's flags. In theory we're stopping some possible
gcc optimisations with this.
I don't see a reason, why we would need -fno-st
Nicholas Clark wrote:
> I believe that your understanding of the JIT and the GC cores are still
> correct. The problem would be solved if we had some nice way of getting the
> C compiler to generate us nice stub versions of all the non-inline ops
> functions, which we could then place inline. Howe
On Mon, Nov 04, 2002 at 09:21:06PM +, Nicholas Clark wrote:
> I'm not convinced. Compiling the computed goto core with any sort of
> optimisation turns on *really* hurts the machine. I think it's over a
> minute even a 733 MHz PIII, and it happily pages everything else out while
> it's doing i
At 18:57 on 11/04/2002 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> atexit is not an alternative, because we might have multiple
> interpreters to clean up like in t/op/interp_2.
So the issue here is that on_exit can take a parameter to be passed into
the handler function, right?
We cou
Nicholas --
I agree it would be good to see CG performance (compilation and exeuction
speed) with and without
optimizations. I haven't done the experiment myself.
I had tinkered with some asm-comment ideas last year when discussing JIT
with Daniel Grunblatt. For
your amusement, I've attached a
On Mon, Nov 04, 2002 at 10:09:06AM -0500, [EMAIL PROTECTED] wrote:
> While I don't think I'm sophisticated enough to pull it off on my own, I
> do think it should be possible to use what was learned to build the JIT
> system to build the equivalent of a CG core on the fly, given its
> structure
What is the official position with respect to laundry services in the
Parrot memory allocation code?
Some code assumes that the memory returned by Parrot_allocate
and its cousins will be pre-washed, while other code does its own
laundry. The same applies to 'bufferlike' headers - the buffer fields
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Andy Dougherty wrote:
>
>
> > Alternatively, developers could always try to ensure they checkin patches
> > in the correct order so that the timestamps stay correct.
Does cvs change the timestamps at checkout/update according to the
checkin timestam
Andy Dougherty (via RT) wrote:
That's because Solaris doesn't have on_exit. It does have atexit, but
atexit doesn't take any parameters so it's not a direct drop-in
replacement. The correct "fix" is not obvious to me. I suppose
someone could have Configure.pl test for on_exit and only use it
Andy Dougherty wrote:
Alternatively, developers could always try to ensure they checkin patches
in the correct order so that the timestamps stay correct.
Or yet another one:
$ cat bison
touch imcparser.c imcparser.h imclexer.c
in languages/imcc should do it.
leo
Andy Dougherty wrote:
I have committed the following patch:
-//mem_sys_free(p);
+/* mem_sys_free(p); */ /* XXX ??? */
Sorry for that, must have slipped through during my different trials to
clean up PIO.
It would also be nice if someone who understood this could add comme
Andy Dougherty wrote:
Alternatively, developers could always try to ensure they checkin patches
in the correct order so that the timestamps stay correct.
I would prefer such a solution - or better something a long:
info cvs
The commit support files
i.e. a script
Jason --
Originally, I considered adding an optable segment to the packfile format
and no useop op.
After considering useop, I found the idea of a conventional (but
technically optional, TMTOWTDI) preamble
and the ability to modify the optable while running intriguing.
There is value to using
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #18219]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18219 >
The Solaris tinderbox is currently failing with
gcc -o parrot [...]
Undefined
Dan Sugalski <[EMAIL PROTECTED]> writes:
[...]
> No, it doesn't. It needs to preallocate a few entries in the TOC at
> the start of the chunk, but that's it. Not that much waste, even if
> some of the metadata's in the TOC.
>
>
> The point is to have a file format that does what we need it
> to
[EMAIL PROTECTED] wrote:
Leo --
I don't know much about the CG core, but prederef and JIT should be able
to work with dynamic optables. For prederef and JIT, optable mucking does
expire your prederefed and JITted blocks (in general), but for
conventional use (preamble setup), you don't pay a
I have committed the following patch:
diff -r -u parrot-orig/io/io.c parrot-andy/io/io.c
--- parrot-orig/io/io.c Mon Nov 4 11:26:09 2002
+++ parrot-andy/io/io.c Mon Nov 4 12:02:22 2002
@@ -160,7 +160,7 @@
down = p->down;
if (p->api->Delete)
(*p->api->Delete) (p);
-
When I trycd languages/perl6; make; the build stops with
bison -v -y -d -o imcparser.c imcc.y
sh: bison: not found
The above-referenced patch includes changes to
config/gen/makefiles/imcc.in to avoid this problem.
That patch has the disadvantage of requiring developers to remember
On Sun, Nov 03, 2002 at 04:59:22PM -0500, [EMAIL PROTECTED] wrote:
> What I advocate is having possibly only one (maybe too extreme, but
> doable) built-in op pre-loaded
> at opcode zero. This op's name is "useop", and its arguments give an
> opcode (optable index), and
> sufficent information f
Leopold Toetsch:
# the problem is, that as soon as there are dynamic
# oblibs, they can't
# be run in the CGoto core, which is normally the fastest core, when
# executions time is depending on opcode dispatch time. JIT is (much)
# faster, in almost integer only code, e.g. mops.pasm, but fo
Leo --
Ah. It seems the point of divergence is slow_core vs. cg_core, et al.
As you have figured out, I've been referring to performance of the non-cg,
non-prederef, non-JIT (read: "slow" ;) core.
I don't know much about the CG core, but prederef and JIT should be able
to work with dynamic o
[EMAIL PROTECTED] wrote:
Leo --
... Optable build time is not a function of program
size, but rather of optable size
Ok, I see that, but ...
I don't think it remains a problem how to run ops from different oplibs
_fast_.
the problem is, that as soon as there are dynamic oblibs, th
Leo --
Your concern about speed has been raised before, but I still don't see it
(one of the reasons I've been working on a toy VM to demonstrate is that I
figure there's some piece I'm not communicating well, and being able to
point at code would help). Optable build time is not a function of
My last patch did break runops_slow_core (first instruction got traced)
- fixed.
And finally I found an hopefully sane way, to implement the idea from
#17495:
- stacktop is initially set in test_main
- if running the CGgoto core and it's cleared in interpreter
- in cg_core stacktop get's set aga
[EMAIL PROTECTED] wrote:
Leo --
Here's one of the messages about how I'd like to see us link op
implementations with their op codes:
http://archive.develooper.com/perl6-internals@;perl.org/msg06193.html
Thanks for all these pointers.
I did read this thread WRT dynamic opcode loading. W
Brent Dax wrote:
Leopold Toetsch:
# It's totally sane with the standard copying allocator. But the malloc
# allocator tracks resources (i.e. strings bufstart) only via
# the header.
# So, when you reuse the header, the old bufstart which was
# there before
# is unmanaged and leaks.
Can we a
Leopold Toetsch:
# It's totally sane with the standard copying allocator. But the malloc
# allocator tracks resources (i.e. strings bufstart) only via
# the header.
# So, when you reuse the header, the old bufstart which was
# there before
# is unmanaged and leaks.
Can we add a way to explici
29 matches
Mail list logo
