On Sat, 2007-05-19 at 14:24 +0200, Segher Boessenkool wrote:
> >> It's not the compiler who decides -- struct layout is
> >> dictated by the ABI you're compiling for.
> >
> > This is true in the case of externally-visible stuff. I think the
> > compiler is permitted to violate the ABI for purely un
It's not the compiler who decides -- struct layout is
dictated by the ABI you're compiling for.
This is true in the case of externally-visible stuff. I think the
compiler is permitted to violate the ABI for purely unit-internal
things
if it makes sense though, isn't it?
Sure. It isn't "viol
On Sat, 2007-05-19 at 00:00 +0200, Segher Boessenkool wrote:
> It's not the compiler who decides -- struct layout is
> dictated by the ABI you're compiling for.
This is true in the case of externally-visible stuff. I think the
compiler is permitted to violate the ABI for purely unit-internal thing
On Fri, 2007-05-18 at 21:55 +0200, matthieu castet wrote:
> > Are you suggesting that this has changed since I did my testing?
> >
> Which version of gcc did you try ?
It was a while ago -- probably 3.2 or something like that. I think it
might even predate the summary support.
When I get home I'
Out of curiosity, why would a compiler ever insert padding in a
structure
that has all its elements properly-aligned?
Well, it might decide it would be nicer if some elements were aligned
to
64 bits. Or to a cache line. Or something. I don't care about _why_ --
the point is that it's _allowed
Hi,
David Woodhouse wrote:
On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote:
On arch that don't support aligned access, packed struct access will be
done byte per byte (but it could be the expected behavior if there
unaligned access).
When I tested this on ARM, the output for je32_to
David Woodhouse wrote:
On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote:
On Thu, 17 May 2007 10:29:31 -0700, Andrew Morton wrote:
On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy
When I tested this on ARM, the output for je32_to_cpu et al was fine.
For _other_ structures where I'd
On Fri, 2007-05-18 at 07:52 -0400, John Anthony Kazos Jr. wrote:
> Out of curiosity, why would a compiler ever insert padding in a structure
> that has all its elements properly-aligned?
Well, it might decide it would be nicer if some elements were aligned to
64 bits. Or to a cache line. Or some
On Fri, 18 May 2007, David Woodhouse wrote:
> On Thu, 2007-05-17 at 22:57 -0400, John Anthony Kazos Jr. wrote:
> > Wouldn't the appropriate test be to demonstrate that the same program text
> > opcodes are generated in both cases for all architectures?
>
> No, empirical testing with the compiler
On Fri, May 18, 2007 at 09:58:25AM +0300, Artem Bityutskiy wrote:
> Al Viro wrote:
> >BTW, you can simply typedef __be16 ubi16_t; etc. and define conversion
> >functions as cpu_to_ubi16(x) being (__force ubi16_t)cpu_to_be16(x), etc.
> >
> >sparse will do all checks just fine, you still have bitwise
Al Viro wrote:
BTW, you can simply typedef __be16 ubi16_t; etc. and define conversion
functions as cpu_to_ubi16(x) being (__force ubi16_t)cpu_to_be16(x), etc.
sparse will do all checks just fine, you still have bitwise operations
(might or might be not relevant in your case) and for gcc it simpl
On Thu, 2007-05-17 at 22:57 -0400, John Anthony Kazos Jr. wrote:
> Wouldn't the appropriate test be to demonstrate that the same program text
> opcodes are generated in both cases for all architectures?
No, empirical testing with the compiler is never the _correct_ thing to
do. It's just expedie
On Fri, 18 May 2007, David Woodhouse wrote:
> On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote:
> > On Thu, 17 May 2007 10:29:31 -0700, Andrew Morton wrote:
> >
> > > On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy
> > > <[EMAIL PROTECTED]> wrote:
> > >
> > > umm.. I'd say what you'v
On Thu, 2007-05-17 at 20:30 +, Matthieu CASTET wrote:
> On Thu, 17 May 2007 10:29:31 -0700, Andrew Morton wrote:
>
> > On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy
> > <[EMAIL PROTECTED]> wrote:
> >
> > umm.. I'd say what you've done in there is an improvement to the
> > exiting stuff
On Thu, May 17, 2007 at 02:33:34PM -0700, David Miller wrote:
> From: "Dmitry Torokhov" <[EMAIL PROTECTED]>
> Date: Thu, 17 May 2007 17:14:26 -0400
>
> > On 5/17/07, Al Viro <[EMAIL PROTECTED]> wrote:
> > >
> > > Ahem... So what does
> > >x |= y;
> > > turns into with that approach?
> >
From: "Dmitry Torokhov" <[EMAIL PROTECTED]>
Date: Thu, 17 May 2007 17:14:26 -0400
> On 5/17/07, Al Viro <[EMAIL PROTECTED]> wrote:
> >
> > Ahem... So what does
> >x |= y;
> > turns into with that approach?
>
> Do we want to do such kind of operations on endian-annotated data? I'd
> imagi
On Thu, May 17, 2007 at 05:14:26PM -0400, Dmitry Torokhov wrote:
> On 5/17/07, Al Viro <[EMAIL PROTECTED]> wrote:
> >
> >Ahem... So what does
> > x |= y;
> >turns into with that approach?
>
> Do we want to do such kind of operations on endian-annotated data? I'd
> imagine you want to conver
On Thu, May 17, 2007 at 09:42:34PM +0100, Al Viro wrote:
> Ahem... So what does
> x |= y;
> turns into with that approach?
Another case is
#define FLAG1 cpu_to_be32(2)
#define FLAG2 cpu_to_be32(0x400)
if (packet_header->field & (FLAG1 | FLAG2))
which is a blo
On 5/17/07, Al Viro <[EMAIL PROTECTED]> wrote:
Ahem... So what does
x |= y;
turns into with that approach?
Do we want to do such kind of operations on endian-annotated data? I'd
imagine you want to convert ot host-endianess first anyway.
--
Dmitry
-
To unsubscribe from this list: send
On Thu, May 17, 2007 at 01:56:24PM -0700, David Miller wrote:
> From: Artem Bityutskiy <[EMAIL PROTECTED]>
> Date: Thu, 17 May 2007 17:50:43 +0300
>
> > Well, I see the good side of your change - no home-brewed media<->cpu
> > things. Fair enough and nice. But why don't you make __be32 a struct
>
From: Artem Bityutskiy <[EMAIL PROTECTED]>
Date: Thu, 17 May 2007 17:50:43 +0300
> Well, I see the good side of your change - no home-brewed media<->cpu
> things. Fair enough and nice. But why don't you make __be32 a struct
> (just like I do) so that compiler could complain then?
structs get pass
> Ahem... So what does
> x |= y;
> turns into with that approach?
BTW, you can simply typedef __be16 ubi16_t; etc. and define conversion
functions as cpu_to_ubi16(x) being (__force ubi16_t)cpu_to_be16(x), etc.
sparse will do all checks just fine, you still have bitwise operations
(might or
On Thu, May 17, 2007 at 10:29:31AM -0700, Andrew Morton wrote:
> On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2007-05-17 at 16:56 +0200, Christoph Hellwig wrote:
> > > On Thu, May 17, 2007 at 05:50:43PM +0300, Artem Bityutskiy wrote:
> > > > Christop
On Thu, 17 May 2007 10:29:31 -0700, Andrew Morton wrote:
> On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy
> <[EMAIL PROTECTED]> wrote:
>
> umm.. I'd say what you've done in there is an improvement to the
> exiting stuff: getting gcc to check it is better than having to use
> sparse.
>
> I'
On Thu, 17 May 2007, Andrew Morton wrote:
Drat, and here was I hoping I'd lured you into implementing the generic
code.
Well, I am really happy to contribute, but I am not a generic janitor like
Cristoph, who (amaizingly) knows many differet kernel subsystems. I am
a specific developer and I w
On Thu, 17 May 2007 16:32:01 +0200, Christoph Hellwig wrote:
> Kill ubis homegrown endianess handling crap and replace it with the
> normal kernel endianess handling.
>
Hum, you should check about alignment stuff.
Jffs2 use a similar mechanism and the packed struct also take care of
some unalign
Christoph Hellwig wrote:
> The attribute syntax is perfecltly
> find to address endianess issues without introducing wrapper structs the
> lead to horrible code generation in some situations (e.g. trying to return
> such a value)
Small structs are returned in register; it is indistinguishable fro
On Thu, May 17, 2007 at 08:23:14PM +0200, Sam Ravnborg wrote:
> On Thu, May 17, 2007 at 08:12:23PM +0200, Christoph Hellwig wrote:
> > On Thu, May 17, 2007 at 11:50:54PM +0800, David Woodhouse wrote:
> > > On Thu, 2007-05-17 at 16:32 +0200, Christoph Hellwig wrote:
> > > > Kill ubis homegrown endia
On Thu, May 17, 2007 at 08:12:23PM +0200, Christoph Hellwig wrote:
> On Thu, May 17, 2007 at 11:50:54PM +0800, David Woodhouse wrote:
> > On Thu, 2007-05-17 at 16:32 +0200, Christoph Hellwig wrote:
> > > Kill ubis homegrown endianess handling crap and replace it with
> > > the normal kernel endiane
On Thu, 17 May 2007 20:46:46 +0300
Artem Bityutskiy <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-05-17 at 10:29 -0700, Andrew Morton wrote:
> > umm.. I'd say what you've done in there is an improvement to the exiting
> > stuff: getting gcc to check it is better than having to use sparse.
> >
> > I'
On Thu, May 17, 2007 at 11:50:54PM +0800, David Woodhouse wrote:
> On Thu, 2007-05-17 at 16:32 +0200, Christoph Hellwig wrote:
> > Kill ubis homegrown endianess handling crap and replace it with
> > the normal kernel endianess handling.
>
> NAK. The 'normal' kernel stuff doesn't work in GCC; only
On Thu, 2007-05-17 at 10:29 -0700, Andrew Morton wrote:
> umm.. I'd say what you've done in there is an improvement to the exiting
> stuff: getting gcc to check it is better than having to use sparse.
>
> I'd have expected gcc to generate poorer code with your approach but I'm
> showing zero text
On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-05-17 at 16:56 +0200, Christoph Hellwig wrote:
> > On Thu, May 17, 2007 at 05:50:43PM +0300, Artem Bityutskiy wrote:
> > > Christoph,
> > >
> > > On Thu, 2007-05-17 at 16:32 +0200, Christoph Hellwig wrot
On Thu, 2007-05-17 at 16:32 +0200, Christoph Hellwig wrote:
> Kill ubis homegrown endianess handling crap and replace it with
> the normal kernel endianess handling.
NAK. The 'normal' kernel stuff doesn't work in GCC; only in sparse.
If you want to go removing the ones which _do_ work in GCC, th
On Thu, 2007-05-17 at 16:56 +0200, Christoph Hellwig wrote:
> On Thu, May 17, 2007 at 05:50:43PM +0300, Artem Bityutskiy wrote:
> > Christoph,
> >
> > On Thu, 2007-05-17 at 16:32 +0200, Christoph Hellwig wrote:
> > > Kill ubis homegrown endianess handling crap and replace it with
> > > the normal
On Thu, May 17, 2007 at 05:50:43PM +0300, Artem Bityutskiy wrote:
> Christoph,
>
> On Thu, 2007-05-17 at 16:32 +0200, Christoph Hellwig wrote:
> > Kill ubis homegrown endianess handling crap and replace it with
> > the normal kernel endianess handling.
>
> Err,__be32 and the company are just spar
Christoph,
On Thu, 2007-05-17 at 16:32 +0200, Christoph Hellwig wrote:
> Kill ubis homegrown endianess handling crap and replace it with
> the normal kernel endianess handling.
Err,__be32 and the company are just sparse things, while I have compiler
checks with my struct ubi32_t and friends. JFFS
37 matches
Mail list logo
