On Sat, Feb 21, 2015 at 02:05:23PM +0100, FRIGN wrote: > On Sat, 21 Feb 2015 09:55:53 +0100 > k...@shike2.com wrote: > > > > char *name; /* string representation of op */ > > > - int type; /* from Tok.type */ > > > - int prec; /* precedence */ > > > - int nargs; /* number of arguments (unary or binary) */ > > > - int lassoc; /* left associative */ > > > + char type; /* from Tok.type */ > > > + char prec; /* precedence */ > > > + char nargs; /* number of arguments (unary or binary) */ > > > + char lassoc; /* left associative */ > > > } Op_info; > > > > I don't have any problem with the patch, but the advantage of this > > patch depends too much of which machine you are using. In a > > i386/x86-64 the code is going to be similar and you are going to save > > memory, but in other processors maybe you need aditional operations to > > transform the char (which can be signed or unsigned) to integer. I > > usually put flags as integers because you don't save too much > > (if you have four options like this case) and you don't know if the > > code is going to be smaller or not. > > It all comes down to alignment: > > For 32 Bit / 64 Bit machines (assuming int is 32 bit and char is 8 bit). > Signed, unsigned makes no difference, assuming self-aligned (which is the > case on x86, x86_64 and ARM): > > OLD > char *name; /* 4 bytes */ /* 8 bytes */ > int type; /* 4 bytes */ /* 4 bytes */ > int prec; /* 4 bytes */ /* 4 bytes */ > int nargs; /* 4 bytes */ /* 4 bytes */ > int lassoc; /* 4 bytes */ /* 4 bytes */ > ----------------------------------------- > 24 bytes 28 bytes > > NEW > char *name; /* 4 bytes */ /* 8 bytes */ > char type; /* 1 byte */ /* 1 byte */ > char prec; /* 1 byte */ /* 1 byte */ > char nargs; /* 1 byte */ /* 1 byte */ > char lassoc; /* 1 byte */ /* 1 byte */ > ----------------------------------------- > 8 bytes 12 bytes > > You would only get padding-issues when mixing ints and chars, or putting > the pointer somewhere else than the beginning (because pointer-alignment > has to be in effect. ints have to be 4 byte-aligned, so an int following > a pointer-aligned char would have 3 bytes of padding inbetween. > But there is no problem here. char's are fine, but I didn't look too deep > into the code. > The reason why often chars have no advantage over ints is exactly when > ints and chars are mixed, given they both need 4 bytes of memory at the > end of the day.
Yeah that's all good but at the end of the day this kind of optimization only makes sense if you have a lot of these objects allocated. You can significantly reduce the memory footprint in that case. This is not the case here so it doesn't quite matter. I am OK either way. Cheers, Dimitris
