Translating Blech variable names to C
Possibilities in Blech
Variable names appear in different syntactic contexts (expressions):
- current / previous access
- lhs / rhs value (in assignment)
- lhs / rhs reference (in procedure call)
Variable names appear in different declaration contexts:
- Parameter input / output
- Global constant
- Activity- / function-local Blech variable
- Activity-local external C-variable
- Auxiliary variable introduced by the compiler
Variable names may represent various kinds of data types:
- Simple (atomic)
Not all combinations are possible. Below is an overview of what is possible in Blech and what the corresponding generated C code must look like.
Translating any access to data runs through several stages:
Given a typed memory location
prev foo.bar binds as
- For the QNamePrefix part
foo, determine a name scheme (depending on declaration context)
- Static name
- Parameter name
- Auto name
- Context element
- Auxiliary name
- prev of Blech var
- prev of extern var
- Static name
- Ensure the name
<name>generated above represents the memory blob itself, not a pointer to it
foois a simple type or struct parameter rewrite name from above to
- Nothing to do for arrays as the name (pointer to the first element) already represents the whole array blob.
- Append all field / cell access to this name
- Depending on usage context and type (of
bar) determine whether to use the path as is or construct a reference from it
Possibly reduce trivial combinations like
<name>. This will happen for e.g. simple typed output parameters passed on as an output argument.
Remarks and after thoughts:
blc_ prefix is used to make sure we never overwrite global variables with the same name (that might appear in C sources outside the scope of the generated Blech code). Of course, we assume that the
blc_ prefix is reserved and not used by sources not generated by the Blech compiler.
However previous variables use the scheme
prev_ yet another exclusive prefix. We cannot simply generate
prev <id> as this would clash with a regular Blech variable called
We also use
blc_ for naming fields in the activity context. This ensure we rule out clashes between normal and prev’ed external variables in the activity context.
Auxiliary variables use yet another prefix
This ensures they do not shadow a global C variable with the same name (assuming that the environment never uses names starting with
This is basically the same reasoning as with auto variables. However we need the extra
aux_ to prevent a clash with an actual Blech variable.
statickeyword of C and let the declaration remain inside the function?