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,
> 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
> 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.
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
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.
>
> 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
> "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
> 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
>
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
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 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
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,
> "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 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
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
[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
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
> "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
> "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
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
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
> "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
22 matches
Mail list logo
