Re: The core platforms list
On Tue, Sep 18, 2001 at 02:43:07PM -0400, Dan Sugalski wrote: Okay, folks, the following platforms are considered core for the parrot interpreter. That means we need to run on all of them for any release of the interpreter to be considerd OK. They are: [...] Solaris (Sparc) 32 bit, 64 bit or both? Phil -- Philip Kendall [EMAIL PROTECTED] http://www.srcf.ucam.org/~pak21/
Re: parrot compilation failure in Tru64
On Sat, Sep 15, 2001 at 06:33:18PM +0100, Simon Cozens wrote: We also need to think about endianness. Urgh. This is something I ought to seek consensus on. (And possibly a ruling from Dan.) Do we *expect* Parrot bytecode to be portable? My gut reaction would be to say no, but I can see the arguments either way. My personal view would be that the gains due to portable bytecode would be outweighed by the amount of cruft we'd have to put into the interpreter to get them. As Nicholas Clark and someone else who's name I've forgotten[1] mentioned, there are platforms (eg Cray) which don't have a native 32-bit integer type. OTOH, my impression is that Dan is favouring at least some sort of bytecode portability. Phil -- Philip Kendall [EMAIL PROTECTED] http://www.srcf.ucam.org/~pak21/
Re: Using int32_t instead of IV for code
On Thu, Sep 13, 2001 at 06:38:56PM -0400, Dan Sugalski wrote: I was thinking more that we'd have a type OP for opcodes, for example. #typedef'd to int, or long, or int32_t, but conceptually standalone so we could change it if need be. (The possibility still exists that we might shrink to 16 bit opcodes...) That should be possible from my patch just by replacing all occurences of `int32_t' with `OP' (and then getting something into the configure system to set the typedef). Phil -- Philip Kendall [EMAIL PROTECTED] http://www.srcf.ucam.org/~pak21/
Re: Using int32_t instead of IV for code
On Wed, Sep 12, 2001 at 10:03:55PM -0400, Dan Sugalski wrote: At 05:06 PM 9/12/2001 -0700, Hong Zhang wrote: I think we should use int32_t instead of IV for all code related data. Absolutely. Using an IV was a quick answer to get things working--a first draft if you will. It needs rewriting so all the ops are I32 and the floating point constants are N64s. If we are going to keep on doing fancy stuff with pointer arithmetic (eg the Alloc_Aligned/CHUNK_BASE stuff), I think we're also going to need an integer type which is guaranteed to be the same width as a pointer, so we can freely typecast between the two. Also, if we've got a system with 64 bit IVs, are the arguments to Parrot opcodes going to be 32 or 64 bit? If 32 bit, is there going to be any way of loading a 64 bit constant? Phil -- Philip Kendall [EMAIL PROTECTED] http://www.srcf.ucam.org/~pak21/
config.h.in
Two small changes to config.h.in:
* Actually use ${nv} for the numeric type, rather than `${iv} double'.
* Make MASK_CHUNK_LOW_BITS 64 bit clean.
Phil
Index: config.h.in
===
RCS file: /home/perlcvs/parrot/config.h.in,v
retrieving revision 1.1
diff -u -r1.1 config.h.in
--- config.h.in 2001/09/11 09:44:00 1.1
+++ config.h.in 2001/09/13 09:44:10
@@ -7,7 +7,7 @@
#if !defined(PARROT_CONFIG_H_GUARD)
#define PARROT_CONFIG_H_GUARD
typedef ${iv} IV;
-typedef ${iv} double NV;
+typedef ${nv} NV;
typedef struct _vtable VTABLE;
typedef void DPOINTER;
@@ -22,7 +22,7 @@
#define FRAMES_PER_INT_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_STR_REG_CHUNK FRAMES_PER_CHUNK
-#define MASK_CHUNK_LOW_BITS 0xf000
+#define MASK_CHUNK_LOW_BITS ((IV)~0x0fff)
${headers}
Re: Parrot coredumps on Solaris 8
On Tue, Sep 11, 2001 at 10:23:51AM -0700, Daniel Sully wrote: [Parrot coredumps on Solaris] It also coredumps on Solaris 7, when running the test2.pbc - test.pbc is fine. The coredump doesn't show much, only that it keeled over at interpreter.c line 16, which is the while() loop. That was the padding problem, which is now fixed in CVS (Brian Wheeler's patch in http://archive.develooper.com/perl6-internals%40perl.org/msg03844.html ) test3.pbc is still segfaulting on me though. Phil -- Philip Kendall [EMAIL PROTECTED] http://www.srcf.ucam.org/~pak21/
Re: Parrot coredumps on Solaris 8
On Wed, Sep 12, 2001 at 09:24:06AM -0400, Dan Sugalski wrote: At 12:18 PM 9/12/2001 +0100, Simon Cozens wrote: On Wed, Sep 12, 2001 at 12:11:35PM +0100, Philip Kendall wrote: test3.pbc is still segfaulting on me though. Yes, it is here too; I've sent some debugging info to Dan and he's having a look at it. I'm trying to take a look at it too. I suspect that CHUNK_BASE isn't doing what it should. CHUNK_BASE was OK, it was Allocate_Aligned that was broken. That and the problems with the assembler generating odd code that's now been fixed. I think we're OK now--sync up with CVS and see if that's the case. Now works on Solaris and i386, but segfaults at the GRAB_IV call in read_constants_table on my Alpha. Problems with the integer-pointer conversions in memory.c? (line 29 is giving me a warning). Phil -- Philip Kendall [EMAIL PROTECTED] http://www.srcf.ucam.org/~pak21/
Re: Parrot coredumps on Solaris 8
On Wed, Sep 12, 2001 at 09:45:42AM -0400, Dan Sugalski wrote: At 02:40 PM 9/12/2001 +0100, Philip Kendall wrote: On Wed, Sep 12, 2001 at 09:24:06AM -0400, Dan Sugalski wrote: CHUNK_BASE was OK, it was Allocate_Aligned that was broken. That and the problems with the assembler generating odd code that's now been fixed. I think we're OK now--sync up with CVS and see if that's the case. Now works on Solaris and i386, but segfaults at the GRAB_IV call in read_constants_table on my Alpha. Problems with the integer-pointer conversions in memory.c? (line 29 is giving me a warning). You've got 64-bit ints and pointers? Or are the ints 32 bits? I haven't abused things enough to run on my VMS Alpha boxes recently. ints are 32 bit, but IVs and pointers are both 64 bit. I've just backed out the changes to memory.c and it still segfaults in the same place; make of that what you will... The machine's at the wrong end of a dialup link at the moment, but I'll have a trash at this when I get home this evening (BST). Phil -- Philip Kendall [EMAIL PROTECTED] http://www.srcf.ucam.org/~pak21/
Parrot coredumps on Alpha (Was: Parrot coredumps on Solaris 8)
On Wed, Sep 12, 2001 at 02:54:49PM +0100, Philip Kendall wrote:
On Wed, Sep 12, 2001 at 09:45:42AM -0400, Dan Sugalski wrote:
At 02:40 PM 9/12/2001 +0100, Philip Kendall wrote:
Now works on Solaris and i386, but segfaults at the GRAB_IV call in
read_constants_table on my Alpha. Problems with the integer-pointer
conversions in memory.c? (line 29 is giving me a warning).
You've got 64-bit ints and pointers? Or are the ints 32 bits? I haven't
abused things enough to run on my VMS Alpha boxes recently.
ints are 32 bit, but IVs and pointers are both 64 bit. I've just backed
out the changes to memory.c and it still segfaults in the same place;
make of that what you will...
Quick research reveals the obvious problem: even when IVs are 64 bit,
assemble.pl is still 32 bit (as $pack_types{i} is the 32-bit type 'l').
Changing this over to 'q' means I get further, but it's still
segfaulting further in, which I'll look at in a bit.
Are we going to try and support 32 bit IVs on machines with 64 bit
pointers? If so, all the places in the code where pointers are typecast
to IVs are clearly going to blow everything up in a hurry...
In the short to medium term, should Configure.pl modify the behaviour of
assemble.pl such that it produces the correct sized bytecode? Also, is
there going to be a mechanism to identify if we're trying to run
bytecode with the wrong sized and/or endianness words?
Cheers,
Phil
--
Philip Kendall [EMAIL PROTECTED]
http://www.srcf.ucam.org/~pak21/
Re: Parrot coredumps on Alpha (Was: Parrot coredumps on Solaris 8)
On Wed, Sep 12, 2001 at 07:21:06PM +0100, Philip Kendall wrote:
[Coredumps on Alpha]
Quick research reveals the obvious problem: even when IVs are 64 bit,
assemble.pl is still 32 bit (as $pack_types{i} is the 32-bit type 'l').
Changing this over to 'q' means I get further, but it's still
segfaulting further in, which I'll look at in a bit.
OK... further research reveals more assembler problems, one 64 bit
problem and something I'm not sure about...
* Assembler: the `l' in %pack_type, all the `i's in %real_type and the
`l' on line 86 all need to be `q' to give us 64 bit words everywhere.
This is just a bodge fix as it breaks 32 bit stuff.
* 64 bit problem: in config.h, MASK_CHUNK_LOW_BITS is defined as
0xf000, which isn't going to work for machines with 64 bit
pointers. Is (~(IV)0x0fff) a portable replacement?
* The trickier one: with the above two changes, test and test2 work,
but test3 tries to pop a non-existent stack frame. In Parrot_pop_i,
should the fragment:
if (chunk_base-prev) {
/* Do so. We don't need to adjust used/free, since they're
already OK for the We're full case */
chunk_base = chunk_base-prev;
interpreter-int_reg = chunk_base-IReg[chunk_base-used];
}
actually be:
if (chunk_base-prev) {
/* Do so. We don't need to adjust used/free, since they're
already OK for the We're full case */
chunk_base = chunk_base-prev;
interpreter-int_reg = chunk_base-IReg[chunk_base-used - 1];
}
If chunk_base-used == 1, I think we want chunk_base-IReg[0], not
chunk_base-IReg[1]?? (but I'll happily admit I haven't got my head
around the memory management yet). Similar considerations apply to the
other Parrot_pop_? functions.
Apologies for any stupidity...
Phil
--
Philip Kendall [EMAIL PROTECTED]
http://www.srcf.ucam.org/~pak21/
Parrot coredumps on Solaris 8
/lurk Hi. I've just tried getting Parrot running on a Solaris 8 box here, but it's coredumping on me with test2.pasm and test3.pasm: cass87:pak:~/data2/parrot$ ./test_prog test.pbc I reg 1 is 1000206849 I reg 5 is 1000206859 I reg 2 is 1000 I reg 2 is 10 I reg 4 is 3000 N reg 1 is 3000.00 I reg 2 is 10 N reg 2 is 10.00 N reg 1 is 300.00 cass87:pak:~/data2/parrot$ perl assemble.pl t/test2.pasm test2.pbc cass87:pak:~/data2/parrot$ ./test_prog test2.pbc Bus Error cass87:pak:~/data2/parrot$ perl assemble.pl t/test3.pasm test3.pbc cass87:pak:~/data2/parrot$ ./test_prog test3.pbc I reg 1 is 0 Segmentation Fault This is apparently consistent across various Solaris boxes here; the machine above is: cass87:pak:~/data2/parrot$ uname -a SunOS cass87 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-5_10 Has anyone else seen this behaviour, or am I going to have to do some digging? Cheers, Phil -- Philip Kendall [EMAIL PROTECTED] http://www.srcf.ucam.org/~pak21/
