If memory serves me right, Leopold Toetsch wrote:
> I'm - as stated in the thread - for a new register type (L, long).
I'm thinking of virtual registers here... ie
if sizeof(INTVAL) == 4
'L' is a PMC
else if sizeof(INTVAL) == 8
'L' is an INTVAL
So 64 bit opcodes are compiled in
I would expect a large majority of parrot subroutines to *not* use all
four register types.
How difficult would it be to make imcc detect when less than 4 register
types were used in a subroutine, and replace a call to "saveall" with an
appropriate combination of "pushi", "pushs", "pushp", and "pu
[slightly rearranged]
Dan Sugalski wrote:
[snip]
> 2) Make some way to gang together I registers to make 64 bit things
[snip]
> I don't like option 2, since it means that we speed-penalize 64 bit
> systems, which seems foolish.
I think that it could be done in a way that doesn't significantly
pea
All~
# sweep 0 is lazy
# sweep 1 is unconditional
Perhaps we should use
sweep 0 is unconditional
sweep -1 is lazy
sweep x is the top x generations (if supported, lazy otherwise)
That would make it easier to add a generational GC later...
Matt
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> *) Opcodes are limited to 32 bits so we have full bytecode
> portability. While defining an opcode number past 2 billion is
> utterly insane, we don't require that there be no holes in the opcode
> numbers,
Huh, what did I miss here:
# define DO_OP(PC,IN
[As I snip out all this stuff]
Okay, after reading the thread, I think some explanations and notes
are in order.
*) Opcodes are limited to 32 bits so we have full bytecode
portability. While defining an opcode number past 2 billion is
utterly insane, we don't require that there be no holes in
This is the first of some changes, before pmc->data can be moved
into the PMC_EXT structure.
While digging through the classes and
:perldo s/(\w+)->data/PMC_data($1)/g
some notes are accumulating:
- CSub seems to be unused and is AFAIK obsoleted by NCI
- Pointer should probably also get deleted.
JüRgen" "BöMmels <[EMAIL PROTECTED]> wrote:
> In many places in the code we use the idiom
> PIO_fprintf(interpreter, PIO_STDERR(interpreter), ...);
> But there is a function for doing exactly this
> PIO_eprintf(interpreter, ...);
Thanks, applied.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 5:47 PM +0200 5/21/03, Leopold Toetsch wrote:
>> PObj_needs_early_DOD_FLAG
>> interpreter->has_early_DOD_PMCs
>>
>> # sweep 0 is lazy
>> # sweep 1 is unconditional
>> op sweep(inconst INT) {
> Works. The DOD can also set it to 1, thus avoidin
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #22592]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22592 >
These patches are a follow-up to the exploration and proposal
http://nntp.x.perl.
> -Original Message-
> From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
[snip]
> I see. Yes, this shorthand is fine, the more that it will be used
> heavily. What about:
>
> invokecc the_sub_label
>
> which would include constructing the subroutine object in P0 too?
This would be co
Leopold Toetsch wrote:
Jonathan Sillito <[EMAIL PROTECTED]> wrote:
We need them. Parrot calling conventions are not the only convention we
have. And for parrot calling conventions you have to save registers too.
I was not suggesting that we not save registers, just that we use a context
object
Leo, thanks for the answer.
It confirms my initial understanding of the alocation. But the line of
my original message was more like "IF there is a bug, this code will
not uncover it, even though it is supposed to".
On to finding where @ARGV is found at interpreter start time; and how
to set a
So finally the patch went in.
Here is a summary of changes:
Configure System
- tests for posix_memalign and memalign, the former has priority
- if neither is found, ARENA_DOD_FLAGS gets disabled
- platform function prototypes are in platform_interface.h now
PMC layout
- metadata, synchronize and ne
14 matches
Mail list logo
