#364: ptr_alignment 8 not honored, sparc 64bit broken
---------------------+------------------------------------------------------
Reporter: rurban | Owner: rurban
Type: bug | Status: assigned
Priority: blocker | Milestone: 1.0
Component: core | Version: trunk
Severity: release | Keywords:
Lang: | Patch:
Platform: other |
---------------------+------------------------------------------------------
Description changed by rurban:
Old description:
> A strict 64bit cpu with a ptr_alignment=8 will break when reading pbc's
> or just frozen pmc's because our alignment when writing our bytecode is
> 16/ptrsize and not 16.
>
> Any 64bit big-endian cpu with strict alignment is broken without
> '''-xmemalign=2i''' (the immediate workaround)
>
> The goal should be to allow fast aligned code and to align as advertised
> to 16, not 2 on 64-bit.
>
> {{{
> * First we should align to the foreign pbc ptrsize, not to the native
> ptrsize.
> * /sizeof (opcode_t) => /header->wordsize
> * Then we should get rid of the "/" at all, and align absolutely to 16,
> and not
> * to 16/4 = 4 or 16/8 = 2.
> * It is also broken in strict alignment 64bit CPU's. See
> http://nopaste.snit.ch/15684
> * 0x100000dec is an illegal alignment.
> */
> #define ROUND_16(val) (((val) & 0xf) ? 16 - ((val) & 0xf) : 0)
> #define ALIGN_16(st, cursor) \
> (cursor) += ROUND_16((const char *)(cursor) - (const char
> *)(st))/sizeof (opcode_t)
> }}}
>
> This requires a rewrite of all pbc writer alignment code
> (no macro used, bad), and also of the pbc reader code which
> is much simplier to fix.
>
> {{{
> t...@1 (l...@1) stopped in PF_fetch_integer at line 1076 in file "pf_items.c"
> 1076 ASSERT_ARGS(PF_fetch_integer)
> (dbx) step
> t...@1 (l...@1) stopped in PF_fetch_integer at line 1078 in file "pf_items.c"
> 1078 if (!pf || pf->fetch_iv == NULL)
> (dbx) print *(*stream)
> **stream = 4
> (dbx) step
> t...@1 (l...@1) stopped in PF_fetch_integer at line 1079 in file "pf_items.c"
> 1079 return *(*stream)++;
> (dbx) print *(*stream)
> **stream = 4
> (dbx) step
> t...@1 (l...@1) signal BUS (invalid address alignment) in PF_fetch_integer at
> line 1079 in file "pf_items.c"
> 1079 return *(*stream)++;
> (dbx) print *(*stream)
> **stream = 35
> (dbx) print *stream
> *stream = 0x100000dec
> }}}
>
> '''0x100000dec''' is not properly aligned. It must be '''0x100000df0'''.
>
> Sparc cc manpage:
> -xmemalign[=<a><b>] Controls memory alignment, <a>={1|2|4|8|16},
> b={f|i|s}.[[BR]]
> Accepted values for b are: i Interpret access and continue execution. s
> Raise signal SIGBUS. f For variants of -xarch=v9 only. [reduced i]
>
> Thanks to Rolf Grossmann for coming up with all this info and debugging.
New description:
A strict 64bit cpu with a ptr_alignment=8 will break when reading pbc's or
just frozen pmc's because our alignment when writing our bytecode is
16/ptrsize and not 16.
Any 64bit big-endian cpu with strict alignment is broken without
'''-xmemalign=2i''' (the immediate workaround)
The default for all v9 architectures is '''-xmemalign=8s'''.
The goal should be to allow fast aligned code and to align as advertised
to 16, not 2 on 64-bit.
{{{
* First we should align to the foreign pbc ptrsize, not to the native
ptrsize.
* /sizeof (opcode_t) => /header->wordsize
* Then we should get rid of the "/" at all, and align absolutely to 16,
and not
* to 16/4 = 4 or 16/8 = 2.
* It is also broken in strict alignment 64bit CPU's. See
http://nopaste.snit.ch/15684
* 0x100000dec is an illegal alignment.
*/
#define ROUND_16(val) (((val) & 0xf) ? 16 - ((val) & 0xf) : 0)
#define ALIGN_16(st, cursor) \
(cursor) += ROUND_16((const char *)(cursor) - (const char
*)(st))/sizeof (opcode_t)
}}}
This requires a rewrite of all pbc writer alignment code
(no macro used, bad), and also of the pbc reader code which
is much simplier to fix.
{{{
t...@1 (l...@1) stopped in PF_fetch_integer at line 1076 in file "pf_items.c"
1076 ASSERT_ARGS(PF_fetch_integer)
(dbx) step
t...@1 (l...@1) stopped in PF_fetch_integer at line 1078 in file "pf_items.c"
1078 if (!pf || pf->fetch_iv == NULL)
(dbx) print *(*stream)
**stream = 4
(dbx) step
t...@1 (l...@1) stopped in PF_fetch_integer at line 1079 in file "pf_items.c"
1079 return *(*stream)++;
(dbx) print *(*stream)
**stream = 4
(dbx) step
t...@1 (l...@1) signal BUS (invalid address alignment) in PF_fetch_integer at
line 1079 in file "pf_items.c"
1079 return *(*stream)++;
(dbx) print *(*stream)
**stream = 35
(dbx) print *stream
*stream = 0x100000dec
}}}
'''0x100000dec''' is not properly aligned. It must be '''0x100000df0'''.
Sparc cc manpage:
-xmemalign[=<a><b>] Controls memory alignment, <a>={1|2|4|8|16},
b={f|i|s}.[[BR]]
Accepted values for b are: i Interpret access and continue execution. s
Raise signal SIGBUS. f For variants of -xarch=v9 only. [reduced i]
Thanks to Rolf Grossmann for coming up with all this info and debugging.
--
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/364#comment:4>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
