> The data which needs to be stored along with the buffer data, can be
> stored as either a header or a footer. The size of this header needs to be
> a multiple of 16 (or possibly even 8) bytes, so that the real buffer
> which follows would be correctly aligned. I'm not sure if this applies for
>
]- me too .
|I actually like Andy Wardly's suggestion of iterators. It makes a lot of
|sense and looks a lot cleaner to read and write and adds less new syntax
|to remember (and parse).
|
|Clayton
raptor
> Clint brought a small assembler string but to my attention, and I found
> another bug while fixing the first. Bugs were:
> a) 'a"b"c' was turned into 'a[sc:1]c' before being turned into [sc:2]
> b) 'a\"b' was printing being stored as a\"b and not a"b
There was some discussion about this, but no
Minor patch. Our mem_allocate currently allocates too much memory. It
rounds up to the next 16 bytes if we are currently in the middle, but if
we are on a 16 byte boundary, it rounds up to the next 16 bytes.
This patch removes those extra 16 bytes of allocation, and simplifies our
copy_size logic
On Sun, 28 Apr 2002, Mike Lambert wrote:
> > Clint brought a small assembler string but to my attention, and I found
> > another bug while fixing the first. Bugs were:
> > a) 'a"b"c' was turned into 'a[sc:1]c' before being turned into [sc:2]
> > b) 'a\"b' was printing being stored as a\"b and n
At 8:32 AM -0400 4/26/02, Melvin Smith wrote:
>I might take a look at 3&4 this weekend if I can finish moving.
I thought you were busy getting married and honeymooning and such? I
do *not* want to be responsible for your SO having to find a
convenient place to dump your body... :)
>Concerning
At 7:00 AM +0100 4/27/02, Piers Cawley wrote:
>Andrew J Bromage <[EMAIL PROTECTED]> writes:
>
>> G'day all.
>>
>> On Fri, Apr 26, 2002 at 08:16:27AM -0400, Melvin Smith wrote:
>>
>>> I also vote for reserving some caller-save registers to make
>>> arg passing faster, however, reserving 16 is p
At 9:45 PM -0700 4/21/02, Chip Salzenberg wrote:
>According to Simon Glover:
>> I've made a start on fixing this, and other breaches of encapsulation,
>> with my recent patch to perlstring.pmc, but I've been loathe to go
>> any further until I get some feedback from Dan and/or Jeff about
>>
At 1:51 PM +0200 4/28/02, Peter Gibbs wrote:
> > The data which needs to be stored along with the buffer data, can be
>> stored as either a header or a footer. The size of this header needs to be
>> a multiple of 16 (or possibly even 8) bytes, so that the real buffer
>> which follows would be
Dan Sugalski wrote:
> So, let's do this:
>
> 1) We'll add allocate_string and reallocate_string functions, which
> the strings use. It'll give us COW space at the end of the string
> data.
>
> 2) We'll add in new_*_const_header to match the new_*_header
> functions, to allocate String/Buffer/PMC
Dan Sugalski writes:
>Okay, the first draft of PDD3, calling conventions, is in. Sync up,
>rip in, and let fly... :)
Also available on the website, http://dev.perl.org/perl6/pdd/, updated
daily.
-R
On Sun, Apr 28, 2002 at 12:18:19PM -0400, Dan Sugalski wrote:
> As for the closeout thing, what I'm thinking of is a way to say "This
> stack frame is complete" and start a new frame, even if there's still
> space left in the stack chunk. Doing this makes continuations and
> co-routines easier.
At 3:55 PM -0700 4/28/02, Steve Fink wrote:
>On Sun, Apr 28, 2002 at 12:18:19PM -0400, Dan Sugalski wrote:
>> As for the closeout thing, what I'm thinking of is a way to say "This
>> stack frame is complete" and start a new frame, even if there's still
>> space left in the stack chunk. Doing th
On Sat, Apr 27, 2002 at 05:06:08PM -0400, Mike Lambert wrote:
> > For (1), maybe we should add an opcode: get_number_of_live_objects?
> > Then you could write a test case that records the number of live
> > objects, does stuff, forces a sweep and collect, and checks that the
> > saved number + #ex
G'day all.
On Sat, Apr 27, 2002 at 07:00:17AM +0100, Piers Cawley wrote:
> I'm trying to see how, if you want genuine continuations and/or tail
> call optimization, you're going to get away with anything but 'caller
> saves everything important to it', and what do you know, I
> can't.
If you ha
G'day all.
On Sun, Apr 28, 2002 at 11:44:04AM -0400, Dan Sugalski wrote:
> We're going caller-save. I think I made this declaration before, but
> now it's backed up with pure PDD goodness. :)
The first thing to realise is that this violates the principle of
"callee does everything important t
MIPSPro is unhappy:
http://tinderbox.perl.org/tinderbox/showlog.cgi?log=parrot/1020037080.95964.gz
--
At 12:18 PM 4/28/2002 -0400, Dan Sugalski wrote:
>At 8:32 AM -0400 4/26/02, Melvin Smith wrote:
>>I might take a look at 3&4 this weekend if I can finish moving.
>
>I thought you were busy getting married and honeymooning and such? I do
>*not* want to be responsible for your SO having to find a c
At 11:44 AM 4/28/2002 -0400, Dan Sugalski wrote:
>At 7:00 AM +0100 4/27/02, Piers Cawley wrote:
>>Andrew J Bromage <[EMAIL PROTECTED]> writes:
>>
>>> G'day all.
>>>
>>> On Fri, Apr 26, 2002 at 08:16:27AM -0400, Melvin Smith wrote:
>>>
I also vote for reserving some caller-save registers to
G'day all.
On Sun, Apr 28, 2002 at 09:49:35PM -0400, Melvin Smith wrote:
> I don't think I and Andrew were saying we shouldn't do caller-save, we
> were just discussing that the calling convention (read activation record of
> a subroutine) should support the common optimization of passing args
>
And a long time coming...
An assembler supporting keyed aggregates. Because of the current lack of
macro support (that will be added in a few days), it's not built by
default and isn't invoked in the test suite.
To build the new assembler, type 'make newasm'. All this target really
does is run t
At 12:09 PM 4/29/2002 +1000, Andrew J Bromage wrote:
>G'day all.
>
>On Sun, Apr 28, 2002 at 09:49:35PM -0400, Melvin Smith wrote:
>
> > I don't think I and Andrew were saying we shouldn't do caller-save, we
> > were just discussing that the calling convention (read activation record of
> > a subro
G'day all.
On Sun, Apr 28, 2002 at 10:26:12PM -0400, Melvin Smith wrote:
> Ok, agreed. Sorry for speaking for you.
Not a problem. Having people try to speak for you can actually
clarify your thoughts, or so I've found.
> Regarding performance, a decent compiler should be able to
> analyze a m
According to Dan Sugalski:
> Actually (as I dig through my mail backlog) PMCs look Topaz-like
> because of Topaz.
Cool beans. I knew that work was for something. :-)
> (I'm not actually sure if any of Parrot's design is ultimately
> original to me. I think pretty much all of it has been lift
I'd have to agree with Andrew. With only 32 registers of each type in
Parrot (the last time I checked) using most of them for function arguments
would cause much needless register copying within each function.
Surely 8 registers of each type would be more than sufficient for
function paramet
25 matches
Mail list logo
