Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Elian (119)

Elian
  (email not shown publicly)
http://www.sidhe.org/~dan/
AOL IM: DanSugalski (Add Buddy, Send Message)

Perl 6/Parrot internals ex-design team lead.

Journal of Elian (119)

Wednesday May 23, 2001
11:41 AM

Registers, registers, who's got the registers?

[ #201 ]
I've been contemplating registers lately. Perl's interpreter has always been a stack-based one, and that's fine, but I'm really wanting Parrot's (AKA "The perl 6 interpreter") model to be register based rather than stack based. And yes, for those of you who're keeping track, the internals of perl 6 are tending more towards that of a CPU than software. Consider Parrot to be a VAX (with all the extensions) on steroids.

That's fine, as far as it goes, but then it brings up the next question--what sort of registers? Should they hold only PMCs? Should there be multiple types, like most modern CPUs do? (The separate intger and float register sets, for those of you that don't hit the metal) I'm currently thinking a set of integer, float, string, and PMC registers, but... should they be independent? Linked? Should the int & float registers be able to hold both normal and big types? (Or should they be split?)

Decisions, decisions...

And, of course, there's always the question of whether this is the right tack to take anyway. Some of the reasons registers are best for hardware don't really apply to software based CPUs (no pipeline, no processing multiple instructions at once, no real performance hit going off-chip), and the reasons for a stack-based software architectures aren't that compelling either. (Simplicity for one--simple is nice, fast is nicer)

Ah, well, something to chew on for perl6-internals, I think.