What is the meaning of ATS_STATIC_PREFIX? - ats

For instance, I saw the following line the other day:
#define ATS_STATIC_PREFIX "_Game_of_24_"
What is the meaning of such a line? What purpose does it serve?

Its literally one search on the google.
Here is the site.
Here is the quoted answer for your question:
When the DATS-file is
compiled into C, the prefix 'foo__' is attached to the original names
of static variables and functions in the generated C code.
This feature can be very useful if one wants to mix the C code
generated from multiple ATS source files as doing so is likely to
result in name conflicts among static variables and functions in the
C code. Such conflicts can be resolved by properly setting
ATS_STATIC_PREFIX. The same applies to loading PHP code generated from
ATS source.

Related

debugging yacc YYDEBUG where is y.debug

I trying to debug a the yacc generated component for awk (awk.g.c) but when I define YYDEBUG it includes y.debug which I don't seem to have.
Where does y.debug come from?
Without it there are several references that are undefined.
I'm compiling the old 32v or V7 version of awk so I'm not sure if this is something that still exists.
Some versions of yacc (in particular, the AT&T version, still available as part of Plan 9) generated an additional file with the suffix .debug containing debugging information, notably the table which translated symbol numbers back into names. Modern yacc-alikes just insert this information into the generated C file, on the grounds that the memory consumption is basically trivial these days.
The name table might not be generated if you don't request it, but the way you ask for it depends on the yacc version:
Most bison versions only generate the table if the trace option is enabled. (Posix mandates -t for this, but bison provides a host of alternatives and not all historical yaccs complied.)
As indicated above, some really old yaccs put the name table into y.debug. The AT&T implementation, as I mentioned above, always did this, but guarded the #include line with a preprocessor conditional on YY_DEBUG
However, the yacc implementation you pointed to in a comment, which uses the conditionally-included y.debug mechanism, only generates the y.debug file if you invoke it with the -D flag. So that's what you need to do.
Background notes
I unearthed the information in point 3 from the V10 source linked in a comment. The download link is at the top of this page; that wasn't immediately obvious from the link in the comment. (That's the complete source tarball, which is about 70MB. The individual files linked to by the link in the comment have been HTMLised, which makes them a pain to work with.) I could have saved myself some time by reading the release notes (called yaccnews rather than CHANGES). The last note in that file describes the implementation, and I include the paragraph here since it has all the details on how debugging works in this particular yacc version.
8/11/81
Debugging changed. If the parser starts with %{#define YYDEBUG %} and yacc is invoked as yacc -D (for Debugging), then the parser uses an external variable named yydebug to control debugging output. If yydebug == 1, the parser prints out the text of the reduction when it performs one. If yydebug == 2, the parser also prints out the name of the token returned by each call to yylex, and if yydebug == 3, the parser also prints out the active items each time it changes state (this is uninteresting).
For what it's worth, it should be possible to generate a working, compilable parser using a modern yacc (such as bison or byacc). In the long run, that will probably be easier. (If you use bison and you require legacy yacc compatibility, you can use the -y flag. That flag is not supported by byacc, which claims to be legacy compatible regardless.)

What is C(argument) in documentation

Recently I have been reviewing a lot of Ansible modules(code) and I have come across some with this strange nomenclature in the documentation section when referring to arguments such as the examples (F5 modules) below:
specified, the default of C(round-robin) will be used
or this
If this value is an IP address, and the C(type) is C(tcp) (the
default),
then a C(port) number must be specified.
What is the C and is it required when documenting your code? As I said not all of the modules have in them.
I just found this in ansible.docs-1.7.pdf1), page 545:
The description, and notes fields support formatting with some
special macros.
These formatting functions are U(), M(), I(), and C() for URL,
module, italic, and constant-width respectively. It is suggested to
use C() for file and option names, and I() when referencing
parameters; module names should be specifies as M(module).
1) This seems to be somewhat dated, but should still be valid. The same can also be found in the latest online documentation.

