[Dwarf-discuss] Proposal to support bundled instructions (e.g., Itanium)

[Cary Coutant]

I'm tossing this idea out there just to see if anyone else likes it...

On the Itanium architecture, three instructions are packed into one  
16-byte "bundle". Only the bundle itself has a real (16-byte aligned)  
address, leaving the compiler and debugger to agree on a convention  
for how to represent the addresses of the instructions inside the  
bundle. On HP-UX, we use the bundle address plus 0, 4, and 8 to  
represent these; Linux has chosen the bundle address plus 0, 1, and  
2. In the line number program, we set minimum_instruction_length to  
4, and we then have to use increments of 1, 1, 2, 1, 1, 2, ....  
Worse, Linux chose to set minimum_instruction_length to 1, and uses  
increments of 1, 1, 14, 1, 1, 14, .... Ideally, I'd like to set  
minimum_instruction_length to 16/3, so we can just use uniform  
increments of 1.

I propose to extend the definition of the minimum_instruction_length  
field of the line number program header, in Section 6.2.4, as follows:

"If minimum_instruction_length is zero, it is immediately followed by  
two additional ubytes -- bundle_length and  
instruction_slots_per_bundle. For architectures with instruction  
bundles, the address register has two components: a bundle address  
and a slot number. Line number program opcodes that alter the address  
register first compute the new bundle address as (bundle_adress +  
bundle_length * ((slot_number + operand) div  
instruction_slots_per_bundle)), then compute the new slot number as  
((slot_number + operand) rem instruction_slots_per_bundle), where div  
and rem are defined such that (a div b) is an integer and a = (a div  
b) * b + (a rem b) and 0 <= (a rem b) < b."

For Itanium, we would set the minimum_instruction_length field to 0,  
followed by the bundle_length and instruction_slots_per_bundle fields  
of 16 and 3.

-cary