Where are static variables stored?

Suppose I am using a 8051.

Then you are supposed to know about CODE, DATA, IDATA, XDATA and PDATA memory - 8051 is a multi Harvard architecture.

Where that Static Variable will be stored?

That is a good question. It will depend on the compiler settings - usually called "memory model"; But you can also explicitly say where the compiler will put it:

xdata unsigned int i;  // integer in XDATA memory

The compiler/linker should be able to crate a Map file, which will show you the addresses of your variables.

CONST are stored in ROM.

This probably depends on the compiler and needs to be checked against the Map file. I remember tagging those explicitly:

code const char fooStr[]="Foo";  // string constant in code = flash memory

And global variables are stored in Flash

Both true and false. They reside in one of the 8051's data memories, but the initial value will be loaded from Flash at startup time - unless the variable is initialised with zero.

The following answer is based on my experience looking at mapfiles, if I'm wrong about sth. please correct me!

Static vars are definitely not stored on the heap, since this is only for variables allocated during run time (and static vars are allocated during compile time).

Static variables are stored in RAM, just like your global variables. The scope of a certain variable matters only to the compiler, at the machine code level nobody prevents you from reading a local variable outside of a function (as long as your controller doesn't have some fancy features to protect memory areas from being accessed).

And global variables are stored in Flash.

No. Think about it: To write a single bit of flash, you have to erase a whole block of data an then rewrite the whole thing with the modified data. And these steps do not execute in a single cycle like a simple store into RAM does. Global variables are stored in RAM, just like mentioned before. This solves also your confusion about flash-less systems.

On processors where the code store is in the same address space as all other variables, compilers will typically place "const"-qualified global or static variables into their own link section, and linkers will typically be configured to place that section in the system's code store (flash, OTP, or whatever). This will reduce the amount of RAM required by the program, and will reduce the amount of work the startup code has to do.

On processors where the code store is in a different address space (e.g. the PIC or 8051), some compilers will use a const qualifier to signal that they should place the variables into the code store and use different instructions to access them, while others will not. Such compilers will require that only pointers with a const qualifier may be used to access const-declared variables, since without that requirement the compilers wouldn't know that special instructions had to be used to access such pointers.

On the 8051 compilers I've seen (Archimedes and Keil), there are 8051-compiler-specific keywords __data, __idata, __code, __bdata, _pdata, and_xdata available to indicate that variables should be loaded in a particular address space. By default, the names can be used with or without underscores; the non-underscore versions are more convenient, but may be disabled if, e.g. one is porting a program which uses identifiers named code or data). If a pointer is declared without applying one of those keywords to its target, the compiler will allocate three bytes: one to indicate what memory space the target is in, and two to hold a 16-bit address if one is required. Declaring a variable const without also applying a code qualifier will cause the variable to be placed in the default RAM address space, and loaded with the default value at startup; a variable declared that way may be passed to code expecting a pointer in the default address space (but will use RAM). Adding a __code (or code, if enabled) declaration will cause the variable to be placed in code space. It's usually better to use the code declaration than not, but in some cases, especially if the item in question is small, the comparative ease of accessing things in idata RAM might make up for the loss of a few bytes of that space.