On Wed, Dec 18, 2002 at 03:11:59AM +, Bruce Gray wrote:
2) PTR_SIZE == INTVAL_SIZE == LONG_SIZE (x86 Linux and Win32)
Intermediate casts to (unsigned long) removed, i.e.
(any)(unsigned long)(d)
becomes
(any)(d)
Under MS VC++ for .Net, this patch changes the results of
none
On Tue, Dec 17, 2002 at 11:49:50PM -0800, Steve Fink wrote:
As a more concrete demonstration of what I'm talking about, here's an
implementiation of the easy part: the pinning and releasing macros.
(UNPIN would probably be better than RELEASE, huh?) It's a naive
implementation with a low fixed
Steve Fink wrote:
(UNPIN would probably be better than RELEASE, huh?)
Maybe ATTACH / DETACH or AQUIRE / RELEASE?
A
The Perl Summary for the week ending 20021215
Hi, and welcome to the first summary prepared on my shiny second hand
TiBook (no, it wasn't a gift from a grateful summary reader, it was
bought from a friend who was upgrading, gifts from grateful summary
readers are, of course, still
We have indeed gone through this before. The last time the dominant argument
was that these types of mark/unmark operations can be mis-used just as readily
as malloc/free, because the programmer has to know when and where to call them.
I'm just repeating this for everyone's benefit, not giving an
On Tue, Dec 17, 2002 at 09:40:26AM +0100, Leopold Toetsch wrote:
Tracking this further down would need some extensive debug sessions on
this machine, which would currently imply to prepare pasm's w/o macros
and empty lines.
Aha. But say I cut it down to this:
set N1, 0.0
What's the cleanest way to return a new PMC from an op?
e.g. Suppose I have a Vec2D_in_X_plane and a Vec2D_in_Y_plane and I add them
and want to always produce a Vec3D - is this correct (and is it efficient?):
void add(PMC* value, PMC* dest) {
if(value-vtable ==
David Robins wrote:
What's the cleanest way to return a new PMC from an op?
e.g. Suppose I have a Vec2D_in_X_plane and a Vec2D_in_Y_plane and I add them
and want to always produce a Vec3D - is this correct (and is it efficient?):
void add(PMC* value, PMC* dest) {
if(value-vtable ==
Marco Baringer wrote:
speaking of compiling directly to pbc, parrotbyte.pod says that number
constants should be encoded as FLOATVALs, which is a system dependant
careteristic, shouldn't there be a specified format for floats? ie
either ieee single/double float or, preferably, the number segment
Steve Fink wrote:
I propose that we have configure probes for the variations that we can
support, but have everything else (including miniparrot) fall back to
a registration scheme. In other words, whenever you allocate a
collectible pointer and don't immediately anchor it to something, you
Nicholas Clark wrote:
On Tue, Dec 17, 2002 at 09:40:26AM +0100, Leopold Toetsch wrote:
what would your response be? :-)
dddp (s. docs/jit.pod)
[if I remove either the set N1, or the sub N2, the answer is correct in the
JIT]
Register allocation problem WRT K5
Nicholas Clark
leo
On Wed, 18 Dec 2002, Leopold Toetsch wrote:
David Robins wrote:
if(value-vtable == Parrot_base_vtables[enum_class_Vec2D_in_Y_plane]) {
always compare ids (vtables may change) - yes, many pmc's do like above,
but will need changes too.
What do you mean by ids? pmc-type()?
PMC*
Looking at some of the test failures, I see several instances where
t/src/sprintf test 1 is failing because
printf(0x%x, (int) -1) is 0x
but
Parrot_sprintf(%08vd, (INTVAL) -1) is 0x
Except that the latter seems correct to me, for a 64-bit platform.
For now, I'm
David Robins wrote:
On Wed, 18 Dec 2002, Leopold Toetsch wrote:
always compare ids (vtables may change) - yes, many pmc's do like above,
but will need changes too.
What do you mean by ids? pmc-type()?
Yes, -vtable-type().
morph dest to be a ret?
unimplemented, unused, but your
14 matches
Mail list logo
