On Sat, 21 Feb 2015 09:55:53 +0100
k0ga_AT_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.
Cheers
FRIGN
--
FRIGN <dev_AT_frign.de>
Received on Sat Feb 21 2015 - 14:05:23 CET