how to check for a macro defined in a c file in Makefile?

I have a #define ONB in a c file which (with several #ifndef...#endifs) changes many aspects of a programs behavior. Now I want to change the project makefile (or even better Makefile.am) so that if ONB is defined and some other options are set accordingly, it runs some special commands.
I searched the web but all i found was checking for environment variables... So is there a way to do this? Or I must change the c code to check for that in environment variables?(I prefer not changing the code because it is a really big project and i do not know everything about it)
Questions: My level is insufficient to ask in comments so I will have to ask here:
How and when is the define added to the target in the first place?
Do you essentially want a way to be able to post compile query the binaries to to determine if a particular define was used?
It would be helpful if you could give a concrete example, i.e. what are the special commands you want run, and what are the .c .h files involved?
Possible solution: Depending on what you need you could use LLVM tools to maybe generate and examine the AST of your code to see if a define is used. But this seems a little like over engineering.
Possible solution: You could also use #includes to pull in .c or header files and a conditional error be generated, or compile (to a .o), then if the compile fails you know it is defined or not. But this has it's own issues depending on how things are set-up in your make file.

What does an underscore at the start of an *.scss file name indicate?

I've had a look into CSS setups for a couple of projects that other people developed and I can understand most of what's going on.
The programmers have, however, created some files whose names start with the underscore (for example: _variables.scss). I have seen files named like this in both of the projects.
I can't figure out what this convention represents. Is there a special reason why the people are naming the files this way?
The only reason I can find to use underscore before the name of the partial is what's described in the Sass docs here:
The underscore lets Sass know that the file is only a partial file and that it should not be generated into a CSS file.
Any SASS files not beginning with an underscore will be rendered on their own, which will fail if they are using variables or mixins defined elsewhere.
In the end I have concluded that the underscore is just used to clarify that it is a partial file. We can also use a partial file without using an underscore as prefix.
Sometimes that naming convention is used for templates or template part files, you could find this being used in MVC frameworks.
In other places this might mean that this variable or file is private and can only be accessed by the server or the running program. It all depends on the language you're programming really, but this is simply a naming convention.
It's just a naming convention. When you want to define a name for an interface you define it with (_interface). This is just for compatibility issues, In some cases a program may include classes and interfaces And in order to distinguish between the two, you use _ for interfaces.
This is just one example as you can use it in the BLL layer when working with databases and so on.
It is an emphasis for other developer to notice the variables and objects.

How can I create a custom variable attribute to direct movs into different address spaces?

So, I'm building a custom backend for GCC for a processor. This processor has 4 address spaces: local, global, mmm, and mmr. I want to make it such that when writing c code, you can do this:
int global x = 5;
which would cause the compiler to spit out an instruction like this:
ldi.g %reg, 5
I know that certain processors like blackfin and MeP do something similar to this, so I figure its possible to do, however I have no idea how to do it. The technique that should allow me to do this is a variable attribute.
Any suggestions on how I could go about doing this?
You can add target-specific attributes by registering a struct attribute_spec table using TARGET_ATTRIBUTE_TABLE, as described in the GCC internals documentation. The details of struct attribute_spec can be found in the source (gcc/tree.h).
This handler doesn't need to do anything beyond returning NULL_TREE, although typically it will at least do some error checking. (Read the comments in gcc/tree.h, and look at examples in other targets.)
Later, you can obtain the list of attributes for a declaration tree node with DECL_ATTRIBUTES() (see the internals docs again), and use lookup_attribute() (see gcc/tree.h again) to see if a given attribute in the list.
You want to references to a symbol to generate different assembly based on your new attributes, so you probably want to use the TARGET_ENCODE_SECTION_INFO hook ("Define this hook if references to a symbol or a constant must be treated differently depending on something about the variable or function named by the symbol") to set a flag on the symbol_ref (as the docs suggest). You can define a predicate for testing this flag in the .md .

Resources