[Fwd: a warning and a failure for parrot in Tru64]
Leopold Toetsch
-------- Original Message --------
Subject: a warning and a failure for parrot in Tru64
Date: Thu, 31 Mar 2005 20:41:30 +0300
From: Jarkko Hietaniemi <j...@iki.fi>
To: Leopold Toetsch <l...@toetsch.at>
cc: Warning: pylist.pmc, line 601: In this statement, the referenced
type of the pointer value "value" is "struct PMC", which is not
compatible with "struct List". (ptrmismatch)^M
list_splice(interpreter, list, value, start, end-start);^M
---------------------------------------^
And all of md5.t fail, here's the first one:
t/library/md5..................# Failed test (t/library/md5.t at
line 31)^M
# got: '0725ab1dfe30df5f1f20d44a53159406^M
# 4b3b7a24af37bc4091d9d60dcfe9deac^M
# 875790f4f6efec1f4f96ed0e21866559^M
# a444b9826bdc2ca5e1dca89f155225a9^M
# '^M
# expected: '8b1a9953c4611296a827abf8c47804d7^M
# 6fc422233a40a75a1f028e11c3cd1140^M
# e7cb1e977e896954fec46d2ea7832072^M
# ed076287532e86365e841e92bfc50d8c^M
# '^M
--
Jarkko Hietaniemi <j...@iki.fi> http://www.iki.fi/jhi/ "There is this special
biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
Nick Glencross
>
>
> -------- Original Message --------
> Subject: a warning and a failure for parrot in Tru64
> Date: Thu, 31 Mar 2005 20:41:30 +0300
> From: Jarkko Hietaniemi <j...@iki.fi>
> To: Leopold Toetsch <l...@toetsch.at>
>
> cc: Warning: pylist.pmc, line 601: In this statement, the referenced
> type of the pointer value "value" is "struct PMC", which is not
> compatible with "struct List". (ptrmismatch)^M
> list_splice(interpreter, list, value, start, end-start);^M
> ---------------------------------------^
>
> And all of md5.t fail, here's the first one:
>
> t/library/md5..................# Failed test (t/library/md5.t at
> line 31)^M
> # got: '0725ab1dfe30df5f1f20d44a53159406^M
> # 4b3b7a24af37bc4091d9d60dcfe9deac^M
> # 875790f4f6efec1f4f96ed0e21866559^M
> # a444b9826bdc2ca5e1dca89f155225a9^M
> # '^M
> # expected: '8b1a9953c4611296a827abf8c47804d7^M
> # 6fc422233a40a75a1f028e11c3cd1140^M
> # e7cb1e977e896954fec46d2ea7832072^M
> # ed076287532e86365e841e92bfc50d8c^M
> # '^M
Having never had access to a Tru64 system, does that mean that parrot is
compiled 64 bit?
Two initial comments:
* This is a platform that we've not had a chance to test on, so I'm
grateful to see it tested on a new platform. It was hoped that it would
work, but to stop the test failing it was supposed to skip them until
formally tested. Why did the skipping not work though? What would the
intsize attribute be (from config_lib.pasm I guess)
* Secondly, any chance I can get access to other platforms, such as
this one, to troubleshoot the problem? If not, perhaps I can instrument
the code and have the results sent back to me...
Cheers,
Nick
Nick Glencross
> Having never had access to a Tru64 system, does that mean that parrot
> is compiled 64 bit?
>
> Two initial comments:
>
> * This is a platform that we've not had a chance to test on, so I'm
> grateful to see it tested on a new platform. It was hoped that it
> would work, but to stop the test failing it was supposed to skip them
> until formally tested. Why did the skipping not work though? What
> would the intsize attribute be (from config_lib.pasm I guess)
>
> * Secondly, any chance I can get access to other platforms, such as
> this one, to troubleshoot the problem? If not, perhaps I can
> instrument the code and have the results sent back to me...
>
> Cheers,
>
> Nick
There have been updates have been made to the md5 library and tests; great!
Leo: There's a gremlin in the onload routine related to endianess.
Although the endian register is correct, it doesn't now set the global
on big endian systems... Might be worth moving the store_global after
the is_little_endian label.
I'm also attaching an instrumented version of
runtime/parrot/library/Digest/MD5.imc, so if you've got a 64-bit or big
endian system, perhaps you could try the following with this updated file:
nickg@scrappy parrot $ md5sum ABI_CHANGES
84195669527b120240cdd20a02edd63b ABI_CHANGES
./parrot examples/assembly/md5sum.imc ABI_CHANGES > md5.log
If the last line of this log file doesn't say 8419... then send me
details of your platform, and the logfile.
Thanks in advance,
Nick Glencross
MrJoltCola
>Having never had access to a Tru64 system, does that mean that parrot is
>compiled 64 bit?
>
>Two initial comments:
>
> * This is a platform that we've not had a chance to test on, so I'm
> grateful to see it tested on a new platform. It was hoped that it would
> work, but to stop the test failing it was supposed to skip them until
> formally tested. Why did the skipping not work though? What would the
> intsize attribute be (from config_lib.pasm I guess)
Not true. We've done successful compiles before on Tru64. Maybe as of 0.0.6
or something but
we were using Compaq's testdrive system and 64-bit gcc. At one time Parrot
dir run on
both 64-bit Sparc and Alpha and I tested all these when doing the
byte-ordering code.
> * Secondly, any chance I can get access to other platforms, such as
> this one, to troubleshoot the problem? If not, perhaps I can instrument
> the code and have the results sent back to me...
Check out and see if testdrive is still available. I don't even remember
the IPs or account info, nor do
I remember the URL to go to but you can get free shell accounts if they
still offer it. Also, I had set
up an S/390 account at IBM for Daniel way back when and did a succesful
compile there, but we
never got the JIT written and it fell off the map.
-Melvin
Nick Glencross
> At 06:33 AM 4/1/2005, Nick Glencross wrote:
>
>> Having never had access to a Tru64 system, does that mean that parrot
>> is compiled 64 bit?
>>
>> Two initial comments:
>>
>> * This is a platform that we've not had a chance to test on, so I'm
>> grateful to see it tested on a new platform. It was hoped that it
>> would work, but to stop the test failing it was supposed to skip them
>> until formally tested. Why did the skipping not work though? What
>> would the intsize attribute be (from config_lib.pasm I guess)
>
>
> Not true. We've done successful compiles before on Tru64. Maybe as of
> 0.0.6 or something but
> we were using Compaq's testdrive system and 64-bit gcc. At one time
> Parrot dir run on
> both 64-bit Sparc and Alpha and I tested all these when doing the
> byte-ordering code.
I'm sorry, I was slightly unclear. I was talking specifically about the
MD5 library running on parrot, not parrot itself.
> * Secondly, any chance I can get access to other platforms, such as
> this one, to troubleshoot the problem? If not, perhaps I can
> instrument the code and have the results sent back to me...
There was a follow up posting with a version of MD5.imc with some prints
in, so even if I can be sent some results, I can work out where the
problems lie. It's certainly strange that the tests failed, instead of
being skipped...
Cheers,
Nick
Jarkko Hietaniemi
> Not true. We've done successful compiles before on Tru64. Maybe as of 0.0.6
True, not true :-) I do manual test compiles in Tru64 once in a while.
Once the packfile portability problems were solved back when, the Parrot
core at least has been pretty good regarding 64-bitness.
Tru64 is 64-bit little-endian, with longsize=ptrsize=8 intsize=4
(shortsize=2).
P.S. (I wish I still had Cray 90 access, the unusual-but-legal
longsize=ptrsize=intsize=shortsize=8 nicely shook bugs to the bright
light of day in Perl 5.)
Nick Glencross
Jay Scherrer wrote:
> Attached is my make test output from my laptop running Fedora Core 3
> x86_64bit: makeTest.txt
> Is there any other way I can help?
>
Thanks for that Jay. What's happened is that in the last week a new test
has gone into CVS, but I haven't had access to systems besides an i386
to test it, which is why it will be skipped on unfamiliar platforms.
It's the 3rd md5 test which is new, and the one that I am interested in
making sure works:
t/library/dumper...............ok
t/library/getopt_long..........ok
t/library/md5..................ok <--
t/library/parrotlib............ok
...
If you can get a newer parrot (from CVS or rsync'd), then I would be
grateful if you could try the following.
$ md5sum ABI_CHANGES
84195669527b120240cdd20a02edd63b ABI_CHANGES
$ ./parrot examples/assembly/md5sum.imc ABI_CHANGES
84195669527b120240cdd20a02edd63b ABI_CHANGES
You'll probably get a warning that you're on a 64-system, but if the
checksums are the same, then I can remove the warning, and enable the test.
Thanks in advance,
Nick
Nick Glencross
>>Not true. We've done successful compiles before on Tru64. Maybe as of 0.0.6
>>
>>
>
>True, not true :-) I do manual test compiles in Tru64 once in a while.
>Once the packfile portability problems were solved back when, the Parrot
>core at least has been pretty good regarding 64-bitness.
>
>Tru64 is 64-bit little-endian, with longsize=ptrsize=8 intsize=4
>(shortsize=2).
>
>P.S. (I wish I still had Cray 90 access, the unusual-but-legal
>longsize=ptrsize=intsize=shortsize=8 nicely shook bugs to the bright
>light of day in Perl 5.)
>
>
Ok, so intsize=4, which is why my md5 test tried to run. I'd be really
grateful if some could run my instrumented MD5.imc from a previous post
on this platform.
So what I'm confused about is why intsize=4 when you say the Parrot core
is 64 bit. Isn't one of the points of a 64-bit processor to have larger
ints (often accompanied by larger address space)? So if ints are just 4
bytes, what would trip things up on Tru64?
There are a few reasons why I'm keen to get this resolved. 1) My
assumption that intsize!=4 for 64-bit processors is broken, which is why
the test is seen to fail. 2) I would like the library to work on all
platforms. 3) I'm curious to know why it doesn't work, as it was
expected to work on different endianess and word size. 4) the md5
library has been, and hopefully will continue to be, a good way to shake
problems out of the parrot core.
Thanks all,
Nick
Jarkko Hietaniemi
> Jarkko Hietaniemi wrote:
>
>
>>>Not true. We've done successful compiles before on Tru64. Maybe as of 0.0.6
>>>
> Ok, so intsize=4, which is why my md5 test tried to run. I'd be really
> grateful if some could run my instrumented MD5.imc from a previous post
> on this platform.
>
> So what I'm confused about is why intsize=4 when you say the Parrot core
> is 64 bit.
Weelll... I did not say *quite* that. What I said that so far the
Parrot's core seems to have worked well in systems with _some_ 64-bit
integer types available. So the Parrot core has been 64-bit _safe_,
which doesn't mean it has been _using_ 64-bit integers explicitly
(e.g. in Tru64 it has been using 64-bit longs implicitly).
> Isn't one of the points of a 64-bit processor to have larger
> ints (often accompanied by larger address space)? So if ints are just 4
The 64-bit type can be int, long, long long, quad_t, int64_t, ...
> bytes, what would trip things up on Tru64?
>
> There are a few reasons why I'm keen to get this resolved. 1) My
> assumption that intsize!=4 for 64-bit processors is broken, which is why
Please do not assume such things. The only thing C promises in this
regard is that sizeof(int) <= sizeof(long). 4 <= 8, or 8 <= 8
(or 4 <= 4 in the 32-bit world.) See e.g.
http://www.unix.org/version2/whatsnew/lp64_wp.html
> the test is seen to fail. 2) I would like the library to work on all
> platforms. 3) I'm curious to know why it doesn't work, as it was
> expected to work on different endianess and word size. 4) the md5
> library has been, and hopefully will continue to be, a good way to shake
> problems out of the parrot core.
>
> Thanks all,
>
> Nick
>
Leopold Toetsch
> P.S. (I wish I still had Cray 90 access, the unusual-but-legal
> longsize=ptrsize=intsize=shortsize=8 nicely shook bugs to the bright
> light of day in Perl 5.)
Would break nicely ;)
leo
Jarkko Hietaniemi
HP-UX/HPPA) things are even more interesting -- one can in compile time
decide between different 32-bit modes and different 64-bit modes.
(E.g. in IRIX there are two of each.) I believe the new x86-ish
processors and Linux/gcc offer similar options.
Whether one can mix and match such executables/libraries depends
on how the processors/operating system have been configured.
So one can't really assume much about the integer sizes.
I heartily recommend people interested in portability matters
getting machines and/or accounts in different machines. It Will
Make Your Code Better.
Nick Glencross
>Nick Glencross wrote:
>
>
>>Ok, so intsize=4, which is why my md5 test tried to run. I'd be really
>>grateful if some could run my instrumented MD5.imc from a previous post
>>on this platform.
>>
>>So what I'm confused about is why intsize=4 when you say the Parrot core
>>is 64 bit.
>>
>>
>
>Weelll... I did not say *quite* that. What I said that so far the
>Parrot's core seems to have worked well in systems with _some_ 64-bit
>integer types available. So the Parrot core has been 64-bit _safe_,
>which doesn't mean it has been _using_ 64-bit integers explicitly
>(e.g. in Tru64 it has been using 64-bit longs implicitly).
>
>
Ok, so ints on Tru64 are 32-bit, just like on my PC. In which case, I
wonder which operation is behaving differently between the two platforms?
When you get a chance, do you mind trying out my instrumented MD5.imc
file? I'd be extremely grateful!
CHeers,
Nick
Leopold Toetsch
> Jarkko,
>
> thank you for your patience today. We to-and-fro'd more times than I
> originally intended.
>
> I would say that Tru64 does have 64 bit ints, which is pretty clear from
> the logs that you've been sending me. I'm guessing that intvalsize,
> instead of intsize is the important variable to distinguish a 64-bit
> system (what is intsize in that case?) i.e. it's normal 64-bit
Yep intvalsize is the size of INTVAL and that's relevant.
I've applied the patch now and disabled the 64-bit warning. Tests are
only skipped for bigendian now.
NB: please provide unified diffs (-u option)
Thanks,
leo