[Dwarf-discuss] PROPOSAL: add support for bundled instructions (e.g., Itanium)

[Ron Brender]

I definitely support the goal of this proposal. In fact, the slot to 
instruction mapping computation described here is exactly what we used 
for VMS on Itanium. However, we had no way to describe that this was 
being done--it is assumed based on the knowing the target architecture 
(given by the containing ELF context).

My only hesitation is to wonder how many other weird instruction 
encoding schemes we can recollect and to ask whether the simple ratio 
encoding proposed here is sufficient to cover all of them?

I think I recall a machine that had two instructions in each 36-bit 
word. That would be encoded in this scheme as the pair [1,2] (or the 
triple [0, 1, 2] if you prefer). So that variation is covered, which is 
good. What other variations can anyone report?

I suppose the worst case might be variable sized instructions on 
arbitrary bit boundaries. That too can be described in this scheme using 
the pair [1, 8] (or more generally [1, <bits per word>]). So maybe that 
makes this proposal completely general?

I do point out that the ratio encoding is still not a complete 
description of the Itanium slot scheme, where each 128-bit (16-byte) 
bundle has three 41-bit slots and one 5-bit field of other stuff. So 
there is still some amount of "you gotta know the target architecture" 
in any case.

That said, assuming no one comes up with an example architecture that 
does not fit this proposal then I am happy to support it.

My only additional thought would be that we should explicitly reserve a 
bundle size of zero to DWARF for possible future extension.

Cary Coutant wrote:
> [Resubmitted with the right mailing address. Sorry!]
> 
> I submitted this idea for discussion last year, and got some positive  
> feedback, but never followed through. Here's a formal proposal for  
> the next DWARF revision.
> 
> Chris had these comments on July 14, 2006:
> 
>> Shouldn't the new header fields go at the end
>> of the header so that old code might still work?
>> Of course, you would also want to update the version
>> number for that dwarf section.
> 
> I'd prefer to see them immediately following the  
> minimum_instruction_length field. Moving them to the end means that  
> they'd end up following three variable-length fields: the array of  
> standard opcode lengths, and the two lists of include directory names  
> and file names (with the extra null byte at the end of each list).  
> That's just begging for trouble. Any old code trying to read a line  
> number table that uses this new convention just isn't going to work  
> anyway. Any old code trying to read a new line number table that  
> doesn't use this convention won't see any difference, and will  
> continue to work.
> 
>> Also, you could leave the minimum instruction length
>> set to something normal (like 1 or 16) and use a non-zero
>> value in the two new fields to indicate the new
>> style of information.
> 
> Again, I don't think that's going to help old code -- it would just  
> make it *think* it's working, while producing nonsense instruction  
> addresses.
> 
> -cary
> 
> 
> Background
> 
> 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.
> 
> Proposal
> 
> 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, respectively. (We consider all bundles to have exactly 3  
> slots, even for those bundle type where one instruction spans two  
> slots.)
> 
> Because this change has the potential to break existing consumers,  
> the version number in the line number program header, specified in  
> Section 7.21, should be changed to 4, although producers who do not  
> set minimum_instruction_length to zero can (and should?) continue to  
> generate version 3.
> 
> -cary
> 
> _______________________________________________
> dwarf-discuss mailing list
> dwarf-discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
> 
>