YY**TYPE Definitions and PB

[tajmone]

In lempar.c we find various YY**TYPE definitions, like YYCODETYPE, YYACTIONTYPE and YYMINORTYPE which in the final parser will specify which C type to use for representing various data types according to their minimum data-size requirements. E.g.:

/* The next sections is a series of control #defines.
** various aspects of the generated parser.
**    YYCODETYPE         is the data type used to store the integer codes
**                       that represent terminal and non-terminal symbols.
**                       "unsigned char" is used if there are fewer than
**                       256 symbols.  Larger types otherwise.

In the generated parser, the result is something like this:

#define YYCODETYPE unsigned char

All these types are calculated via the minimum_size_type() function found in report.c:

/*
** Return the name of a C datatype able to represent values between
** lwr and upr, inclusive.  If pnByte!=NULL then also write the sizeof
** for that type (1, 2, or 4) into *pnByte.
*/
static const char *minimum_size_type(int lwr, int upr, int *pnByte){
  const char *zType = "int";
  int nByte = 4;
  if( lwr>=0 ){
    if( upr<=255 ){
      zType = "unsigned char";
      nByte = 1;
    }else if( upr<65535 ){
      zType = "unsigned short int";
      nByte = 2;
    }else{
      zType = "unsigned int";
      nByte = 4;
    }
  }else if( lwr>=-127 && upr<=127 ){
    zType = "signed char";
    nByte = 1;
  }else if( lwr>=-32767 && upr<32767 ){
    zType = "short";
    nByte = 2;
  }
  if( pnByte ) *pnByte = nByte;
  return zType;
}

The above function must be tweaked to use PB types.

The choice of the types requires careful consideration. This is intended to save memory space in the parser data storage, but PureBasic is known to be quirky when handling signed and unsigned types in a same expression, and in general it behaves best with signed types.

Furthermore, PB doesn't support the u32 type, so that might have to be skipped.

In any case, some tests should be done to prevent having to do lots of horrible hacks to convert unsigned types to signed, which might ultimately slow down execution (not to mention potential bugs, which would be hard to track).

Furthermore, users are reporting many issues with unsigned types being treated differently by the Fasm and GCC backends in PB 6 Beta (and since casting has always been a quirky and undocumented, chances are that these problems will still be in the final version).

Then there's the problem of how to handle in PB the C-style single #define:

#define YYCODETYPE unsigned char

A quick solution, would be to use a macro to define the type. But it would be much better if the various types were stored somewhere in Lemon, and correctly injected as PB types (.b, .u, .i, etc.) in the generated code, every time a YY**TYPE is needed, but unfortunately these types are calculated on the fly, injected and dropped! So to preserve them for later use might require tweaking the code and either adding extra fields in an existing structure to preserve them, or create a new structure for that purpose.

[tajmone]

Data Types Correspondence Table

The following table only lists PB types which are size-equivalent on both x64 and x32.

C type	PB	aka	bytes	lwr	upr
unsigned char	.a	u8	1	0	+255
unsigned short int	.u	u16	2	0	+65,535
unsigned int	n/a	u32	4	0	+4,294,967,295
signed char	.b	i8	2	-128	+127
short	.w	i16	4	-32,768	+32,767

References

• PB Documentation » Variables and Types
• TutorialsPoint » C Data Types