[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4 5/8] arm/vm_event: get/set registers



>>> On 31.05.16 at 18:28, <tamas@xxxxxxxxxxxxx> wrote:
> On May 31, 2016 01:48, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>
>> >>> On 30.05.16 at 21:47, <tamas@xxxxxxxxxxxxx> wrote:
>> > On Mon, May 30, 2016 at 5:50 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> >>>>> On 30.05.16 at 00:37, <tamas@xxxxxxxxxxxxx> wrote:
>> >>> +struct vm_event_regs_arm32 {
>> >>> +    uint32_t r0_usr;
>> >>> +    uint32_t r1_usr;
>> >>> +    uint32_t r2_usr;
>> >>> +    uint32_t r3_usr;
>> >>> +    uint32_t r4_usr;
>> >>> +    uint32_t r5_usr;
>> >>> +    uint32_t r6_usr;
>> >>> +    uint32_t r7_usr;
>> >>> +    uint32_t r8_usr;
>> >>> +    uint32_t r9_usr;
>> >>> +    uint32_t r10_usr;
>> >>> +    uint32_t r12_usr;
>> >>> +    uint32_t lr_usr;
>> >>> +    uint32_t fp;
>> >>> +    uint32_t pc;
>> >>> +    uint32_t sp_usr;
>> >>> +    uint32_t sp_svc;
>> >>> +    uint32_t spsr_svc;
>> >>> +};
>> >>
>> >> It would seem more natural for the "ordinary" registers to be
>> >> arranged in the numerical sequence, i.e. fp, r12, sp, lr, pc.
>> >
>> > Not sure I follow.
>>
>> For one it is quite natural for someone looking at a sequence of
>> register values to assume / expect them to be in natural order.
>> And then, having them in natural (numeric) order allows e.g.
>> extracting the register identifying bits from an instruction to use
>> them as an array index into (part of) this structure.
>>
>> (For some background: I've been bitten a number of times by
>> people sorting x86 registers alphabetically instead or naturally,
>> i.e. EAX, EBX, ECX, EDX instead of EAX, ECX, EDX, EBX).
> 
> I see, however I believe that would be a very careless use of this struct
> from the user as the register sizes are not even necessarily match the
> architecture. For example we only define the 64bit x86 registers, so trying
> to access it as an array of 32bit registers wouldn't work at all. Plus we
> are not doing a full set of registers, and I rather not imply that every
> element in the "natural sequence" is present. It may be, it may be not.

Once an ABI is set in stone, and if that ABI allows for optimizations
(by consumers) like the one mentioned, I don't think this would be
careless use. The resulting code is very clearly much more efficient
than e.g. a switch() statement with a case label for each and every
register. Well, yes, I already hear the "memory is cheap and hence
code size doesn't matter" argument, but as said elsewhere quite
recently I don't buy this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.