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
brian wheeler:
# Is this really necessary? Seems like a chicken-and-egg
# thing: to know which chuck the directory is in, you need to
# read the directory.
# However, since you've defined that the first chunk (0) is
# always the directory, there's really no need to have it in
# the directory
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
> #
At 11:46 AM +0100 10/29/02, Juergen Boemmels wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
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, wit
[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
# > everything after position X (for some value of X) left u
Dan Sugalski <[EMAIL PROTECTED]> writes:
> 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
> everything after position X (for some value of
At 10:44 PM -0700 10/25/02, Brent Dax wrote:
I was thinking in terms of what TYPE: stores; it seems you were thinking
about how you identify a particular segment. Yeah, you can probably get
away with just numbering the segments, although that might slow things
down a bit when you're looking for a
"Brent Dax" <[EMAIL PROTECTED]> writes:
> Dan Sugalski:
> # Huh? No, you misunderstand. Each chunk of the bytecode has a separate
> # TOC for stuff like this. The full identifier would be
> # file/chunk/entry, which should be reasonably guaranteed to be unique.
> # When the compiler's emitting
If memory serves me right, Dan Sugalski wrote:
> Huh? No, you misunderstand. Each chunk of the bytecode has a separate
> TOC for stuff like this. The full identifier would be
> file/chunk/entry, which should be reasonably guaranteed to be unique.
> When the compiler's emitting code to reference
Dan Sugalski:
# Huh? No, you misunderstand. Each chunk of the bytecode has a separate
# TOC for stuff like this. The full identifier would be
# file/chunk/entry, which should be reasonably guaranteed to be unique.
# When the compiler's emitting code to reference a piece of binary data
# (which
At 9:13 AM +1000 10/26/02, Rhys Weatherley wrote:
Dan Sugalski wrote:
># Instead, lets just give an entry number. We can have arbitrary data
># chunk #1, #2, #3, and so on. I'm not sure it'll buy us much having
># names attached.
>
>What happens if two tools (say, a custom debugger and the
Dan Sugalski wrote:
> ># Instead, lets just give an entry number. We can have arbitrary data
> ># chunk #1, #2, #3, and so on. I'm not sure it'll buy us much having
> ># names attached.
> >
> >What happens if two tools (say, a custom debugger and the Perl compiler)
> >both use the same segment num
At 12:23 PM +0200 10/25/02, Juergen Boemmels wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
[imcc...]
>>>* Bytecode format
> ... We could use existing ELF tools to, at the very least,
> provide test result verification.
This is an argument. If we get e.g. bsr fixup at load time done
At 12:30 PM -0700 10/25/02, Brent Dax wrote:
Dan Sugalski:
# I'm thinking something else, actually. Names made perfect sense
# except for encoding info and duplication. We can put limits on the
# name encoding if we want, but... really, who cares? It's only useful
# for introspection purposes and
Dan Sugalski:
# I'm thinking something else, actually. Names made perfect sense
# except for encoding info and duplication. We can put limits on the
# name encoding if we want, but... really, who cares? It's only useful
# for introspection purposes and while that's certainly important, I'm
# no
At 5:28 PM +0200 10/24/02, Juergen Boemmels wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
>The ability to embed arbitrary data in a pbc file under a
>named section. This data needs to be readable by the program
>when it runs, but is otherwise ignored by the rest of Parrot.
Right, good ca
Leopold Toetsch <[EMAIL PROTECTED]> writes:
[imcc...]
> >>>* Bytecode format
>
>
> > ... We could use existing ELF tools to, at the very least,
> > provide test result verification.
>
>
> This is an argument. If we get e.g. bsr fixup at load time done by the
> elf loader, it would be nice.
>
Steve Fink wrote:
On Oct-24, Leopold Toetsch wrote:
... is there anything perl-specific about PerlInt?
PerlNum?
This depends. The PerlScalars change there types on demand.
add PerlInt, PerlInt, PerlNum
changes the type of the LHS to a PerlNum. Other languages might prefer
to round the
Steve Fink wrote:
On Oct-23, Leopold Toetsch wrote:
we could look at usage patterns and finally decide, what to do.
(Who could extend the assembler?)
Sounds good to me. But it does suggest a question -- are there any
compelling reasons to preserve the separate assembler?
Macros, currentl
On Oct-24, Leopold Toetsch wrote:
> Steve Fink wrote:
>
>
> >... If not, then just
> >renaming it to Undef seems best.
>
> I had a closer look at it. Just renaming doesn't: PerlUndef is derived
> from PerlInt, which provides major funtionality for it.
>
> If this syllable "Perl" is really a p
On Oct-23, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> >I suppose I ought to try to wrap up a release one of these days.
>
>
> > - Artificial goal: I want the list of pending patches to be smaller
> >than one screenfull before I release. Fortunately, I have a large
> >screen.
>
> I
Dan Sugalski <[EMAIL PROTECTED]> writes:
> >The ability to embed arbitrary data in a pbc file under a
> >named section. This data needs to be readable by the program
> >when it runs, but is otherwise ignored by the rest of Parrot.
>
> Right, good call. This'll make perl's named embedded filehand
Steve Fink wrote:
... If not, then just
renaming it to Undef seems best.
I had a closer look at it. Just renaming doesn't: PerlUndef is derived
from PerlInt, which provides major funtionality for it.
If this syllable "Perl" is really a problem, I will reorganize them
again i a more hierar
On Thu, 24 Oct 2002, Leopold Toetsch wrote:
> Andy Dougherty wrote:
>
> > Types:
> > iv=long long, intvalsize=8, intsize=4, opcode_t=long long, opcode_t_size=8,
> > ptrsize=4, ptr_alignment=4 byteorder=87654321,
> The INTVAL2PTR and PTR2INTVAL macros should take care of such a
> con
Steve Fink wrote:
On Oct-23, Dan Sugalski wrote:
It'd probably be a good idea for us to have a generic undef.pmc for
undefined usage.
Yes, that's what I was saying. Sorry the comment was vague -- all I
meant was that general Parrot PMCs should not be creating
Perl-specific PMCs. I agree co
Steve Fink wrote:
Prerequisites for 0.0.9 release
---
* Reclaim the tinderbox!
On one machine I suddenly have additionally:
Failed Test Status Wstat Total Fail Failed List of failed
---
Andy Dougherty wrote:
Types:
iv=long long, intvalsize=8, intsize=4, opcode_t=long long, opcode_t_size=8,
ptrsize=4, ptr_alignment=4 byteorder=87654321,
The INTVAL2PTR and PTR2INTVAL macros should take care of such a
configuration. Though I'm not to sure, if we can get rid of all th
On Oct-23, Dan Sugalski wrote:
> At 7:41 PM +0200 10/23/02, Leopold Toetsch wrote:
> >>Possible (feature/architectural) goals for 0.0.9
> >>
> >>* PMC cleanup
> >> - Leo did a huge amount of work on this, but there are a few things
> >> left:
> >>
Steve Fink:
# - requires sprintf* to work on PPC. (Brent -- what's the status?)
Dan said that he would give me an account on a PPC machine so I could
debug this, but that hasn't happened yet.
# * Exceptions
# - I haven't been paying much attention to developments on this,
# alth
At 7:43 AM +1000 10/24/02, Rhys Weatherley wrote:
Steve Fink wrote:
- Stratospheric rehydrocalibration amplifiers for the .NET people
(er... or something; I can't remember what they needed)
The ability to embed arbitrary data in a pbc file under a
named section. This data needs to
Steve Fink wrote:
> - Stratospheric rehydrocalibration amplifiers for the .NET people
> (er... or something; I can't remember what they needed)
The ability to embed arbitrary data in a pbc file under a
named section. This data needs to be readable by the program
when it runs, but is ot
At 7:41 PM +0200 10/23/02, Leopold Toetsch wrote:
Possible (feature/architectural) goals for 0.0.9
* PMC cleanup
- Leo did a huge amount of work on this, but there are a few things left:
- array.pmc still autocreates something called "PerlUndef"
On Wed, 23 Oct 2002, Steve Fink wrote:
> I suppose I ought to try to wrap up a release one of these days. I've
> been thinking about the possibilities, but I'm not sure about the
> current state of a couple of things. And what I'd most like to see
> right now is some stabilization. So I'll list my
In message <[EMAIL PROTECTED]>
Steve Fink <[EMAIL PROTECTED]> wrote:
> * Keyed access
> - Another discussion that's gone over my head. Leo has a scheme to
> dramatically reduce the number of instructions, at the cost of
> requiring a couple of opcodes for keyed accesses; Dan sa
Steve Fink wrote:
I suppose I ought to try to wrap up a release one of these days.
- Artificial goal: I want the list of pending patches to be smaller
than one screenfull before I release. Fortunately, I have a large
screen.
I did set 2 of them to "Applied". I'll wade through my
35 matches
Mail list logo
