Dan Sugalski:
# Since it looks like it's time to extend the packfile format and the
# in-memory bytecode layout, this would be the time to start discussing
# metadata. What sorts of metadata do people think are useful to have
# in either the packfile (on disk) or in the bytecode (in memory).
I
Steve Fink wrote:
I'm confused by nci.pmc's mark() routine. It calls pobject_lives() on
the ->cache.struct_val pointer. But in set_string_keyed(), that seems
to be set to a pointer to a function, which is definitely not a PObj*.
Yes, that's right.
The ->data field, on the other hand, appear
Dan Sugalski wrote:
Okay, since this has all come up, here's the scoop from a design
perspective.
Hard stuff did meet my printer at midnight, reading it onscreen twice
didn't help ;-)
First:
Definition #0: A bytecode segment is a sequence of code, which is loaded
into memory with no execut
Benjamin Stuhl wrote:
At 03:00 PM 1/22/2003 -0500, you wrote:
... Although,
all this would seem to suggest that we'd need/want a special-purpose
allocator for bytecode segments, since every sub has to fit within
precisely
one segment (and I know _I'd_ like to keep bytecode segments on their
Dan Sugalski sent the following bits through the ether:
> Also, I know that we do have people scattered all over the world, but
> if someone wants to try and get a list of who's where, we may find
> it's worth it to get groups of people together. (I don't, after all,
> have to be involved... :)
Steve Fink wrote:
I'm confused by nci.pmc's mark() routine.
Ok, nci's mark() is gone.
But - what confuses me - this patch needs a "make progclean" for changes
to take effect. Without default_mark gets called, because I don't know
where, something isn't recompiled.
Argh: pmc->vtable->init o
On Thu, Jan 23, 2003 at 10:23:22AM +, Leon Brocard wrote:
> Latitude:
> Longitude:
You forgot altitude. A proper ICBM block needs altitude :-)
> Useful resources for finding your longitude, latitude:
If you're in the UK you can get lat and long conversions from
http://www.streetmap.co.uk/
Wh
If memory serves me right, Erik Bågfors wrote:
> > :-) Python basically requires that each step in the process be
> > overridable. (1. look up attribute 2. call attribute, at least in
> > `callmethod's case).
would this be more of what you need ?
obj.__dict__["foo"].__call__();
/me again shows
On Thu, 2003-01-23 at 15:46, Gopal V wrote:
> > Ruby needs to call the missing_method method (if I remember correctly).
> > So if "foo" doesn't exist, it would be good to be able to override
> > callmethods behavior and make it call missing_method.
>
> like I said , the compiler designer can put
If memory serves me right, Erik Bågfors wrote:
> But if I write a library in ruby that depends on the missing_method
> method it will not be usable from other languages, since those languages
> doesn't call missing_method if the method they try to call doesn't
> exist.
Hmm... that's twisting lang
On Wed, 22 Jan 2003 13:27:47 +, Dan Sugalski wrote:
> Since it looks like it's time to extend the packfile format and the
> in-memory bytecode layout, this would be the time to start discussing
> metadata. What sorts of metadata do people think are useful to have
> in either the packfile (o
Hello,
after quite a long time away from keyboard and fighting through a huge
backlog of mail I'm (hopefully) back again.
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Since it looks like it's time to extend the packfile format and the
> in-memory bytecode layout, this would be the time to start d
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
> My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (or most of it) can simply be mmap-ed in (RO),
analogously to executables.
--- chromatic <[EMAIL PROTECTED]> wrote:
> On Wed, 22 Jan 2003 13:27:47 +, Dan Sugalski wrote:
>
> > Since it looks like it's time to extend the packfile format and the
>
> > in-memory bytecode layout, this would be the time to start
> discussing
> > metadata. What sorts of metadata do peop
On Wed, Jan 22, 2003 at 03:00:37PM -0500, Dan Sugalski wrote:
> Destinations. These are a pain, since if we can go anywhere then the
> JIT has to do all sorts of nasty and unpleasant things to compensate,
> and to make every op a valid destination. Yuck.
Arbitrary jumps are not that difficult t
> Design Edict #3: All destinations *must* be marked as such in the
> bytecode metadata segment. (I am officially nervous about this, as I
> can see a number of ways to subvert this for evil)
[...]
> Design Edict #4: Dan is officially iffy on jumps, but can see them as
> useful for lower-level s
--- Dave Mitchell <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
> > My current idea for the in memory format of the bytecode is this:
>
> I would strongly urge any file-based byte-code format to arranged
> in such a way that it (or most of it) can
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Okay, since this has all come up, here's the scoop from a design perspective.
>
> First, the branch opcodes (branch, bsr, and the conditionals) are all
> meant for movement within a segment of bytecode. They are *not*
> supposed to leave a segment. To do
At 10:29 PM -0800 1/22/03, James Michael DuPont wrote:
You will probably think that this is overkill for parrot,
Why yes, yes I do. On the other hand, when we hand people bazookas to
deal with their fly problems, we often find they start in on the
elephant problems as well.
The proposal in ge
At 10:10 PM +0530 1/23/03, Gopal V wrote:
If memory serves me right, Erik Bågfors wrote:
But if I write a library in ruby that depends on the missing_method
method it will not be usable from other languages, since those languages
doesn't call missing_method if the method they try to call does
At 12:10 AM -0800 1/23/03, Brent Dax wrote:
Dan Sugalski:
# Since it looks like it's time to extend the packfile format and the
# in-memory bytecode layout, this would be the time to start discussing
# metadata. What sorts of metadata do people think are useful to have
# in either the packfile (on
At 8:42 AM +0100 1/23/03, Erik Bågfors wrote:
On Wed, 2003-01-22 at 19:46, Christopher Armstrong wrote:
On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
> At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
> >But who knows, maybe it could be made modular enough (i.e., more
>
At 1:46 PM -0500 1/22/03, Christopher Armstrong wrote:
On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
>But who knows, maybe it could be made modular enough (i.e., more
>interface-oriented?) to allow the best of both worlds -
At 8:16 PM +0530 1/23/03, Gopal V wrote:
If memory serves me right, Erik Bågfors wrote:
> Ruby needs to call the missing_method method (if I remember correctly).
So if "foo" doesn't exist, it would be good to be able to override
callmethods behavior and make it call missing_method.
like I sa
Dave Mitchell <[EMAIL PROTECTED]> writes:
> On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
> > My current idea for the in memory format of the bytecode is this:
>
> I would strongly urge any file-based byte-code format to arranged
> in such a way that it (or most of it) can sim
At 10:31 PM +0100 1/23/03, Juergen Boemmels wrote:
Dave Mitchell <[EMAIL PROTECTED]> writes:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
> My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
Dan Sugalski <[EMAIL PROTECTED]> writes:
> >This might be possible if the byteorder, wordsize, defaultencoding
> >etc. are the same in the file on disk and the host.
>
> Which will generally be the case, I expect. Tell a sysadmin that they
> can reduce the memory footprint of mod_parrot by 50% by
At 8:39 PM + 1/23/03, Dave Mitchell wrote:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (or most of it) can simply
Dan Sugalski:
# At 12:10 AM -0800 1/23/03, Brent Dax wrote:
# >Dan Sugalski:
# ># Since it looks like it's time to extend the packfile
# format and the #
# >in-memory bytecode layout, this would be the time to start
# discussing #
# >metadata. What sorts of metadata do people think are useful
At 11:48 AM -0800 1/23/03, chromatic wrote:
On Wed, 22 Jan 2003 13:27:47 +, Dan Sugalski wrote:
Since it looks like it's time to extend the packfile format and the
in-memory bytecode layout, this would be the time to start discussing
metadata. What sorts of metadata do people think are us
--- Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Hello,
>
> after quite a long time away from keyboard and fighting through a
> huge
> backlog of mail I'm (hopefully) back again.
>
> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > Since it looks like it's time to extend the packfile format and
At 2:48 PM -0800 1/23/03, Brent Dax wrote:
Dan Sugalski:
# At 12:10 AM -0800 1/23/03, Brent Dax wrote:
# >Dan Sugalski:
# ># Since it looks like it's time to extend the packfile
# format and the #
# >in-memory bytecode layout, this would be the time to start
# discussing #
# >metadata. What sorts
--- Brent Dax <[EMAIL PROTECTED]> wrote:
> Dan Sugalski:
> # At 12:10 AM -0800 1/23/03, Brent Dax wrote:
> # >Dan Sugalski:
> # ># Since it looks like it's time to extend the packfile
> # format and the #
> # >in-memory bytecode layout, this would be the time to start
> # discussing #
> # >met
Dan Sugalski wrote:
Since it looks like it's time to extend the packfile format and the
in-memory bytecode layout, this would be the time to start discussing
metadata. What sorts of metadata do people think are useful to have in
either the packfile (on disk) or in the bytecode (in memory).
I'
Dave Mitchell wrote:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (or most of it) can simply be mmap-ed in (RO),
anal
At 7:23 AM +0100 1/24/03, Leopold Toetsch wrote:
Dave Mitchell wrote:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (
I just gave a run of examples/assembly/mops_p.pasm, getting some
performance numbers. Here's an interesting timing.
no jit: 24.9 seconds
with jit: 33.6 seconds
This is... odd. And on PPC, FWIW, and I'm not sure if it happens on x86.
Someone care to check it out and poke around a bit?
--
37 matches
Mail list logo
