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

[Ron Brender]

Cary Coutant wrote:
 > I'm tossing this idea out there just to see if anyone else likes it...
 >

Yes, I definitely like it!

For VMS on Itanium we did essentially what Cary suggests. That is, all
"delta address" operations are interpreted as really being "delta slot"
operations. This gives us all the advantages of a smooth, dense 
numbering. What we did not do was invent an encoding to describe this. 
IIRC, we use a minimum instruction length of 1 and assume 16/3 slot 
numbering if the architecture is Itanium and the OS is VMS as specified 
in the containing ELF header.

It would certainly be more self-describing to include the bundle length 
and instructions per bundle values in the DWARF information such as Cary 
suggests.

A really pedantic person might also worry about the layout of the 
instructions within the bundle, in particular for the location of the 
"left over bits", of which there are five per bundle on Itanium. I am 
inclined to ignore this issue--at least until another "bundlized" 
architecture comes along. (Are there any others?)

Cary's scheme is upward compatible with the existing encoding so that I 
suppose that it is not strictly necessary to increase the version number 
for any line number table that includes this new scheme. OTOH, I do 
worry just a bit that a consumer that does not know/support the 
extension will get badly confused when it comes across the likely 
unchecked header length of zero, simply tucks it away for later use, and 
then bungles the rest of the line number header because of the extra 
bytes that it misconstrues. So maybe there should be a higher version 
number to enable use of this extension...

Ron


> 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