#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    |  
---------------------+------------------------------------------------------
Changes (by rurban):

  * owner:  => rurban
  * status:  new => assigned


Old description:

> A strict 64bit cpu with a ptr_alignment 8 will break when reading frozen
> pmc's because our alignment when writing our reading bytecode is
> 16/ptrsize and not 16.
>
> Any 64bit big-endian cpu with strict alignment is broken without
> '''-xmemalign=2i -xmemalign=2f -xmemalign=2s''' (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'''.

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 -xmemalign=2f -xmemalign=2s''' (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'''.

--

-- 
Ticket URL: <https://trac.parrot.org/parrot/ticket/364#comment:1>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets

Reply via email to