Bernd Petrovitsch wrote:
> The "register" keyword is and was always from start *at most* a hint to
> the C compiler to use a register for that variable (similar to "inline"
> BTW).
> So every C compiler is allowed to simply ignore the "register" for any
> reason - be it "not implemented" or "the
Bernd Petrovitsch wrote:
The register keyword is and was always from start *at most* a hint to
the C compiler to use a register for that variable (similar to inline
BTW).
So every C compiler is allowed to simply ignore the register for any
reason - be it not implemented or the compiler knows
On Tue, 2007-05-22 at 14:38 +0530, Nitin Gupta wrote:
[...]
> On 5/18/07, Andrey Panin <[EMAIL PROTECTED]> wrote:
> > On 138, 05 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
> > > + register const unsigned char *ip;
> >
> > register keyword is meaningless for today's compiler.
>
> But can
On May 22 2007 14:38, Nitin Gupta wrote:
> On 5/18/07, Andrey Panin <[EMAIL PROTECTED]> wrote:
>> On 138, 05 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
>> > + register const unsigned char *ip;
>>
>> register keyword is meaningless for today's compiler.
>
> But can we assume that gcc is
On May 18 2007 15:28, Nitin Gupta wrote:
> +/* lzo1x.h -- public interface of the LZO1X compression algorithm
> +
> + This file is part of the LZO real-time data compression library.
> +
> + Copyright (C) 2005 Markus Franz Xaver Johannes Oberhumer
> + Copyright (C) 2004 Markus Franz Xaver
Nitin Gupta wrote:
Ok. I will make them inline functions now.
Btw, the only reason why any sane compiler would not inline
them is because it has reason to believe the end-result will
be more efficient. AFAIK you only need to use
__always_inline where it matters for correctness (like, for
Hi,
On 5/18/07, Richard Purdie <[EMAIL PROTECTED]> wrote:
> This patch, as of yet, only gives 'non-safe' version of decompressor.
> The 'safe' version will be included soon.
How are you planning to add that back?
Please see newer patch posted.
The LZO author had some concerns about this
On 5/22/07, Pekka Enberg <[EMAIL PROTECTED]> wrote:
Nitin Gupta wrote:
> What if compiler decides not to actully inline them? In that case
> there will be significant perf. hit.
Then you use __always_inline.
Pekka
Ok. I will make them inline functions now.
Thanks,
Hi,
On 5/18/07, Andrey Panin <[EMAIL PROTECTED]> wrote:
On 138, 05 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
> + register const unsigned char *ip;
register keyword is meaningless for today's compiler.
But can we assume that gcc is being used? What if we use compiler for
which it
Nitin Gupta wrote:
What if compiler decides not to actully inline them? In that case
there will be significant perf. hit.
Then you use __always_inline.
Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Hi,
On 5/18/07, Pekka Enberg <[EMAIL PROTECTED]> wrote:
On 5/18/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> +#define DX2(p,s1,s2) \
> + (size_t)((p)[2]) << (s2)) ^ (p)[1]) << (s1)) ^ (p)[0])
> +#define DX3(p,s1,s2,s3) ((DX2((p)+1,s2,s3) << (s1)) ^ (p)[0])
> +#define DMUL(a,b)
On May 18 2007 15:28, Nitin Gupta wrote:
+/* lzo1x.h -- public interface of the LZO1X compression algorithm
+
+ This file is part of the LZO real-time data compression library.
+
+ Copyright (C) 2005 Markus Franz Xaver Johannes Oberhumer
+ Copyright (C) 2004 Markus Franz Xaver
On May 22 2007 14:38, Nitin Gupta wrote:
On 5/18/07, Andrey Panin [EMAIL PROTECTED] wrote:
On 138, 05 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
+ register const unsigned char *ip;
register keyword is meaningless for today's compiler.
But can we assume that gcc is being used?
On Tue, 2007-05-22 at 14:38 +0530, Nitin Gupta wrote:
[...]
On 5/18/07, Andrey Panin [EMAIL PROTECTED] wrote:
On 138, 05 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
+ register const unsigned char *ip;
register keyword is meaningless for today's compiler.
But can we assume
Hi,
On 5/18/07, Pekka Enberg [EMAIL PROTECTED] wrote:
On 5/18/07, Nitin Gupta [EMAIL PROTECTED] wrote:
+#define DX2(p,s1,s2) \
+ (size_t)((p)[2]) (s2)) ^ (p)[1]) (s1)) ^ (p)[0])
+#define DX3(p,s1,s2,s3) ((DX2((p)+1,s2,s3) (s1)) ^ (p)[0])
+#define DMUL(a,b) ((size_t) ((a) *
Nitin Gupta wrote:
What if compiler decides not to actully inline them? In that case
there will be significant perf. hit.
Then you use __always_inline.
Pekka
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Hi,
On 5/18/07, Andrey Panin [EMAIL PROTECTED] wrote:
On 138, 05 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
+ register const unsigned char *ip;
register keyword is meaningless for today's compiler.
But can we assume that gcc is being used? What if we use compiler for
which it does
On 5/22/07, Pekka Enberg [EMAIL PROTECTED] wrote:
Nitin Gupta wrote:
What if compiler decides not to actully inline them? In that case
there will be significant perf. hit.
Then you use __always_inline.
Pekka
Ok. I will make them inline functions now.
Thanks,
Nitin
Hi,
On 5/18/07, Richard Purdie [EMAIL PROTECTED] wrote:
This patch, as of yet, only gives 'non-safe' version of decompressor.
The 'safe' version will be included soon.
How are you planning to add that back?
Please see newer patch posted.
The LZO author had some concerns about this
Nitin Gupta wrote:
Ok. I will make them inline functions now.
Btw, the only reason why any sane compiler would not inline
them is because it has reason to believe the end-result will
be more efficient. AFAIK you only need to use
__always_inline where it matters for correctness (like, for
Bill Rugolsky Jr. wrote:
I'm certainly missing something but what are the advantages of this
code (over current gzip etc.), and what will be using it?
Richard's patchset added it to the crypto library and wired it into
the JFFS2 file system. We recently started using LZO in a userland UDP
Bill Rugolsky Jr. wrote:
I'm certainly missing something but what are the advantages of this
code (over current gzip etc.), and what will be using it?
Richard's patchset added it to the crypto library and wired it into
the JFFS2 file system. We recently started using LZO in a userland UDP
On Sat, 2007-05-19 at 14:55 -0400, Bill Rugolsky Jr. wrote:
> On Fri, May 18, 2007 at 11:14:57PM +0200, Krzysztof Halasa wrote:
> > I'm certainly missing something but what are the advantages of this
> > code (over current gzip etc.), and what will be using it?
>
> Richard's patchset added it to
On Fri, May 18, 2007 at 11:14:57PM +0200, Krzysztof Halasa wrote:
> I'm certainly missing something but what are the advantages of this
> code (over current gzip etc.), and what will be using it?
Richard's patchset added it to the crypto library and wired it into
the JFFS2 file system. We
>I'm certainly missing something but what are the advantages of this
>code (over current gzip etc.), and what will be using it?
lzo compresses/decompresses much faster and using less cpu
this is how it compares:
bzip2: best compression, but damn slow performance
gzip: good compression with
I'm certainly missing something but what are the advantages of this
code (over current gzip etc.), and what will be using it?
lzo compresses/decompresses much faster and using less cpu
this is how it compares:
bzip2: best compression, but damn slow performance
gzip: good compression with good
On Fri, May 18, 2007 at 11:14:57PM +0200, Krzysztof Halasa wrote:
I'm certainly missing something but what are the advantages of this
code (over current gzip etc.), and what will be using it?
Richard's patchset added it to the crypto library and wired it into
the JFFS2 file system. We recently
On Sat, 2007-05-19 at 14:55 -0400, Bill Rugolsky Jr. wrote:
On Fri, May 18, 2007 at 11:14:57PM +0200, Krzysztof Halasa wrote:
I'm certainly missing something but what are the advantages of this
code (over current gzip etc.), and what will be using it?
Richard's patchset added it to the
"Nitin Gupta" <[EMAIL PROTECTED]> writes:
> Facts for LZO (at least for original code. Should hold true for this
> port also - hence the RFC!):
> - The compressor can never overrun buffer.
> - The "non-safe" version of decompressor can never overrun buffer if
> compressed data is unmodified. I am
On Fri, May 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
> +/* lzo1x.h -- public interface of the LZO1X compression algorithm
> +
> + This file is part of the LZO real-time data compression library.
> +
> + Copyright (C) 2005 Markus Franz Xaver Johannes Oberhumer
> + Copyright (C) 2004
On 138, 05 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
> Hi,
>
> This is kernel port of LZO1X de/compression algo stripped down to just ~500
> LOC!
> It is derived from original LZO 2.02 code found at:
> http://www.oberhumer.com/opensource/lzo/download/
> The code has also been reformatted
On Fri, 2007-05-18 at 16:57 +0530, Nitin Gupta wrote:
> On 5/18/07, Heikki Orsila <[EMAIL PROTECTED]> wrote:
> > Good work..
> >
> > On Fri, May 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
> > > Facts for LZO (at least for original code. Should hold true for this
> > > port also - hence the
Hi,
On Fri, 2007-05-18 at 15:28 +0530, Nitin Gupta wrote:
> This is kernel port of LZO1X de/compression algo stripped down to just ~500
> LOC!
> It is derived from original LZO 2.02 code found at:
> http://www.oberhumer.com/opensource/lzo/download/
> The code has also been reformatted to match
Hi,
Thanks for review. My comments inline.
On 5/18/07, Heikki Orsila <[EMAIL PROTECTED]> wrote:
Good work..
On Fri, May 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
> Facts for LZO (at least for original code. Should hold true for this
> port also - hence the RFC!):
> - The compressor can
On 5/18/07, Pekka Enberg <[EMAIL PROTECTED]> wrote:
So how about making that a little less verbose. Say like:
Copyright (c) 1996-2005 Markus Franz Xaver and Johannes Oberhumer
Oh, the author's name really is "Markus Franz Xaver Johannes
Oberhumer." But please make the copyright statement one
On 5/18/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
+ Copyright (C) 2005 Markus Franz Xaver Johannes Oberhumer
+ Copyright (C) 2004 Markus Franz Xaver Johannes Oberhumer
[snip]
So how about making that a little less verbose. Say like:
Copyright (c) 1996-2005 Markus Franz Xaver and
Good work..
On Fri, May 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
> Facts for LZO (at least for original code. Should hold true for this
> port also - hence the RFC!):
> - The compressor can never overrun buffer.
> - The "non-safe" version of decompressor can never overrun buffer if
>
Hi,
This is kernel port of LZO1X de/compression algo stripped down to just ~500 LOC!
It is derived from original LZO 2.02 code found at:
http://www.oberhumer.com/opensource/lzo/download/
The code has also been reformatted to match general kernel style.
Facts for LZO (at least for original code.
Hi,
This is kernel port of LZO1X de/compression algo stripped down to just ~500 LOC!
It is derived from original LZO 2.02 code found at:
http://www.oberhumer.com/opensource/lzo/download/
The code has also been reformatted to match general kernel style.
Facts for LZO (at least for original code.
Good work..
On Fri, May 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
Facts for LZO (at least for original code. Should hold true for this
port also - hence the RFC!):
- The compressor can never overrun buffer.
- The non-safe version of decompressor can never overrun buffer if
compressed
On 5/18/07, Pekka Enberg [EMAIL PROTECTED] wrote:
So how about making that a little less verbose. Say like:
Copyright (c) 1996-2005 Markus Franz Xaver and Johannes Oberhumer
Oh, the author's name really is Markus Franz Xaver Johannes
Oberhumer. But please make the copyright statement one
On 5/18/07, Nitin Gupta [EMAIL PROTECTED] wrote:
+ Copyright (C) 2005 Markus Franz Xaver Johannes Oberhumer
+ Copyright (C) 2004 Markus Franz Xaver Johannes Oberhumer
[snip]
So how about making that a little less verbose. Say like:
Copyright (c) 1996-2005 Markus Franz Xaver and Johannes
Hi,
Thanks for review. My comments inline.
On 5/18/07, Heikki Orsila [EMAIL PROTECTED] wrote:
Good work..
On Fri, May 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
Facts for LZO (at least for original code. Should hold true for this
port also - hence the RFC!):
- The compressor can
On Fri, 2007-05-18 at 16:57 +0530, Nitin Gupta wrote:
On 5/18/07, Heikki Orsila [EMAIL PROTECTED] wrote:
Good work..
On Fri, May 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
Facts for LZO (at least for original code. Should hold true for this
port also - hence the RFC!):
- The
Hi,
On Fri, 2007-05-18 at 15:28 +0530, Nitin Gupta wrote:
This is kernel port of LZO1X de/compression algo stripped down to just ~500
LOC!
It is derived from original LZO 2.02 code found at:
http://www.oberhumer.com/opensource/lzo/download/
The code has also been reformatted to match
On 138, 05 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
Hi,
This is kernel port of LZO1X de/compression algo stripped down to just ~500
LOC!
It is derived from original LZO 2.02 code found at:
http://www.oberhumer.com/opensource/lzo/download/
The code has also been reformatted to
On Fri, May 18, 2007 at 03:28:31PM +0530, Nitin Gupta wrote:
+/* lzo1x.h -- public interface of the LZO1X compression algorithm
+
+ This file is part of the LZO real-time data compression library.
+
+ Copyright (C) 2005 Markus Franz Xaver Johannes Oberhumer
+ Copyright (C) 2004 Markus
Nitin Gupta [EMAIL PROTECTED] writes:
Facts for LZO (at least for original code. Should hold true for this
port also - hence the RFC!):
- The compressor can never overrun buffer.
- The non-safe version of decompressor can never overrun buffer if
compressed data is unmodified. I am not sure
48 matches
Mail list logo
