Re: PATCH: usb: descriptor structures have to be packed

> From: David Brownell
> Newsgroups: gmane.linux.usb.devel
> Subject: Re: PATCH: usb: descriptor structures have to be packed
> Date: Tue, 6 Feb 2007 16:02:27 -0800

Hallo.

> On Tuesday 06 February 2007 2:48 pm, Pete Zaitcev wrote:
>> On Tue, 6 Feb 2007 13:08:19 -0800, Inaky Perez-Gonzalez <[email protected]> wrote:
>> 
>> > [btw, I truly have little idea about which are those specific costs,
>> >  out of professional curiosity, got any pointers?]
>> 
>> http://www.digitalvampire.org/blog/articles/2006/07/31/why-you-shouldnt-use-__attribute__-packed
>
> In fact the executive summary on that page applies nicely:
>
>   "don't add __attribute__((packed)) to your code unless
>    you know you need it."
>
> My point [b] explained why/how "we know we need it".  You seem
> to have ignored that part of the discussion this time, just like
> the last several times it's come up.
>
>
> And for anyone who's tempted to shudder at the ASM there, from
> two platforms well-known for code bloat:
[]

Dave, would you like additionally answer some related questions? TIA.

Would you clarify "non aligned access issue" on well known platforms
(*x86-*). I see on gcc's output, that they are not carry much about it:

,-*- gcc | objdump -S -*-
|  40046a:       0f b7 40 05             movzwl 0x5(%rax),%eax
|  40046e:       0f be c0                movsbl %al,%eax
(memory access shift is odd -- 0x05)
|
or (one is even -- 0x08)
|  400445:       8b 40 08                mov    0x8(%rax),%eax
|  400448:       0f be c0                movsbl %al,%eax
`-*-     

some docs are saying about (0)"slightly faster operation", if access is
aligned. What it's all about?

(1) When i started to understand things about packed/padded structs in
gcC, my first ever question was: "WTF that padding is doing there, if i
didn't coded it explicitly?" (2) Is it impact of hardware memory bus
access issues, like (0) or that bloated code from ia64 and Sparc, showed
in proposed URL, that i even can't parse (: ?

I've also read in some Intel's docs, that having bigger struct's members
first is better, what can you say on this?

>>   __attribute((__packed__)) is hardly superior to the old style which
>> worked fine for a 1000 years before gcc.
>
> Yes, that "old style" you're promoting is indeed from the Dark Ages.
> And you *can* make anything sound bad if you disregard its strengths,
> as you've been doing with respect to "packed".

Do you mean byte access "magic", probably due to (2)?
In scope of (1) i can't understand: structs are padded implicitly,
member access is coded explicitly.

Thus i think, using "packed" attribute for things like inet-packets, wire,
hardware is absolute *must*, because structures are usually
copied/moved from memory to devices "as they are".

(hope you will understand all this "English" ;)

Thanks.

--
-o--=O`C  info emacs : not found  /. .\ ( is there any reason to live? )
 #oo'L O  info make  : not found      o (    yes --- R.I.P. FSF+RMS    )
<___=E M  man gcc    : not found    `-- ( viva Debian Operating System )

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel