[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

BOUNCE ll1-discuss@ai.mit.edu: Non-member submission from ["Brent Dax" <brentdax@cpan.org>]

>From gregs@ai.mit.edu  Mon Dec  3 12:13:08 2001
Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [])
	by life.ai.mit.edu (8.9.3/8.9.3/AI2.13/ai.master.life:2.21) with ESMTP id MAA21300
	for <ll1-discuss@ai.mit.edu>; Mon, 3 Dec 2001 12:13:08 -0500 (EST)
Received: from hsa071.pool011.at001.earthlink.net ([] helo=deepblue)
	by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1)
	id 16AweL-0004Q2-00; Mon, 03 Dec 2001 09:13:01 -0800
From: "Brent Dax" <brentdax@cpan.org>
To: "Terrence Brannon" <metaperl@mac.com>, <perl6-internals@perl.org>
Cc: <ll1-discuss@ai.mit.edu>
Subject: RE: basic parrot questions
Date: Mon, 3 Dec 2001 09:18:06 -0800
MIME-Version: 1.0
Content-Type: text/plain;
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <23304D80-E80B-11D5-8997-003065C2A10C@mac.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

Terrence Brannon:
# Why would a software machine closely emulating CISC architecture
# be expected to execute as efficiently on RISC and CISC machines?

We're not necessarily expecting it to run as efficiently.  We're just
expecting it to run efficiently enough.

# Does it make any sense to create a low-level machine modeled on
# one-architecture instead of a high-level architecture which can
# flexibly optimize to either architecture?

Yes, because we've tried higher-level machines and were always either
killed by stack thrash or other issues uniquely destructive to a
high-level machine's operation, or buried in complicated code.
Optimizers are good, but they still can't recognize a stack machine when
they see one.  :^)

We don't expect to have our architecture map directly on to the physical
architecture of any machine.  We don't expect any machine to have 128
registers, 64 of which are pointers, 32 ints and 32 floats.  Registers
are basically just conveniently numbered slots in memory.

# Also, I thought Parrot was not "stack-based" If that is the case
# then why does Overview.pod say this:
# "Registers will be stored in register frames, which can be pushed and
# popped onto the register stack. For instance, a subroutine or a block
# might need its own register frame."

That's just a convenience in case you manage to fill up the registers
and need s'more.  Many architectures have something like this--IIRC
Sparc (I think it's Sparc, but I'm not sure) has a way to 'rotate' the
register set and get the first half of the registers moved to the last
half of the slots; the first half of the slots are then filled with
fresh registers.  But Sparc (or whatever it is) is definitely a
register-based architecture.  We actually do have a data stack too, for
passing arguments that won't fit in the first five registers or for
saving data for later--we're still register-based because most of our
operations are on registers.

--Brent Dax
Configure pumpking for Perl 6

"Nothing important happened today."
    --George III of England's diary entry for 4-Jul-1776