On Thu, 26 Feb 2004, Leopold Toetsch wrote:
> Andrew Dougherty <[EMAIL PROTECTED]> wrote:
> > Solaris/SPARC/Sun cc, longsize=4:
>
> > # PackFile_unpack: Not a Parrot PackFile!
> > # Magic number was [0x20a54100] not [0x013155a1]
>
> Does it work now?
Yes, great! Thanks.
>
> > And, just to round out the report, on x86 with long-long opcodes,
>
> ... is broken ;)
>
> > (what you get if you build perl-5.8.3 with -Duse64bitint)
>
> You don't need a special perl.
>
> perl Configure.pl --opcode="long long" [ --intval="long long" ]
>
> *but* just don't do that.
Oh, I agree that if I go out of my way to build a non-default build, I
ought to anticipate possible problems. I'm more concerned that as more
people build perl with -Duse64bitint on x86, then a plain
perl Configure.pl
will automatically pick up this broken configuration.
It may make sense to augment Configure.pl to not use 'long long' unless
explicitly directed to do so (either on the command line or as run
interactively).
In a somewhat similar vein, a challenge is emerging on the
Linux/UltraSPARC front. Under Debian's current 'unstable' and 'testing'
distributions, for example, you end up with the following types:
iv=long, intvalsize=8, intsize=4, opcode_t=long, opcode_t_size=8,
ptrsize=8, ptr_alignment=4 byteorder=87654321,
nv=double, numvalsize=8, doublesize=8
(I think these sizes are the same as Jarkko was reporting on the alpha.)
As you might guess, there are a number of things -- not just parrot --
that don't work well with these defaults. And, just to make degugging fun,
I'm currently getting helpful messages from gdb like the following:
Warning:
Cannot insert breakpoint -1.
Error accessing memory address 0xcaa0: Input/output error.
--
Andy Dougherty [EMAIL PROTECTED]
