On Sun, 2008-07-20 at 15:45 +0200, Christian Franke wrote:
> Christian Franke wrote:
> > But the function call in the 32-bit case requires only 5 bytes :-)
> >
>
> Sorry, I was wrong here. The assumption about function call size was
> only true for module-local calls. If a module calls a func
Christian Franke wrote:
Pavel Roskin wrote:
On Tue, 2008-07-08 at 20:04 +0200, Christian Franke wrote:
With old gcc versions without the "rol" optimization, even the 16
bit swap should be a function:
Or better yet, an asm statement.
We should consider optimized assembly vs fu
On Fri, 2008-07-11 at 15:21 +0200, Christian Franke wrote:
> Very nice optimization idea!
>
> The practical advantage is probably limited by the fact that kernel.img
> and most of the modules typically included in a i386-pc core.img are not
> affected.
>
> I attached a diff of "size *.mod" out
Pavel Roskin wrote:
Quoting Pavel Roskin <[EMAIL PROTECTED]>:
366976 original
364988 "=q", xchgb
365460 "=q", rolw $8,%w0
365420 "=r", rolw $8,%w0
364996 monstrosity ("=r", conditional xchgb/rolw)
364728 "little details"
Marginally better (by just 12 bytes):
364716 "little details" + "
Quoting Pavel Roskin <[EMAIL PROTECTED]>:
366976 original
364988 "=q", xchgb
365460 "=q", rolw $8,%w0
365420 "=r", rolw $8,%w0
364996 monstrosity ("=r", conditional xchgb/rolw)
364728 "little details"
Marginally better (by just 12 bytes):
364716 "little details" + "monstrosity"
#define
Quoting Christian Franke <[EMAIL PROTECTED]>:
#define grub_swap_bytes32(x) \
({ \
grub_uint32_t _x = (x), _y; \
asm ( \
"xchgb %b0,%h0\n" \
"roll $0x10,%0\n" \
"xchgb %b0,%h0\n" \
: "=q"(_y) : "0"(_x) \
); \
_y; \
})
Results are much better for the inline
On Thu, Jul 10, 2008 at 03:59:14PM -0400, Pavel Roskin wrote:
> Thank you for testing! We could do better with the bswap instruction,
> but it appeared in 486. I think we still need to support 386.
Do we, or better yet, can we? I thought most distros had dropped 386
support from kernels and to
Quoting Christian Franke <[EMAIL PROTECTED]>:
GCC optimizer does a good job optimizing register use, but function
call is still better:
Debian gcc 4.1.2-7:
inline (portable)=357,asm (%%eax)=126, asm (%0)=107, function=104
Cygwin gcc 3.4.4:
inline (portable)=340, asm (%%eax)=124, asm (%0)=104,
Pavel Roskin wrote:
On Wed, 2008-07-09 at 14:50 +0200, Christian Franke wrote:
Result with the test script from my last mail:
Debian gcc 4.1.2-7:
inline (portable)=357, inline (asm)=126, function=104
Cygwin gcc 3.4.4:
inline (portable)=340, inline (asm)=124, function=96
Function call is s
On Wed, 2008-07-09 at 14:50 +0200, Christian Franke wrote:
> Overall size from inline asm would only be smaller if there is any
> benefit from additional optimizations.
Correct. Function calls use fixed registers for everything, but macros
don't have to.
> Result with the test script from my la
Pavel Roskin wrote:
> On Tue, 2008-07-08 at 20:04 +0200, Christian Franke wrote:
>
> > With old gcc versions without the "rol" optimization, even the 16
> > bit swap should be a function:
> >
>
> Or better yet, an asm statement.
>
> We should consider optimized assembly vs function call. Even
On Tue, 2008-07-08 at 20:04 +0200, Christian Franke wrote:
> With old gcc versions without the "rol" optimization, even the 16 bit
> swap should be a function:
Or better yet, an asm statement.
We should consider optimized assembly vs function call. Even the 32-bit
swap could be shorter:
a:
Christian Franke wrote:
Assembly code for grub_swap_bytes16 from Debian gcc 4.1.2-7:
Macro or Inline: 4 bytes (minus possible additional benefit from
register level optimizations)
66 c1 c0 08 rol$0x8,%ax
Function call: 11 bytes
0f b7 c0 movzwl %ax,%eax
e8 xx xx xx xx
Javier Martín wrote:
El dom, 06-07-2008 a las 20:30 +0200, Robert Millan escribió:
On Sun, Jul 06, 2008 at 12:54:58AM +0200, Javier Martín wrote:
El sáb, 05-07-2008 a las 17:30 -0400, Pavel Roskin escribió:
They probably should be functions. We may want to sparse annotate GRUB
El dom, 06-07-2008 a las 20:30 +0200, Robert Millan escribió:
> On Sun, Jul 06, 2008 at 12:54:58AM +0200, Javier Martín wrote:
> > El sáb, 05-07-2008 a las 17:30 -0400, Pavel Roskin escribió:
> > > They probably should be functions. We may want to sparse annotate GRUB
> > > one day, and then inlin
On Sun, Jul 06, 2008 at 12:54:58AM +0200, Javier Martín wrote:
> El sáb, 05-07-2008 a las 17:30 -0400, Pavel Roskin escribió:
> > They probably should be functions. We may want to sparse annotate GRUB
> > one day, and then inline functions in the only way to go.
> Hmm... you mean changing this
>
On Sun, 2008-07-06 at 00:54 +0200, Javier Martín wrote:
> El sáb, 05-07-2008 a las 17:30 -0400, Pavel Roskin escribió:
> > They probably should be functions. We may want to sparse annotate GRUB
> > one day, and then inline functions in the only way to go.
> Hmm... you mean changing this
>
> #defi
El sáb, 05-07-2008 a las 17:30 -0400, Pavel Roskin escribió:
> They probably should be functions. We may want to sparse annotate GRUB
> one day, and then inline functions in the only way to go.
Hmm... you mean changing this
#define grub_swap_bytes16(x)\
({ \
grub_uint16_t _x = (x); \
(g
On Sat, 2008-07-05 at 15:27 +0200, Javier Martín wrote:
> Just my two (euro) cents: why are the endianness macros written like
> functions? I'm talking about the grub_Xe_to_cpuNN family, which look
> like function calls instead of the macros they are. Shouldn't they be
> capitalized to GRUB_LE_TO_C
Just my two (euro) cents: why are the endianness macros written like
functions? I'm talking about the grub_Xe_to_cpuNN family, which look
like function calls instead of the macros they are. Shouldn't they be
capitalized to GRUB_LE_TO_CPU32 and such?
signature.asc
Description: Esta parte del mensa
20 matches
Mail list logo
