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
On Fri, Oct 25, 2002 at 01:01:16PM +0100, Nicholas Clark wrote:
> What is wrong with any of
>
> 1: Duplicating the above loop (which isn't large), one for upwards stack,
>the other for downwards stack, and switching (outside) between the two
>based on an if statement on a global stack dir
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 9:15 PM +1000 10/25/02, Rhys Weatherley wrote:
I was just having a look at the packfile format code, and I
have a suggestion on load-time performance of the code segment.
Currently, you read the file, parse out the various sections,
copy them elsewhere in memory, and byte-swap as necessary.
Th
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 wrote:
Attached is a test program showing some features, how a PMC could look
like in the future.
Arg mozilla did show it.
Leopold Toetsch wrote:
> Attached is a test program showing some features, how a PMC could look
> like in the future.
and where's the attachment?
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
I did ci 2 changes:
- headers.c was a little bit to drastic in stressing the system.
e.g. t/op/stacks_4 ran just out of mem after allocating 800K new_blocks.
- spf_vtable did use string_make (with BUFFER_external_FLAG) after my
patch, both are wrong. string_copy i.e. make a COW string - is the
On Fri, Oct 25, 2002 at 09:15:07PM +1000, Rhys Weatherley wrote:
> A "trick" that I've found very useful in the past is to design
> the bytecode format so that it can be mmap'ed into a block of
> memory, and then executed almost immediately with the minimum
> number of fixups. Rather than copying
On Fri, Oct 25, 2002 at 07:55:45AM -0400, Bryan C. Warnock wrote:
> On Thu, 2002-10-24 at 19:15, Robert Spier wrote:
> > -R (pondering his next move in the unending war against spam)
>
> Nukes.
my thoughts entirely
> --
> Bryan C. Warnock
> bwarnock@(gtemail.net|raba.com)
When the spammers fig
On Thu, Oct 24, 2002 at 06:16:55PM -0400, Jason Gloudon wrote:
> On Thu, Oct 24, 2002 at 04:47:05PM -0400, Josh Wilmes wrote:
> > It shouldn't at all. It does the check once, when parrot starts up.
>
> It will. If you read the following paragraph I explained why it will be slower,
> and it has n
On Thu, 2002-10-24 at 19:15, Robert Spier wrote:
>
> Obviously spam, sorry folks.
>
> It snuck in under the spam filters.
>
> X-Spam-Status: No, hits=5.3 required=7.0
>
>tests=CARRIAGE_RETURNS,FORGED_HOTMAIL_RCVD,MISSING_HEADERS,NORMAL_HTTP_TO_IP,NO_REAL_NAME,SPAM_PHRASE_00_01,TO_EMPTY
> versio
I was just having a look at the packfile format code, and I
have a suggestion on load-time performance of the code segment.
Currently, you read the file, parse out the various sections,
copy them elsewhere in memory, and byte-swap as necessary.
The overhead of doing this could be quite significant
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.
>
Attached is a test program showing some features, how a PMC could look
like in the future.
1)
PMCs/Buffer are both based on the same bufferlike structure - I called
it Pobj (Parrot Object)
- There is no need, that all PMCs are of same size, the bufferlike code
in smallobjects.c / headers.c take
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-24, Leopold Toetsch wrote:
Thanks! It's a little scary how fast you are.
This depends on the RL work I've waiting to be done. The more is in the
queue (especially putting invoices together for the revenue office), the
more I'll code parrot stuff ;-)
leo
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-24, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> > - the various unions should probably be coalesced into one
>
> I did check in my datatypes patch.
> - all? native and other data types are summarized in datatypes.h
> - hash and list use the same enums now
> - datatype.c has currently 2
24 matches
Mail list logo
