One of the interesting side-effects of a copying collector is that we can't
inherently determine which objects need to be destructed (their memory space
just gets reused without notifying anyone). I'm already looking to use some
algorithms that utilize linked-lists to determine set-association
On Tuesday 04 December 2001 12:21 am, David M. Lloyd wrote:
> He was telling me about the way PHP seperates the interpreter from
> the OS-specific stuff via a SAPI layer.
Facinating, but perl is, afterall a scripting language first. perl -e ''
is very essential; though I could see a compati
On Sunday 02 December 2001 02:47 pm, Brent Dax wrote:
> Quick comment: I've been thinking about constructing an 'OpaqueHandle'
> PMC type. All the programmer is supposed to know about it is that it
> points to Something (usually a C struct, but they don't have to know
> that). I'm not sure what
On Thursday 15 November 2001 02:11 pm, James Mastros wrote:
> I don't see doing it with a macro as too bad, so long as the macro is
> decently localized. (If you don't like macros because of their
> preprocessor nature, use a function; it should inline just fine.) And it
> seems like it would be
Combining these two, I have a couple comments.
On Thursday 15 November 2001 02:07 pm, Simon Cozens wrote:
> if (pmc->flags & PS_INTEGER_OK) {
> return ((struct PerlScalarData *)(pmc->data))->intdata;
Why are you storing flags for PerlScalarData inside the pmc-flags? If the
nested type i
On Thursday 15 November 2001 07:53 am, Ken Fox wrote:
> Shlomi Fish wrote:
> > For instance, we can have a "ret-with-call" opcode. However, isn't it
> > exactly the same as a jump instruction ?
>
> No. The current scope must be destroyed, lexicals destroyed, localized
> globals restored, etc. It's
On Tuesday 13 November 2001 06:37 pm, James Mastros wrote:
> On Tue, Nov 13, 2001 at 06:14:30PM -0500, Michael L Maraist wrote:
> > Extending mem-mngr data-structures (like the linked-list) to the
> > definition of a PMC is what I'm worried about; not exposing a function t
On Tuesday 13 November 2001 03:57 pm, James Mastros wrote:
> > Unfortunately, this would require hooks into the mem-mngr module, which
> > violates it's black-box nature. Not to mention the points you make.
>
> I don't really see this as ownerous fiddiling with the memory manager; we
> want to ha
On Tuesday 13 November 2001 01:20 pm, Jason Gloudon wrote:
> On Mon, Nov 12, 2001 at 11:59:08PM -0500, Michael L Maraist wrote:
> > 2)
> > Can we assume that a "buffer object" is ONLY accessible by a single
> > reverse-path-to-PMC? PMC's or array-buffers c
On Tuesday 13 November 2001 12:05 pm, Ken Fox wrote:
> > Are _all_ handles (PMC's, Strings, or whatever) that serve as
> > root-set elements dynamically allocated?
>
> Nope. Part of the root set includes auto C PMC handles used by
> extensions. You also have to think about hardware registers too
>
Dan gave a list a bit ago about some minimal assumptions about how we'll deal
with memory. I've been researching various memory management techniques, and
I'm noticing that various optimizations can occur if certain assumptions are
made.. It's still early in the game, but I thought it might be
On Friday 09 November 2001 03:36 pm, Dan Sugalski wrote:
> > Do we want non-PMC lexical support?
>
> Nope, I wasn't going to bother. All variables are PMCs. The int/string/num
> things are for internal speed hacks.
But can't a compiler generate one of these "internal hacks"? My thoughts are
On Sunday 04 November 2001 10:59 pm, Zach Lipton wrote:
> I'm working on learning some parrot asm, but if I write something like
> this:
>
> set N0,2
> set N1,2
> add N3, N0, N1
> print N3
>
>
> I get:
>
> 4.00
>
> Is there any way to round this, or at least chop the 0's off the end?
since pr
On Sunday 04 November 2001 02:39 pm, Dan Sugalski wrote:
> At 08:32 PM 11/4/2001 +0100, Benoit Cerrina wrote:
> > > There will be a mechanism to register PMCs with the interpreter to note
> > > they're pointed to by something that the interpreter can't reach. (For
> > > example, a structure in you
On Sunday 04 November 2001 03:36 pm, Benoit Cerrina wrote:
> > While the PMC structures themselves don't move (no real need--there of
> > fixed size so you can't fragment your allocation pool, though it makes
>
> Sorry can you expand on this. I don't see the relation between the data
> being fixe
On Friday 02 November 2001 05:27 pm, Dan Sugalski wrote:
> 1) The pointer in a PMC structure may point to:
>
>*) Another PMC
>*) A buffer object
>*) Something non-tracked
>
> Additionally the buffer object may contain array of buffer object pointers,
> or an array of PMC pointers. Flag
On Friday 02 November 2001 01:33 am, Uri Guttman wrote:
>
> dan at his recent talk at boston.pm's tech meeting said he was leaning
> towards a copying GC scheme. this would be the split ram in half design
> and copy all objects to the other half at CG time. the old half is
> reclaimed (not even re
> According to an old 486 book I have, it claims
> that complex addressing modes don't have cycle
> penalties for leaving out the scale or the offset.
> That seems hard to believe for the RISC-like
> P3s and Athalons.
x4 is just a bit offset, so it shouldn't be hard to believe that the pentium+
On Thursday 01 November 2001 09:08 pm, Ken Fox wrote:
> Michael L Maraist wrote:
> [an incredible amount of detailed information that will
> take me weeks to digest...]
>
> This looks like a malloc/free style allocator. Since the whole
> GC system for Parrot is on the table,
I just noticed that we're not using any tags in the CVS tree. Do you think
that we're at a state where we could start applying labels to our code. I am
considering two types of labels. One for the periodic snapshots (so as to
back-trace features in those files), and one for successful smoke-
> My intial impression is that a page should be 1024 bytes (though I'm also
> looking at 512 bytes to reduce the shotgun effect of 8-byte allocs).
> I've actually found that "q-caches" were detramental to things like
> conslidation, and the calling depth (overhead) of a worst-case allocation.
> S
This references the previously posted (by someone else) article on SUN's libu
memory architecture. If needed I can run through the archives and find the
URL.
I've already written a threaded implementation which has a decent
responsiveness. It did as much as the SUN libu claimed that it would
On Tuesday 30 October 2001 01:47 am, Ken Fox wrote:
> Uri Guttman wrote:
> > that is good. i wasn't disagreeing with your alternative architecture.
> > i was just making sure that the priority was execution over compilation
> > speed.
>
> I use a snazzy quintuple-pass object-oriented assembler wri
> Absolutely. Compile-and-go is an absolute must, and one that'll end up
> disabling most of the potential optimizations for sheer startup time
> reasons. Which is a pity, but we can always let people enable them if they
> want from the command line.
Or via "use flags", since mod_perl and the l
>
> > A split between local, marginal, and global registers would be an
> > interesting thing to do, and I can see it making the code more elegant. I
> > worry about it making things more complex, though, especially with us
> > already having multiple register types. (We'd double or triple the num
On Wednesday 24 October 2001 08:28 pm, you wrote:
> Ive just spent some time looking through the various RFCs for Perl 6.
>
> IMHO: The various proposals dealing with multi threading, synchronization
> and RPC can be solved in a different way.
>
> Instead of thinking about multiple threads, one
Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>
>
> DS> Ask has found us a spot for the paper Alan was speaking of.
>
> DS> http://dev.perl.org/perl6/talks/
>
> very impressive paper. my recent proposal for a multi-queue malloc
> system has some of the ideas o
"Gregor N. Purdy" wrote:
> Michael --
>
> > I had more time to think about it, and I determined how a compute op-code
> > could be efficient.
> >
> > [snip]
>
> You wicked, wicked person! :)
>
> I'd like to see some benchmarks on that one vs. the most efficient
> possible hand-coded separate ops
Michael Maraist wrote:
> > All --
> >
> > > I've created a varargs-ish example by making a new op, print_s_v.
> > > This is pretty rough, and I haven't updated the assembler, but it
> > > seems to work.
>
>
> With var-args, we could produce highly efficient SIMD instructions.
> printf obviously,
Wizard wrote:
> Michael Maraist [mailto:[EMAIL PROTECTED]] wrote:
> > Does you idea allow for:
> > int msgid = txtToMsgid( "This feels strange\n" );
> > char *label = msgidToRes( msgid );
>
> I'm not sure that I understand your question. This is not my idea, but GNU's
> gettext tools. I, myself,
Arthur Bergman wrote:
> > Arthur Bergman wrote:
> >
> > > In an effort to rest my braine from a coredumping perl5 I started to think a bit
>on threading under parrot?
> > >
> > > While it has been decided that perl should be using ithread like threading, I
>guess that is irelevant at the parrot
>
>
> What we're going to do is fire up a new interpreter for each thread. (We
> may have a pool of prebuilt interpreters hanging around for this
> eventuality) Threading *is* essential at the parrot level, and there are
> even a few (as yet undocumented) opcodes to deal with them, and some stuff
Arthur Bergman wrote:
> In an effort to rest my braine from a coredumping perl5 I started to think a bit on
>threading under parrot?
>
> While it has been decided that perl should be using ithread like threading, I guess
>that is irelevant at the parrot level. Are you
> going to have one "virtu
The internal do-op-loop runs until it sees a return value of zero from any
op-codes. The RETURN statement within basic_opcodes.ops is really a keyword
which gets parsed into an offset of the current PC counter based on the
internally calculated size of the instruction (known at Configure time fro
34 matches
Mail list logo
