Dan --
[snip]
> I'll have to snag that manual next time I'm around a good bookstore. I've
> not read it as of yet, and Knuth generally has good things to say.
You can grab PDFs here:
http://link.springer.de/link/service/series/0558/tocs/t1750.htm
Of course, you can also browse around on Knuth's site for other related
stuff...
http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html
> A split between local, marginal, and global registers would be an
> interesting thing to do, and I can see it making the code more elegant. I
> worry about it making things more complex, though, especially with us
> already having multiple register types. (We'd double or triple the number
> of register types essentially, and to some extent blow cache even more than
> we do now. Might be a win in other ways, though. I'll have to ponder a bit)
Yeah, I didn't like the idea of proliferating that more either. I still
sometimes dream about a single register file of N regs into which we can
put whatever we want. Each block of registers has room for the reg
contents and the type info too. Seems you've got some of the support for
that figured out in the stack already. Just declare that either (a) it
is illegal (or behavior undefined) to do
set $2, 5
set $3, "foo bar"
add $1, $2, $3
[just because we have higher-level data types than a "real" machine
doesn't mean we can't still have general-purpose registers, I think]
or (b) that if you do something numeric with a register that is
non-numeric type mucking happens behind the scenes and throws an
exception if there is a problem. Certainly this wouldn't be surprising
to anyone who had been looking at what we do with PMCs and arithmetic
ops.
If we ever did move to such a single-register-file model, I'd support
looking seriously at the calling conventions of MMIX to see if we can
get the appropriate performance characteristics. And, BTW, we have
4*32 = 128 regs now. We could even match the logical register count
of MMIX (256) with only a doubling of total register count. And, if
we ever determined we needed another kind of register (such as one
that can be used for address arithmetic, since INTVAL doesn't cut it),
we wouldn't have to add a fifth file, we'd just add another type
(thinking again about the stack implementation).
[snip]
> >Yeah. I'm trying very hard not to put anything really sophisticated
> >into jakoc (at least not yet). Right now I can still tweak things
> >reasonably well. If I add much more complexity, I'm going to have
> >to actually write a real compiler, and if I write a real compiler I
> >probably won't be able to resist the temptation to turn Jako into the
> >language I *really* wish I had, and that would be a bigger project.
>
> And this would be a bad thing because? (Well, besides the demands on what
> little free time you might have now, but that's not our problem... :)
It might be a bad thing because Jako would then not be a little demo
language. I suppose I could start from scratch, but then I'd have to
come up with another language name (oh the horrors!)
[snip]
Regards,
-- Gregor
_____________________________________________________________________
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_____________________________________________________________________/
