> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
AB> Uri Guttman wrote:
>> but indexing directly into a stack frame is effectively a register
>> window. the problem is that you need to do an indirection through the
>> window base for every access and that is slow in software (but f
Uri Guttman wrote:
> but indexing directly into a stack frame is effectively a register
> window. the problem is that you need to do an indirection through the
> window base for every access and that is slow in software (but free in
> hardware).
Not quite - a register window system has real regi
Nick Ing-Simmons wrote:
> >That comment reminds me of how the register file is implemented in
> >a sun sparc. They have a large register file, but only some are accessable
> >at any given time, say 16.
>
> 32 IIRC but principle is correct.
8 global registers, 8 out registers, 8 local registers
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> "We" need to decide where a perl6 sub's local variables are going
NI> to live (in the recursive case) - if we need a "stack" anyway it
NI> may make sense for VM to have ways of indexing the local "frame"
NI> rather than having
--- Garrett Goebel <[EMAIL PROTECTED]> wrote:
> Then what's the use of using object methods to override properties?
It's funny that the discussion should go this way. From way back in the
beginning, I got the impression that properties were temporary hacks,
and object methods would be the des
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> [I'm taking these all at once, so bear with me]
DS> Simon wrote:
>> Register based. Untyped registers; I'm hoping that the vtable stuff can be
>> sufficiently optimized that there'll be no major win in storing multiple
>> copie
From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]]
> On Tue, May 22, 2001 at 10:10:55AM -0500, Garrett Goebel wrote:
> > What is UNIVERSAL::can($foo, 'new') going to return if
> > there is a variable and/or value property 'new' set
> > on $foo?
>
> undef if there is no "new" method.
Then what
Dave Mitchell writes:
>> I've been meaning for a while to sit down and thoroughly go through sv.c
>> to understand and document it. So, consider sv.c 'grabbed'; if no-one's
>> done av.c and sv.c in the meantime, I may get round to them too.
> ^
> hv.c of course.
D
[I'm taking these all at once, so bear with me]
Simon wrote:
>Register based. Untyped registers; I'm hoping that the vtable stuff can be
>sufficiently optimized that there'll be no major win in storing multiple
>copies of a PMC's data in different types knocking around.
Maybe, but I'm thinking t
Graham Barr <[EMAIL PROTECTED]> writes:
>On Wed, May 23, 2001 at 10:30:32AM -0700, Hong Zhang wrote:
>> I think "stack based =~ register based". If we don't have Java-like "jsr"
>
>That comment reminds me of how the register file is implemented in
>a sun sparc. They have a large register file, bu
On Wed, May 23, 2001 at 01:36:14PM -0400, Bryan C. Warnock wrote:
> You could certainly call PL_undef and the ilk (in its new
> PMC form) a dedicated register
Which is, incidentally, exactly what happens in disassembled Perl 5 bytecode.
--
"Why waste negative entropy on comments, when you coul
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
GB> On Wed, May 23, 2001 at 10:30:32AM -0700, Hong Zhang wrote:
>> I think "stack based =~ register based". If we don't have Java-like "jsr"
GB> That comment reminds me of how the register file is implemented in
GB> a sun sparc. They
On Wed, May 23, 2001 at 10:30:32AM -0700, Hong Zhang wrote:
> I think "stack based =~ register based". If we don't have Java-like "jsr"
That comment reminds me of how the register file is implemented in
a sun sparc. They have a large register file, but only some are accessable
at any given time,
On Wed, May 23, 2001 at 06:06:26PM +0100, Simon Cozens wrote:
> On Wed, May 23, 2001 at 12:59:01PM -0400, Dan Sugalski wrote:
> > Should Parrot be a register or stack-based system, and if a register-based
> > one, should we go with typed registers?
>
> Register based. Untyped registers; I'm hopi
At 12:59 PM 05-23-2001 -0400, Dan Sugalski wrote:
>Okay, folks, here's the current conundrum:
>
>Should Parrot be a register or stack-based system, and if a register-based
>one, should we go with typed registers?
>My current thoughts are this:
>
>We have a set of N registers. They're all linke
On Wednesday 23 May 2001 12:59, Dan Sugalski wrote:
> Okay, folks, here's the current conundrum:
>
> Should Parrot be a register or stack-based system, and if a register-based
> one, should we go with typed registers?
>
> My personal preference here is to make Parrot a register based system. I
> c
> Register based. Untyped registers; I'm hoping that the vtable stuff can be
> sufficiently optimized that there'll be no major win in
> storing multiple copies of a PMC's data in different types knocking
around.
>
> For those yet to be convinced by the benefits of registers over stacks,
try
>
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Should Parrot be a register or stack-based system, and if a
DS> register-based one, should we go with typed registers?
first question: is this for the intermediate language or the back end
VM? they don't have to be the same.
since o
> Okay, folks, here's the current conundrum:
>
> Should Parrot be a register or stack-based system, and if a register-based
> one, should we go with typed registers?
For low-level assembly, registers are important because using them
avoids memory accesses. For high-level perl 6 bytecode, I supp
On Wed, May 23, 2001 at 06:04:17PM +0100, Dave Mitchell wrote:
> > I've been meaning for a while to sit down and thoroughly go through sv.c
> > to understand and document it. So, consider sv.c 'grabbed'; if no-one's
> > done av.c and sv.c in the meantime, I may get round to them too.
>
On Wed, May 23, 2001 at 12:59:01PM -0400, Dan Sugalski wrote:
> Should Parrot be a register or stack-based system, and if a register-based
> one, should we go with typed registers?
Register based. Untyped registers; I'm hoping that the vtable stuff can be
sufficiently optimized that there'll be
> I've been meaning for a while to sit down and thoroughly go through sv.c
> to understand and document it. So, consider sv.c 'grabbed'; if no-one's
> done av.c and sv.c in the meantime, I may get round to them too.
^
hv.c of course.
> If anyone wants to do some really useful work, they can scout through
> sv.c, av.c and hv.c, and summarise the functions that Perl 5 expects to
> be able to perform on scalars, arrays and hashes.
I've been meaning for a while to sit down and thoroughly go through sv.c
to understand and document
Okay, folks, here's the current conundrum:
Should Parrot be a register or stack-based system, and if a register-based
one, should we go with typed registers?
My personal preference here is to make Parrot a register based system. I
can wrap my head around that a lot easier than a stack system,
24 matches
Mail list logo
