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
> can wrap my head around that a lot easier than a stack system, it's
> something I'm comfortable with, there's lots of literature on optimizing
> this sort of system, and I just generally like it better. (I cut my
> programming teeth on 6502s... so sue me :) Stack based systems have a
> certain appeal--they're simpler generally, which is fine. I'm not too
> worried about simpler as much as I am faster, and I think we can get
> faster out of registers. (Or, if you prefer, "named temporaries" instead
> of registers. Whatever)
>
> If (or when, I suppose, barring a Really Good Counter-Argument) we go the
> register route, then, should we have typed registers like most CPUs do? A
> set of PMC pointer registers, a set of integer registers, a set of
> floating-point registers, a set of string registers? And if we do go with
> typed registers, should they be linked together? (So that the int in
> Iregister 1 matches the integer value of the PMC in Pregister 1, and the
> float value in Fregister 1?) And if they're linked (And should they all be
> linked, or only some of them) should we guarantee consistency, or should
> the bytecode explicitly make various registers valid or invalid?
A little backwards my answer will be. I'm fairly sure we won't need linked
registers. The PMC's vtable implemention should already take care of the
int/float/string cross-referencing - by having the linked registers, you'd
really only be creating a parallel structure to wade through. Worse case,
you're doing both - using the vtable to create the values for the other
registers. (After checking the register first to see if it were valid?)
That doesn't sound like a win at all. You could bypass the PMC's vtable and
populate the registers directly, but then why have the PMC. I don't see any
reason for the linking.
Now, assuming I'm not way out in the left-field stands above, I don't see
the necessity for typed registers (at least as described). (I mean, one of
the major reasons for typed registers is for hardware optimization, which we
can't really borrow. We're emulating that win with the vtables.) However,
another common use for registers is to save on allocation - like a hardware
zero register. You could certainly call PL_undef and the ilk (in its new
PMC form) a dedicated register, which means it's sort of type. But I think
you still make a save if you automatically assume that every register is
simply a PMC.
The only use I could think of would be for constants that you know aren't
going to need to be converted from one form to another. But then you need
to handle the two paths in the rest of your vtable entries. Unless you make
everything run through the registers.
Your not going to make opcodes {shudder} dependent on implicit registers,
are you? :-)
--
Bryan C. Warnock
[EMAIL PROTECTED]
