[Tutor] what is 'doubleword alignment'?

[Albert-Jan Roskam]

--- On Mon, 7/18/11, Kushal Kumaran <kushal.kumaran+python at gmail.com> wrote:

From: Kushal Kumaran <kushal.kumaran+python at gmail.com>
Subject: Re: [Tutor] what is 'doubleword alignment'?
To: "Walter Prins" <wprins at gmail.com>
Cc: tutor at python.org
Date: Monday, July 18, 2011, 8:39 AM

On Sun, Jul 17, 2011 at 9:15 PM, Walter Prins <wprins at gmail.com> wrote:
>
>
> On 17 July 2011 15:26, Lisi <lisi.reisz at gmail.com> wrote:
>>
>> Sorry to be slow.  Blame virtually no sleep last night ;-(  But even were
>> the
>> power of two bit correct (and I see subsequently that it is not), how is
>> 18 a
>> power of two?
>>
>
> The 18 bytes is a bit of an irrelevance.  The point is that if the start of
> the buffer falls on a dword (double word) alligned memory location then in
> theory the access should be faster.  The term is a little bit ambiguous
> because strictly speaking different processors have different word sizes.
> Even so, usually when people speak of double-word alignment, it's often the
> case that the term word in such a context has its original meaning, e.g. 16
> bits.  A dword is then 32bits or 4 bytes.   A doubleword aligned memory
> address is, using these assumptions, therefore an address that is divisible
> by 4.  Obviously if the word size is 32bits, then a double word would be
> 64bits and a doubleword aligned address would need to be divisible by 8.  As
> an aside, this type of optimization is often taken care of by compilers
> under the hood, and in any case it's generally not something that you'll
> really be considering as a Python programmer.  (If however you were working
> on one of the Python runtimes or implementations, then you might well be
> sometimes considering this type of thing, depending on exactly how
> performance critical what you are working might be and what the runtime was
> being implemented in.)
>

It's not just about performance.  Some hardware simply cannot access
data that is not correctly aligned.  C programs that indiscriminately
cast among pointers to types of different sizes are a pain to port off
lenient architectures like x86.  If you're writing C code that deals
with pointers, you *always* need to keep alignment in mind.

-- 
regards,
kushal

===> Hello, 

Sorry for the late reply. Thank you all for your replies. I said '18' but I meant '16' (maybe my fingers are too big ;-). 

The text I put in my original post was from the documentation of a .dll/.so file (programmed in C). It was part of a procedure that reads out data. Each variable is 8 bytes or (for string variables) mutliples of 8 bytes (and each byte is 8 bits). I am using struct.unpack and ctypes to process the data in python. It works now, although I still want to read more about this. Where does the distinction little/big endian enter this story?

Thanks again, I appreciate it!

Albert-Jan
_______________________________________________
Tutor maillist  -  Tutor at python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20110720/2f54baf3/attachment.html>