We currently produce SVP64 instructions which might cross 64-byte boundary. OpenPOWER ISA explicitly forbids such behavior, so we must fix it.
https://libre-soc.org/irclog/%23libre-soc.2023-01-23.log.html#t2023-01-23T19:49:50 OpenPOWER ISA 1.6 Instruction Formats Prefixed instructions do not cross 64-byte instruction address boundaries. When a prefixed instruction crosses a 64-byte boundary, the system alignment error handler is invoked.
(In reply to Dmitry Selyutin from comment #1) > https://libre-soc.org/irclog/%23libre-soc.2023-01-23.log.html#t2023-01-23T19: > 49:50 > > OpenPOWER ISA 1.6 Instruction Formats > Prefixed instructions do not cross 64-byte instruction > address boundaries. When a prefixed instruction > crosses a 64-byte boundary, the system alignment > error handler is invoked. that's Power ISA 3.1 EXT001 64-bit prefixed instructions. SVP64 will not be fitting into EXT001 (we know that. current alternatives include EXT009) and consequently alignment of EXT001 is not relevant.
Yes, ISA currently mandates prefixed instructions to have the opcode 0b000001. However, logically SVP64 instructions are prefixed. Another point is that, we have to stay 1:1 with binutils; if we choose to change the alignment, SVP64 code in binutils must be updated respectively. And anyone would be quite surprised to see that, after we combined variables prefix and suffix into a single 64-bit wntitry, there's a check which explicitly avoids alignment if instruction belongs to SVP64. This breaks the least astonishment principle.
(In reply to Dmitry Selyutin from comment #0) > We currently produce SVP64 instructions which might cross 64-byte boundary. > OpenPOWER ISA explicitly forbids such behavior, so we must fix it. this is a misunderstanding. it's actually a 64 *WORD* boundary. this is approximately the size of a L1 Cache Line.
damn. forgot about this task. alignment on 64-word boundary should also be same as for PO1.
Uh-oh. I thought this task isn't to be done... (In reply to Luke Kenneth Casson Leighton from comment #2) > > SVP64 will not be fitting into EXT001 (we know that. current > alternatives include EXT009) and consequently alignment of > EXT001 is not relevant. So, what'd be the right way to handle it? If we behave as any other prefixed, I could re-use some builtins stuff I suppose.
(In reply to Dmitry Selyutin from comment #6) > Uh-oh. I thought this task isn't to be done... yep my mistake. length identification for multi-issue has to be done also on PO9 as with PO1. > (In reply to Luke Kenneth Casson Leighton from comment #2) > So, what'd be the right way to handle it? If we behave as any other > prefixed, I could re-use some builtins stuff I suppose. Yes just copy exactly what PO1 does. but at the moment i think they make of 64 *bit* alignment? i may have misread.
(In reply to Luke Kenneth Casson Leighton from comment #7) > Yes just copy exactly what PO1 does. but at the moment i think they > make of 64 *bit* alignment? i may have misread. https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff;h=41d40baf9d27d79d334e56a68c6819e0b71ef985 That's indeed 64-byte boundary, not 64-bit (as I stated at comment #0). The magic happens here: frag_align_code (6, 4); record_alignment (now_seg, 6); Now this magic applies to SVP64 mode as well (anything which enables PPC_OPCODE_SVP64 and uses sv-prefixed insntructions; these together toggle global svp64 boolean flag). Actually we even had this code before, but now I made an explicit commit. I hope you guys don't object if this is a separate commit. I think this simple code concludes the task. It'd be great if we could have a milestone and a budget assigned.