On Sat, Nov 10, 2001 at 12:37:24PM -0500, Dan Sugalski wrote:
I think we're going to switch over to some sort of key creation op, but I'm
not sure at the moment. Constant keys are easy, of course--they can be
thrown up into the constants section, built at compile-time.
Do constants with
At 11:11 PM + 1/28/02, Nicholas Clark wrote:
On Sat, Nov 10, 2001 at 12:37:24PM -0500, Dan Sugalski wrote:
I think we're going to switch over to some sort of key creation op, but I'm
not sure at the moment. Constant keys are easy, of course--they can be
thrown up into the constants
At 10:10 PM 11/13/2001 -0500, Ken Fox wrote:
QUESTIONS!
Who owns the bytecode format? How do I propose changes?
Nobody in particular at the moment, and note your change proposals to
the list.
I need
a scope definition section. Each scope is assigned a per-module
id. I'm not sure what info is
At 03:03 PM 11/12/2001 -0500, Michael L Maraist wrote:
From the above, the only uses I can see for declaring my $foo as int is to
set flags (or utilize different vtables) to enforce integerness, and to say
to the optimizer that it's ok to use a primitive integer if the block
contained a divide.
On Wed, Nov 14, 2001 at 01:11:54PM -0500, Dan Sugalski wrote:
Correction (and please correct this correction if I'm wrong):
An INTVAL should never get a /native/ pointer in it. However, when we do
relitave or absolute jumps in parrot code, the destination is an INTVAL.
Is this really going
Dan Sugalski wrote:
Nope, not stone tablet at all. More a sketch than anything else,
since I'm not sure yet of all the things Larry's got in store.
Ok. I've made some more progress. There's a crude picture of
some of the internals at http://www.msen.com/~fox/parrotguts.png
The lexical stuff is
On Sun, Nov 11, 2001 at 08:57:15PM -0800, Brent Dax wrote:
You get the idea? And as for multidimensional stuff, what's wrong with:
fetchlex P1, @lol
fetchary P2, P1, 1
fetchary P3, P2, 2
#...
Consider (from exegesis 2):
my int @hit_count is dim(100,366,24);
Jason Gloudon
# On Sun, Nov 11, 2001 at 08:57:15PM -0800, Brent Dax wrote:
#
# You get the idea? And as for multidimensional stuff,
# what's wrong with:
#
# fetchlex P1, @lol
# fetchary P2, P1, 1
# fetchary P3, P2, 2
# #...
#
# Consider (from exegesis 2):
#
# my int
On Friday 09 November 2001 03:36 pm, Dan Sugalski wrote:
Do we want non-PMC lexical support?
Nope, I wasn't going to bother. All variables are PMCs. The int/string/num
things are for internal speed hacks.
But can't a compiler generate one of these internal hacks? My thoughts are
that a
On Sat, 10 Nov 2001, Dan Sugalski wrote:
At 01:39 PM 11/9/2001 -0800, Brent Dax wrote:
Dan Sugalski:
Of course. Random question only very tangentially related to this: is
INTVAL (and thus the I registers) supposed to be big enough to hold a
pointer?
INTVAL shouldn't ever get a
Dan Sugalski:
# At 01:39 PM 11/9/2001 -0800, Brent Dax wrote:
# Dan Sugalski:
# # At 12:39 AM 11/9/2001 -0500, Ken Fox wrote:
# # 3. We've adopted a register machine architecture to
# # reduce push/pop stack traffic. Register save/load
# # traffic is similar, but not nearly as bad.
# #
#
At 01:39 PM 11/9/2001 -0800, Brent Dax wrote:
Dan Sugalski:
# At 12:39 AM 11/9/2001 -0500, Ken Fox wrote:
# 3. We've adopted a register machine architecture to
# reduce push/pop stack traffic. Register save/load
# traffic is similar, but not nearly as bad.
#
# Do we want to further
At 12:39 AM 11/9/2001 -0500, Ken Fox wrote:
There are a number of decisions to make about lexicals
and the current PDD is pretty slim. So, IMHO, the place
to start is with the PDD. Anybody have any more thoughts
on the interface? Dan? Is this stone tablet stuff yet?
Nope, not stone tablet at
Dan Sugalski:
# At 12:39 AM 11/9/2001 -0500, Ken Fox wrote:
# There are a number of decisions to make about lexicals
# and the current PDD is pretty slim. So, IMHO, the place
# to start is with the PDD. Anybody have any more thoughts
# on the interface? Dan? Is this stone tablet stuff yet?
#
#
14 matches
Mail list logo
