Consider adding static storage class?

[HPCguy]

A 'static' storage class could potentially be supported by internally creating a 'hidden' global variable having the name <funcname>_<varname>. This could help prevent the use of global variables, at least in the source code. I think all the machinery is already there to support this in about ten lines of source code changes.

[jserv]

I really look forward to the support for static storage. However, is it enough to avoid the potential conflict with the name scheme <funcname>_<varname>? That is, we might have main_i and variable i in function main at the same time.

[HPCguy]

Yes and no. It is illegal to do the following in both C and AMaCC:

void foo()
{
    static int i;
    int i;
}

Currently in AMaCC, every block-local declaration of 'int i' in a function is promoted to a function-level local varaible.

On the other hand, in C, this is legal:

void foo()
{
    static int i;
    {
        int i;
        /* ... */
    }
}

As an aside, you could handle block-level shadow declarations of a variable in AMaCC with the same mechanism I proposed for static: <funcname>_<varname>_<$blkID>, but using the AMaCC Loc class instead of the AMaCC Glo class as I proposed for static. Since the global declaration that I had added in my previous push had concerned you, I thought I should add this ticket to propose an easy fix.

[jserv]

On the other hand, in C, this is legal:

void foo() { static int i; { int i; /* ... */ } }

As an aside, you could handle block-level shadow declarations of a variable in AMaCC with the same mechanism I proposed for static: <$blkID>, but having AMaCC Loc class instead of the AMaCC Glo class used for static. Since a global declaration I had added in my last push concerned you, I thought I should add this ticket to propose an easy fix.

With the introduction of name scheme changes, AMaCC would be able to handle block scoping. It would be definitely essential toward full C89 compliance. Can you send pull request(s) for this in advance?

[HPCguy]

Yes. I will warn here before opening a branch if I decide to work on this. Hopefully anyone who intends to work on this will do the same.